MTU / 패킷 재조립 - 2

< 1번 패킷 >

3계층 IPv4 Header 를 살펴보면 Flags -> More Fragments 필드가 Set 되어 있으면 이는 분할된 패킷임을 나타낸다.

Fragment offset 값이 0일 경우, 이는 분할된 패킷의 첫 번째 패킷임을 나타낸다.

< 1번 패킷 >

< 2번 패킷 (마지막 패킷) >

IPv4 헤더의 내용 중 Identification 필드의 값은 동일한 패킷임을 알려준다. [ 0x00b6 ]

(분할된 동일 패킷끼리는 동일한 값을 가지기 때문이다.)

분할된 패킷의 마지막 패킷은 IPv4 Header의 Flags -> More Fragments 필드가 Not Set 되어 있다.

수신 측에선 패킷이 모두 도착하면 Fragment offset 값이 낮은 순서대로 재조립 한다.

[출처] MTU / 패킷 재조립 - 2|작성자 육육

MTU / 패킷 재조립 - 1

MTU란 ?

Maximum Transmission Unit = 최대 전송 단위

즉 MTU란 하나의 패킷이 가질 수 있는 최대 크기를 말한다.

크기를 이렇게 나누어 놓은 이유는 데이터를 쪼개지 않고 하나의 커다란 덩어리로 전송을 하게 된다면

전송 과정 중 데이터에 손실을 입게 될 경우 그 데이터는 쓸모가 없어지기 때문이다.

하지만 데이터를 나누어서 전송을 한다면 손실된 부분만 다시 요청을 하여 그 부분만 다시 전송 받을 수 있으므로 신뢰성 있는 통신을 할 수 있다.

비슷한 예로 우리가 평소에 인도에서 흔히 볼 수 있는 보도블럭을 생각 해 보자.

만일 보도블럭이 나누어져 있지 않고 합쳐져 있다면 파손되었을 경우 전체를 교체해야 하지만

보도블럭이 나누어져 있으면 파손된 부분만 교체를 하면 되기 때문이다.

일단 패킷이 분할되는 크기를 보기 위하여 사진을 첨부하겠다.

< Source = 192.168.0.48 // Destination = 192.168.0.44 >

-l [n] = 전송할 byte 지정

-n [n] = count

Ping 전송시 패킷이 캡쳐된 부분의 패킷 길이를 보면 1514 byte 이다.

저 크기에서 Ethernet header 크기인 14 byte를 빼면 1500 byte가 나오는데, 이 값이 Ethernet 환경에서 기본 MTU 값이다.

근데 위의 스샷에서 Ping 전송시 -l 옵션을 주어 2000 byte를 전송 하였는데 왜 길이가 1514+562 

= 2076 byte 일까?

그 이유는 바로 패킷/프레임에 포장된 헤더 크기 때문이다.

우선 Ethernet 헤더부터 살펴 보겠다.

< Ethernet II Header >

1. Destination MAC address ( 6 byte ) = 송신지의 MAC 주소

2. Source MAC address ( 6 byte ) = 수신지의 MAC 주소

3. Type ( 2 byte ) = 상위 타입 ( 0x0800은 IP /// 0x0806은 ARP 등등...)

이더넷 헤더의 총 크기는 14 Byte 이다.

다음은 IPv4 헤더를 살펴 보겠다.

1. version ( 1 byte ) = IP 헤더에 사용된 IP 버전 정보 

2. Header length ( 1 byte ) = IP 헤더의 길이 

3. Differentiated Services Field ( 1 byte ) = 서비스 유형

4. Total Length ( 2 byte ) = IP 헤더 + 패킷에 포함된 데이터 크기

.

.

.

생략 ( IPv4 헤더를 따로 포스팅 할 예정...)

IPv4 헤더의 Header length 필드의 값이 IP 헤더의 길이를 나타낸다.

총 20 Byte 임을 알 수 있다.

첫번째 패킷에서의 데이터 크기는 1480 byte 임을 알 수 있다.

[ 총 크기(1514) - Ethernet Header(14) - IPv4 Header(20) = 1480 byte]

두번째 패킷도 Ethernet header 크기는 같다. 

하지만 다음 계층의 헤더 정보가 다르므로 한번 살펴보겠다.

[ 총 크기(562) - Ethernet Header(14) - IPv4 Header(20) = 528 byte]

데이터 크기가 528 byte 라는 것을 알 수 있다.

첫번째 패킷의 1480 byte + 두번째 패킷의 528 byte = 2008 byte ???

2008 byte가 나오는 이유는 ICMP 헤더 크기 때문이다.

ICMP 헤더의 크기는 총 8 byte 이므로 ICMP 헤더 크기를 빼주면 데이터 크기가 2000 byte 임을 

알 수 있다.

[출처] MTU / 패킷 재조립 - 1|작성자 육육

TCP 4 way handshake

네 방향 핸드셰이크란? 

TCP 기반의 통신은 맨 처음 데이터를 송/수신 하기위해 세 방향 핸드셰이크 절차를 수행한다.

송/수신 이전에 세션을 확립하는 절차이다.

네 방향 핸드셰이크는 세션을 종료하기 위해 수행하는 절차이다.

< 3 way handshake >

세 방향 핸드셰이크 과정에서는 SYN/ACK 플래그가 사용되었다. 

SYN = Synchronization

ACK = Acknowledgment

< 4 way handshake >

하지만 네 방향 핸드셰이크 과정에서는 FIN/ACK 플래그를 사용하게 된다. 

FIN = Finish

ACK = Acknowledgment

= = = = = = = = = = = = = = = = = = = =

1.  Client - > Server 연결 종료 요청

클라이언트는 [클라이언트 -> 서버] 방향으로 연결 종료를 위해 

TCP 제어 플래그에 FIN/ACK를 설정한 패킷을 전송 한다.

데이터 전송? = X

데이터 수신? = O

이 상태를 FIN_WAIT-1 상태 라고 한다.

= = = = = = = = = = = = = = = = = = = =

2. Server -> Client 확인 응답 

Server - > Client 연결 종료 요청

< Server -> Client 확인 응답 >

< Server -> Client 연결 종료 요청 >

클라이언트로 부터 연결 요청을 받은 서버는 

확인 응답으로 ACK 플래그를 설정하여 전송을 하게 되고

서버는 클라이언트로 보낼 데이터가 더이상 남아 있지 않으면 

서버->클라이언트 방향의 세션 종료를 요청하는 플래그가 설정된 패킷을 전송한다.

데이터 송신 = X

데이터 수신 = O

이 상태를 FIN_WAIT-2 라고 한다.

4가지 절차를 모두 수행하게 되면 클라이언트는

아직 도착하지 않은 느린 데이터를 위해 일정 시간 동안 

연결 종료를 하지 않고 포트를 개방 한 상태로 남아있게 된다.

이 상태를 TIME_WAIT 이라 한다.

[출처] TCP - 4 way handshake|작성자 육육

TCP 3 way handshake

삼방향 핸드셰이크란?

TCP 기반의 통신은 서로간의 신뢰성있는 통신을 하기 위하여 3 Way-Handshake 라는 절차를 통해 서로간의 원할한 통신이 가능한지 선행 절차를 수행하게 된다.

(데이터를 송 수신 하기 이전에 세션을 확립하는 절차)

- 목적지 호스트가 UP 상태인지 확인한다.

- 서로간의 원할한 패킷 흐름 유지가 가능하다.

< TCP 3 way handshake >

ACK = 확인 응답

SYN = 일련 번호

1. Client -> Server [일련번호 전송]

서버와 연결을 위해 맨 처음 [SYN] 플래그가 설정된 패킷을 송신한다.

Sequence number = 0

2. Server -> Client [확인응답 + 일련번호]

클라이언트로 부터 [SYN] 플래그가 설정된 패킷을 수신한 서버는

그에 대한 확인 응답으로 [ACK]를 설정하여 보냄과 같이 [SYN]을 같이 설정하여

하나의 패킷으로 송신한다.

Sequence number = 0

Acknowledgment number = 1 (1번 패킷의 sequence + 1)

3. Client -> Server [확인응답]

서버로부터 [SYN] 플래그가 설정된 패킷을 수신한 클라이언트는

확인 응답으로 [ACK] 플래그를 설정한 패킷을 서버로 송신

Sequence number = 0

Acknowledgment number = 1 (2번 패킷의 Sequence number + 1)

확인 응답 번호는 이전 패킷의 Sequence Number 보다 하나가 큰 값으로 설정되어 전송된다.

위의 절차가 정상적으로 끝나면 서로간의 데이터를 주고 받을 수 있는 상태가 된다.

SYN_SENT : 클라이언트에서 SYN 패킷을 송신 했지만 서버로부터 ACK를 받지 못한 상태

(1번에 해당)

SYN_RCVD : 서버에서 클라이언트로 SYN/ACK 패킷을 송신 하였지만 ACK 패킷을 수신받지 못한 상태 (2번에 해당)

ESTABLISHED : 서버-클라이언트 간의 3 way-handshake 상태가 끝난상태. 이 상태부턴 데이터 교환이 가능해진다 (3번에 해당)

[출처] TCP - 3 way handshake|작성자 육육

DHCP 패킷 분석 - 2

DHCP Discover

DHCP Offer

DHCP Request

DHCP ACK 

4개의 패킷을  차례대로 살펴 보겠습니다.

< DHCP Discover >

1. DHCP Discover

IP 주소를 동적으로 할당 받기를 원하는 클라이언트는 DHCP 서버를 찾기 위해 DHCP Discover 패킷을 목적지 255.255.255.255 로 송신한다. 즉 Broadcast로 패킷을 전파 한다.

;

;

(1) Message type : boot Request

Message type 필드의 값을 보면 패킷이 요청인지 응답인지 알 수 있다.

(1은 요청, 2는 응답)

클라이언트가 DHCP 서버를 찾기 위해 송신 하므로 1의 값이 설정된다.

(DHCP 서버는 응답을 해달라는 요청을 하는 것이기 때문이다.)

;

;

(2) Transaction ID : 0x6b3d8569

하나의 request, reply는 동일한 Transaction ID를 가진다.

즉, 이 필드에 0x00000001의 값이 설정되어 요청을 한다면

그에 대한 응답을 받을 때, 0x00000001의 값이 설정 되어 응답을 받는다.

;

;

(3) Bootp flags : 0x0000 (unicast)

Bootp flags 필드의 Broadcast flag 가 1로 설정 되면 서버가 이 패킷을 수신하여 응답을 할 때 Broadcast로 응답 하게 된다. 사진엔 보이지 않지만 이 값이 0으로 설정 되어 있으므로 이 패킷에 대한 응답을Unicast로 하게 된다.

(서버에게 어느 유형으로 응답을 해달라는 요청 정도로 보면 된다.)

;

;

(4) option: (53) DHCP Message Type

이 필드는 DHCP 패킷이 어느 유형의 패킷인지 나타낸다. 현재 필드에선 값이 1로 되어 있는데, 이는 즉DHCP Discover 패킷 임을 알 수 있다.

;

;

;

(5) option: (55) Parameter Request List

이 필드는 클라이언트가 서버로 IP 주소 할당 요청을 하여 그에 대한 응답을 받을 때, 추가로 받고 싶은 요청 목록이다.

DNS 서버 도메인과 주소, Gateway 주소 등등 여러 가지를 요청 할 수 있다.

;

;

< DHCP Offer >

2. DHCP Offer

클라이언트로 부터 DHCP Discover 패킷을 수신한 서버는 DHCP Offer 패킷으로 응답을 한다.

이 패킷에는 클라이언트에게 할당 가능한 IP 주소와 여러 정보들을 담고 있다.

;

;

(1) Message type = boot Reply (2)

DHCP Offer 패킷은 클라이언트로부터 받은 요청에 대한 응답 패킷이다.

그러므로 이 필드의 값이 2로 설정 되어 있다.

(1=요청 / 2=응답)

;

; 

(2) Transaction ID : 0x6b3d8569

하나의 request, reply 패킷은 이 필드의 동일한 값을 가진다고 위에서 설명 하였다.

위의 DHCP Discover 패킷과 현재 보고 있는 DHCP Offer 패킷을 보면 이 필드의 값이 동일 하므로

하나의 요청에 대한 응답은 이 필드의 값이 같다는 것을 알 수 있다.

;

;

(3) Your (client) IP address: 172.16.99.2 (172.16.99.2)

이 필드의 값은 임대 가능한 IP 주소이다. 즉 서버에서 제공하려는 주소가 이 필드에 나타나 있다.

;

(4) Client MAC address : vmware_04:9c:c8 (00:0c:29:04:9c:c8)

이 필드는 IP 주소를 제공받을 클라이언트의 MAC 주소가 들어있다.

;

;

(5) option: (53) DHCP Message Type

현재 이 필드에 2의 값이 설정 되어 있다. 2는 DHCP Offer 패킷임 을 나타낸다.

;

;

(6) option~

DHCP 서버는 클라이언트에게 IP 주소 할당을 함과 같이 다른 여러 가지 정보들을 같이 전송한다.

이 옵션이 바로 여러 가지 정보들이다. 사진을 보면 DHCP 서버 주소, 임대기간, 서브넷, 게이트웨이 등등 여러 가지 정보들을 담고 있다.

;

;

!!!

DHCP Offer 패킷을 수신한 클라이언트는 IP 주소를 바로 사용 하지 않는다.

왜냐하면 여러 DHCP Server로 부터 DHCP Offer 패킷을 수신 하게 되면 그중 가장 빨리 수신한 패킷을 

보낸 서버와 두 가지의 절차를 더 수행 한 후 완전히 IP 주소를 할당 받아 사용 할 수 있게 된다.

즉 DHCP Offer 패킷은 클라이언트에게 "나는 이런 IP 주소를 할당 해 줄 수 있다" 라고 제의를 할 뿐 할당을 하는 것은 아니라고 볼 수 있다.

;

; 

< DHCP Request >

3. DHCP Request

클라이언트가 DHCP 서버로 부터 DHCP Offer 패킷을 수신 하면 DHCP Request 패킷을 송신한다.

DHCP 서버로부터 "이런 IP 주소를 할당 해 줄수 있다" 라는 DHCP Offer 패킷을 받게 되면 클라이언트는 서버에게 "그 IP 주소를 사용 해도 되겠냐?" 라는 의미의 DHCP Request 패킷을 보내게 된다.

만일 여러대의 DHCP 서버로 부터 DHCP Offer 패킷을 수신 하였다면 맨 처음 도착한 DHCP Offer 메세지를 송신한 서버로 DHCP Request 패킷을 보내게 된다.

;

;

(1) Message type : boot Request (1)

DHCP Request 패킷은 이름에서도 볼 수 있듯이 요청을 하는 패킷이므로 1의 값이 설정 되어 있다.

(1=요청 / 2=응답)

;

;

(2) option: (53) DHCP Message Type

이 필드에 3의 값이 설정 되어 있으므로 이 패킷은 DHCP Request 패킷 임을 나타낸다.

;

;

(3) option: (50) Requested IP Address

이 필드에는 DHCP Offer 패킷의 Your (client) IP address 필드의 아이피 주소가 이곳에 들어가게 된다.

즉, 서버는 클라이언트에게 Offer 패킷으로 “난 너에게 n.n.n.n IP 주소를 할당 해 줄 수 있어” 라는

제의를 하게 되고 클라이언트는 서버에게 DHCP Request 패킷으로 “n.n.n.n의 아이피를 사용해도 괜찮냐?” 라는 요청을 보내게 된다.

;

;

(4) option: (54) DHCP Server Identification

DHCP Request 패킷을 수신 할 서버의 IP 주소가 이 필드에 나타나 있다.

;

;

< DHCP ACK >

4. DHCP ACK 

서버는 클라이언트로 부터 DHCP Request 패킷을 송신 하게 되면 그에대한 응답으로 ACK 패킷을 보내게 된다. (ACK = Acknowledgment // 인정, 승인, 답신 등등 허용한다는 뜻을 가지고 있다)

이 과정이 끝나면 비로소 클라이언트는 할당받은 IP를 사용할 수 있게 되고, 서버는 자신의 DB에 정보를 기록하게 된다.

;

;

(1) Message type : boot Reply (2)

클라이언트에게 최종 응답을 해주는 것 이므로 2의 값이 설정 되어 있다.

(1=요청 / 2=응답)

;

;

(2) option: (53) DHCP Message Type 

현재 DHCP ACK 패킷에는 5의 값이 설정 되어 있다. 즉 5의 값이 설정 되어 있으면 DHCP ACK 패킷 임을 나타낸다.

;

;

[출처] DHCP 패킷 분석 - 2|작성자 육육