Facebook Joinc 그룹
Joinc QA 사이트
Tweet
joinc는 Firefox와 chrome에서 테스트 했습니다. IE에서는 테이블이 깨지거나 이미지가 보이지 않을 수 있습니다. 특히 구글 Docs이미지의 경우 엑박처리될 수 있습니다.
Tweet
joinc는 Firefox와 chrome에서 테스트 했습니다. IE에서는 테이블이 깨지거나 이미지가 보이지 않을 수 있습니다. 특히 구글 Docs이미지의 경우 엑박처리될 수 있습니다.
- 보강해야될 내용 : TCP Windows 필드에 대한 설명
- TCP/IP를 처음 공부하는 것이라면, 이 문서를 읽기전에 네트워크 프로그래밍 문서모음에서 TCP/IP 개요 문서들을 먼저 읽어보시기 바랍니다.
1 소개
우리는 IP 자세히보기 를 통해서 IP 프로토콜을 헤더차원에서 살펴보았다. 이번 문서에서는 TCP 프로토콜을 헤더차원에서 살펴보도록 할것이다.
2 TCP (Transmission Control Protocol)
2.1 TCP에 대해서
TCP 개념에 대해선 이미 몇개의 문서를 통해서 다루어지긴 했지만 확인차원에서 다시한번 다루어 보도록 하겠다.
TCP 는 기본적으로 IP 와 함께 사용되며, 그런이유로 TCP/IP 라고 불리워진다. IP는 호스트 사이의 데이타 교환을 목적으로 만들어진 프로토콜인데, 기본적으로 IP는 오로지 데이타 교환을 위한 임무만을 수행한다. 즉 네트웍상에서 발생할수 있는 데이타 누락, 패킷의 순서 뒤바뀜 등의 데이타 교정과 관련된 기능을 가지고 있지를 않다.
그래서 만들어 진개 TCP 프로토콜이다. IP 프로토콜의 상위 레벨 프로토콜로써, IP가 제공하지 못하는 기능즉, 데이타 누락검사 패킷순서 뒤바뀜 등 데이타 교정과 관련된 기능을 제공한다.
이러한 TCP 의 기능상 특징으로 인하여 흔히 TCP 프로토콜을 "신뢰성있는 프로토콜" 이라고한다. TCP 는 이러한 신뢰성 있는 데이타 전송을 위한 방법으로 서버와 클라이언트간에 연결을 설정한다. 이러한 연결을 만드는 특성으로 TCP 프로토콜은 "연결지향 프로토콜" 이라고 말한다.
+---+----+-------------+ |IPH|TCPH|Internet Data| +---+----+-------------+ IPH : IP Header TCPH : TCP Header Internet Data : 교환하고자하는 데이타
그림 1. 전 이중통신 선로
TCP 는 이러한 연결을 설정시 위에서의 그림에서와 같은 "전 이중 통신 선로"를 개설한다. 하나는 읽기 전용의 선로이며, 다른 하나는 쓰기 전용의 선로로써, 각각의 전용선로를 이용함으로 써 읽기와 쓰기를 동시에 할수 있게 된다. 이것은 Unix 에서 IPC 목적으로 pipe 를 생성할때, 읽기와 쓰기전용의 파이프를 동시에 생성하는것과 동일한 원리이다.
TCP 헤더에는 위의 TCP 의 특성을 충족시켜주기 위한 여러가지 기능을 가지는 필드들로 구성되어 있다. 우리는 다음장에서 TCP 헤더의 이러한 필드들을 분석함으로써, 어떻게 TCP 가 서버 클라이언트간 연결을 만들고, 신뢰성 있도록 데이타를 전달하는지 알아보게 될것이다.
2.2 TCP 헤더 구조
TCP 는 다음과 같은 헤더 구조를 가진다. 두 호스트 사이에 전송되는 TCP 데이타 단위를 세그먼트라고 부른다. 그러므로 TCP 세그먼트는 TCP 헤더 + DATA 가 될것이다. 다음은 TCP 세그먼트의 구조이다.
그림 2. TCP 헤더 구조
2.2.1 SOURCE PORT/DESTINATION PORT
source port 는 메시지를 보내는 측에서 통신을 위해 사용하는 port 번호이며, destination port 는 목적지, 즉 메시지를 받는측의 통신 port 번호이다.
여기에 있는 port 번호와 더불어 IP 헤더에 있는 source/destination address 를 이용하면 유일하게 식별되는 통신연결을 만들수 있게 된다.
IP 의 출발지/목적지 주소와 TCP 헤더의 출발지/목적지 포트 번호가 어플리케이션간 통신을 위한 가장 핵심이라고 할수 있을것이다. 다른 정보들은 통신을 원할하도록 도와주기 위해서 부가적으로 존재하는 것이라고 볼수 있다.
이들 포트번호의 크기는 16bit 크기를 가진다. 그러므로 대략 65536 만큼의 포트를 가질수 있을것이다.
2.2.2 SEQUENCE NUMBER
TCP 세그먼트안의 데이터의 송신 바이트 흐름의 위치를 가리킨다. 다른 호스트로 전달되는 패킷은 여러개의 서로 다른 경로를 거치면서 전달되다 보니 패킷의 순서가 뒤바뀔 수 있다. 이를 수신측에서는 재 조립해야할 필요가 있는데, Sequence Number 를 이용해서 조립하게 된다.
2.2.3 ACK
acknowledgment number 라고 말한다. 다음에 받을것으로 예상되는 데이타 옥텟의 순서번호를 나타낸다.
2.2.4 HLEN
TCP 세그먼트의 길이를 정의한다.
2.2.5 RESERVED
현재는 사용하지 않지만, 나중을 위해서 예약된 필드이다.
2.2.6 (Control)CODE BITS
세그먼트의 용도와 내용을 결정하기 위해서 사용된다. URG, ACK, PSH, RST, SYN, FIN 6개의 비트가 정의되어 있다. TCP는 이러한 비트를 이용해서 패킷의 내용이 어떤 목적으로 전달될 것인지를 설정할 수 있다. 이들 비트중 SYN, ACK, RST를 주목할 필요가 있다.
SYN은 TCP연결을 만들 때, 양 호스간 sequence numbers의 동기화를 이루기 위한 목적으로 사용된다. ACK는 원격 호스트의 sequence number에 대한 응답을 위한 목적으로 사용된다. 즉 데이터를 잘 받았다는 걸 알려주기 위한 목적으로 사용되는데, 원격호스트의 sequence number의 번호에 +1을 해줘서 다시 전달하는 방법을 이용한다. SYN 비트는 특히 세번 악수 기법(three-way handshake)를 위해서 사용된다.
URG는 Urgent 즉 긴급 메시지를 전송하기 위해서 사용한다. URG 필드가 설정된 패킷을 받은 운영체제는 SIGURG 시그널을 발생시킨다.
RST 비트가 설정되어 있을 경우 받은 호스트는 즉시 연결을 끊어 버리고 FIN 비트가 설정되어 있을 경우 여러가지 테스트를 거쳐서 연결을 끊게 된다. 일반적인 정상종료를 원한다면 FIN 비트를 설정해서 사용하게 된다. 이들 비트에 대한 자세한 내용은 2.3.3절를 참고하기 바란다.
2.2.7 OPTION & PADDING
옵션은 말그대로 옵션이다. TCP 헤더의 정보를 좀더 확장시키고자 할때 사용한다. PADDING 은 32bit 크기를 채우기 위해서 사용된다.
2.2.8 CHECKSUM
TCP 세그먼트 데이타는 중간에 훼손될수 있으며, 변조될수도 있다. 그러므로 이를 체크할수 있는 장치가 필요하다. CHECKSUM 을 만드는 방법(알고리즘)은 기회가 되면 별도로 설명하도록 하겠다.
2.2.9 Urgent pointer
URG 필드를 설정하면 긴급 메시지를 보낸다. 이 때, 긴급 메시지는 별도의 패킷으로 전송되지 않고, 일반 데이터에 포함되어서 함께 전달된다. 그러므로 운영체제가 긴급 데이터를 읽기 위해서는 긴급 데이터의 위치를 알아야 한다. Urgent pointer는 일반 데이터 내에서 긴급 데이터가 시작되는 위치 정보를 가지고 있다.
2.3 실제 통신상에서 TCP 패킷의 내용을 살펴보자
위에서 각 TCP 필드에 대한 설명을 해보았지만, 솔직히 위의 정보만을 가지고는 뭐가 뭔지 도대체 알수가 없을 것이다. 그래서 이번에는 실제 TCP/IP 통신이 어떻게 이루어지는지에 대해서 알아보고 이러한 통신이 이루어지도록 어떻게 TCP/IP 패킷(세그먼트)가 전송되어지는지 알아보도록 하겠다.
2.3.1 테스트 프로그램 준비
셈플로 알아보는 소켓프로그래밍 에서 제작한 적이 있는 우편번호 서버/클라이언트 프로그램을 이용해서 테스트 하도록 할것이다. 서버 프로그램의 이름은 zipcode 이며 클라이언트 프로그램의 이름은 zipcode_cl 이다.
이와 더불어 tcp/ip 패킷분석을 위해서 tcpdump 를 사용할것이니 준비해놓기 바란다. (아마도 기본 설치되어 있겠지만)
2.3.2 테스트 방법
테스트를 가장 효과적으로 수행하기 위해서는 서버와 클라이언트가 별도의 네트웍에 묶여 있는게 가장 좋겠지만, 여의치 않을경우 하나의 서버에 서버와 클라이언트를 두고 테스트를 해도 관계 없다.
여기에서의 테스트는 서버와 클라이언트가 별도의 네트웍환경에 묶여있는 것을 기준하여 이루어질것이다.
그림 3. 서버/클라이언트 테스트 환경
서버는 Port 번호 4445 로 연결하도록 할것이다.
2.3.3 서버와 클라이언트간의 연결
TCP 는 기본적으로 연결지향의 프로토콜이라고 했다. 이말은 처음 통신을 하기 전에 서로를 연결하는 전용의 통신선로를 개설한다라는 말이 된다. 이는 우리가 전화를 할때
실제 대화를 하기 위해서 서로간에 확인절차를 거치는 것과 마찬가지다.
TCP 도 통신선로를 만들기 위해서 처음에 이러한 확인 절차를 거친다. 우리가 보통 전화상에서 서로의 확인 작업을 위해서 3번 통화가 이루어지는 것처럼 TCP 상에서도 3번의 데이타 전송이 일어난다.
홍길동 : "여보세요 아무개 씨 맞습니까 ?" 아무개 : "내 아무개 입니다." 홍길동 : "아그러세요 저는 홍길동 입니다" ... .... 이런 저런 대화들 .... ...
TCP 도 통신선로를 만들기 위해서 처음에 이러한 확인 절차를 거친다. 우리가 보통 전화상에서 서로의 확인 작업을 위해서 3번 통화가 이루어지는 것처럼 TCP 상에서도 3번의 데이타 전송이 일어난다.
client server
①
Send SYN seq=x ---------------------------> Receive SYN segment
|
② |
Recevie SYN+ACK segment <-------------------------- Send SYN seq=y, ACK x+1
|
| ③
send ACK y+1 --------------------------> Receive ACK segment
이런 이유로 흔히 위의 과정을 "3 way Hand Shaking" 또는 "3번 악수기법" 이라고 한다. 최초에 클라이언트가 seq 번호 x 를 보내면 server 에서는 이 x 에 1 을 더해서 ACK 로 보낸다. 이때 자신의 seq 번호 y 도 포함해서 보낸다. 그러면 클라이언트에서는 server 부터 넘어온 패킷의 ACK가 자신의 seq 번호와 일치하는지 확인하고, 확인이 되면 server 의 seq 번호인 y 에 1을 더해서 ACK로 보낸다. server 에서는 client 가 보낸 ACK 의 번호와 자신의 seq 번호가 일치하는지 확인해서 일치하면 연결이 제대로 되었다는것을 인증하고 데이타 통신에 들어가게 된다.
그럼 tcpdump 를 이용해서 어떻게 위의 3번 악수기법 이 이루어지는 지 확인해 보도록 하겠다. 우선 tcpdump 를 다음과 같은 옵션으로 띄우도록 한다.
그다음에 zipcode_cl 을 이용해서 서버에 접근해보자 그러면 아래와 같은 패킷 dump 화면이 뜰것이다. 1, 2 는 구분하기 쉽도록 필자가 추가시킨 문자이다.
[root@localhost test]# tcpdump -x tcp 4445 Kernel filter, protocol ALL, TURBO mode (575 frames), datagram packet socket tcpdump: listening on all devices ...
13:42:47.952336 eth0 > localhost.2310 > 211.234.96.141.4445: S 2850317194:2850317194(0) win 5840 <mss 1460,sackOK,timestamp 10265185 0,nop,wscale 0> (DF) 4500 003c c1eb 4000 4006 1f2e c0a8 6482 ----- 1 d3ea 608d 0906 115d a9e4 638a 0000 0000 a002 16d0 0cc5 0000 0204 05b4 0402 080a 009c a261 0000 0000 0103 0300 13:42:48.202336 eth0 < 211.234.96.141.4445 > localhost.2310: S 2213490312:2213490312(0) ack 2850317195 win 5792 < mss 1460,sackOK,timestamp 2310931230 10265185,nop,wscale 0> (DF) 4500 003c 0000 4000 3806 e919 d3ea 608d ----- 2 c0a8 6482 115d 0906 83ef 2e88 a9e4 638b a012 16a0 cd8f 0000 0204 05b4 0402 080a 89be 031e 009c a261 0103 0300 13:42:48.202336 eth0 > localhost.2310 > 211.234.96.141.4445: . 1:1(0) ack 1 win 5840 <nop,nop,timestamp 10265210 2310931230> (DF) 4500 0034 c1ec 4000 4006 1f35 c0a8 6482 ----- 3 d3ea 608d 0906 115d a9e4 638b 83ef 2e89 8010 16d0 fc0b 0000 0101 080a 009c a27a 89be 031e3번 악수 기법을 위해서 3번의 패킷이 오고 갔음을 알수 있다. 언뜻 봤을때 절대 이해할수 없을것 같은 숫자로 된 정보들을 뿌려주는데 원리만 알면 간단하게 분석할수 있다. 위의 숫자로 된 정보들이 바로 TCP/IP 세그먼트의 정보를 16 진수로 나타낸 것이다. 4자리씩 구분되어 있는데, 이 4자리의 크기는 16 비트크기를 가진다(하나의 숫자는 4비트이다. 이 정보만 알고 있다면 위의 패킷정보에서 IP 영역과 TCP 영역을 분리해 낼수 있다.
IP 헤더의 크기는 유동적이긴 하지만 기본적으로 5 * (32 bit) 의 크기를 갖는다. 그러므로 1 번 패킷을 높고 보자면 IP 헤더는 다음과 같을 것이다.
정말 IP 헤더 정보가 맞는지 확인해보자. IP 헤더의 첫번째 4bit 는 IP의 버젼을 나타낸다. 위에서 보면 '4' 로 되어 있음으로 이 TCP/IP 패킷은 IPv4 를 이용하고 있음을 알수 있다. c0a8 6482는 source IP, d3ea 608d는 destination IP 이다.
4500 003c c1eb 4000 4006 1f2e c0a8 6482
d3ea 608d
이제 1 번 패킷에서 TCP 헤더 정보를 분석해 보도록 하자. 분석한 데이타는 tcpdump 헤더와 비교하면서 계산하도록 하자. TCP 헤더데이타는 0906 부터이다. TCP 의 처음 16bit 는 SOURCE PORT 다음 16bit 는 DESTINATION PORT 를 나타낸다. 0906 을 계산해 보면(진수변환 되는 계산기로) 2310 이며 115d 를 계산해보면 4445 이다. 정확하게 일치하고 있음을 알수 있다. 클라이언트측의 PORT 번호는 서버측 포트 번호와는 달리 임의의 번호로 할당된다.
우리는 1 번 패킷에서 a9e4 638a 가 시퀀스 넘버임을 유추해낼수 있을것이다. 이것을 계산해 보면 2850317194 임을 알수 있다. ACK는 0000 0000 이다. ACK 는 0000 0000 즉 0 으로 초기화 되어있는데 반해서, 시퀀스 넘버는 0으로 초기화 되어 있지 않다. 실지로 ACK 는 새로운 연결이 이루어질때 마다 0 으로 초기화 되는데 비해 시퀀스 넘버는 새로운 연결이 생길때 마다 임의의 번호로 새로 만들어진다.
Header Length 는 4bit 크기를 가지므로 a002 에서 'a' 임을 알수 있다. 해서 Header Length 는 10(a) 임을 계산할수 있는데, 이때 Length 의 단위는 워드(32 bit) 이다. 그러므로 헤더는 0906 에서 0300 까지의 데이타임을 유추해 낼수 있다.
0906 115d a9e4 638a 0000 0000
a002 16d0 0cc5 0000 0204 05b4 0402 080a
009c a261 0000 0000 0103 0300
즉 최초 세번 악수 기법을 통한 세션 연결시에 오고 가는 3개의 패킷 데이타는 단지 TCP/IP 헤더정보만을 포함하고 있으며, 그외의 아무런 다른 정보도 포함하고 있지 않음을 알수 있다.2.3.4 패킷 분석을 통해서 알아보는 3번 악수 기법 - 연결
이전에 1 패킷을 분석함으로써, 우리는 dump 된 패킷을 분석하는 기본적인 기법을 배웠다. 이 방법들을 토대로 정말로 3번 악수 기법이 제대로 이루어 지는지 한번 확인해 보도록 하겠다.
3번 악수 기법을 보면 알겠지만 가장 핵심이 되는 키워드는 SEQ 번호와 ACK 번호 그리고 패킷의 타입을 나타내는 CODE BITS 이다. 이 세가지 필드의 의 계산만 잘하면 TCP 연결이 어떻게 이루어지는지 이해가 가능할것이다. 그럼 1, 2, 3의 dump 패킷을 분석해서 3번 악수 기법의 흐름을 알아보도록 하자.
- 클라이언트는 자신의 SEQ 를 a9e4 638a (2850317194)로 만들고 . ACK 를 0000 0000 (0) 으로 만들어서 1 패킷을 서버측 측에 보낸다.
- 서버는 클라이언트로 부터 1 패킷을 받는다. SEQ 는 a9e4 638a 인데, 여기에 +1 (a9e4 638b) 를 해서 ACK 를 만든다. 그리고 자신의 SEQ 를 83ef 2e88 로 세팅해서 2 패킷을 만들고 만들어진 패킷을 다시 클라이언트로 보낸다.CODE BITS 를 보면 값이 02 임을 알수 있다. 2 는 2진수로 10 CODE BITS 의 세팅은 00 00 10 으로 되어있음을 알수 있다. 5번째 BIT 는 SYN 비트 임으로 이 패킷은 최초 연결을 시도하기 위한 패킷임을 알수 있다.CODE BITS 를 보면 값이 12 임을 알수 있다. 이것을 2진수로 변경 시켜 보면 10 00 10 이다 그러므로 URG 와 SYN 비트가 세팅되어 있음을 알수 있다.
- 클라이언트는 서버로 부터 2 패킷을 받는다. 2 패킷에서 넘어온 ACK 를 확인해 본다. 최초에 클라이언트가 서버측으로 보낸 SEQ 에 +1 된 값이므로 올바른 데이타임을 확인할수 있다. 이제 2 에서 넘어온 ACK 를 자신의 SEQ 로 설정하고, 2 에서 넘어온 SEQ (83ef 2e88)에 +1 을 해서 3 패킷을 만들고 이것을 서버로 보낸다.
이상 꽤 복잡한것 같지만 곰곰히 생각해 보면 별거 아니란걸 알수 있을것이다.
2.3.5 패킷 분석을 통해서 알아보는 연결 종료
연결과는 좀 다르다. 완전한 종료를 위해서는 아래와 같이 4 번의 패킷 교환이 일어난다.
{
client server
①
Send SYN seq=x ---------------------------> Receive FIN segment
|
② |
Recevie segment <-------------------------- Send ACK x+1
①
Receive FIN + ACK segment <-------------------------- Send FIN seq=y, ACK x+1
|
| ②
Send ACK y + 1 --------------------------> Receive ACK segment
완전한 연결종료를 위해서 위의 zipcode 어플리케이션 대신에 telnet(port 23) 을 이용해서 테스트 하기로 했다. 테스트 방법은 telnet 로 해당 서버에 연결한 연결한 다음 login 프롬프트가 떨어지면 (CTRL + ]) 키를 이용해서 telnet> 프롬프트를 부르고 여기에 quit 를 입력해서 연결을 종료시키는 방법이다.[root@coco test]# telnet 192.168.100.190 Trying 192.168.100.190... Connected to 192.168.100.190. Escape character is '^]'. SunOS 5.8 login: // 여기에서 CTRL+] 입력 telnet> quit이 과정을 tcpdump 로 패킷 덤프 받은 데이타 내용은 다음과 같다.
{
17:03:01.412336 eth0 > localhost.2437 > develop.telnet: F 110:110(0) ack 89 win 5840 <nop,nop,timestamp 11466531 71617405> (DF) 4500 0034 980c 4000 4006 5826 c0a8 6482 ---- 1 c0a8 64be 0985 0017 9d14 6d27 1f57 e476 8011 16d0 3621 0000 0101 080a 00ae f723 0444 cb7d 17:03:01.412336 eth0 < develop.telnet > localhost.2437: . 89:89(0) ack 111 win 10136 <nop,nop,timestamp 71618004 11466531> (DF) 4500 0034 23c2 4000 ff06 0d70 c0a8 64be ---- 2 c0a8 6482 0017 0985 1f57 e476 9d14 6d28 8010 2798 2302 0000 0101 080a 0444 cdd4 00ae f723 17:03:01.412336 eth0 < develop.telnet > localhost.2437: F 89:89(0) ack 111 win 10136 <nop,nop,timestamp 71618005 11466531> (DF) 4500 0034 23c3 4000 ff06 0d6f c0a8 64be ---- 3 c0a8 6482 0017 0985 1f57 e476 9d14 6d28 8011 2798 2300 0000 0101 080a 0444 cdd5 00ae f723 17:03:01.412336 eth0 > localhost.2437 > develop.telnet: . 111:111(0) ack 90 win 5840 <nop,nop,timestamp 11466531 71618005< (DF) 4500 0034 0000 4000 ff06 3132 c0a8 6482 ---- 4 c0a8 64be 0985 0017 9d14 6d28 1f57 e477 8010 16d0 33c8 0000 0101 080a 00ae f723 0444 cdd5패킷 분석방법은 위에서 모두 설명했으니 굳이 다시 설명하진 않겠다. 주의 해서 볼점은 CODE BITS 부분이다. 1 번을 보면 CODE BITS 가 11 로 설정되어 있음을 볼수 있다. 이를 2진수로 변환하면 10 00 01 이다. FIN 비트 가 세팅되어 있음을 알수 있다.
2.3.6 실 데이타 전송
실 데이타를 전송할때는 연결/종료 와 같은 3번 악수 기법에 의한 복잡한 (뭐 그리 복잡하지도 않지만) 그러한 패킷 교환은 없다. 단지 한쪽에서 데이타를 보내면 받은쪽에서는 데이타를 잘 받았다라는 패킷만을 보내게 된다.
이제 실제 데이타가 전송될때의 TCP/IP 패킷의 분석을 해보도록 하자. 여기에서는 다시 zipcode 의 서버/클라이언트가 사용될것이다. zipcode_cl 을 이용해서 서버여 연결하고 "지역이름 입력 : " 프롬프트가 떨어지면 a 를 입력해보도록 하자.
1 에서 실제 데이타를 보내고 있으며 여기에서는 서버측으로 'a' 를 보내게 될것이다. 실제 'a' 를 보내는지 확인을 해보자. IP 헤더의 크기는 (5*32) 로 고정되어 있을것이다. 문제는 TCP 헤더의 크기인데, 8018 에서 8 이 헤더의 크기를 나타냄을 알수 있다. 단위는 워드 이므로 계산을 해보면(8 * 32) 8366 에서 부터 edfc 까지가 TCP 헤더 임을 알수 있다. 그러므로 우리가 보내고자 하는 데이타는 6100 에서 부터가 될것이다. 61 은 'a' 라는걸 알수 있다. - 61 은 10 진수 97 을 나타내며 ASCII 코드를 보면 97 은 'a' 를 나타낸다.
[root@s210-205-210-195 test]# ./zipcode_cl 4445 지역이름 입력 : a 지역이름 입력 :다음은 위의 결과 를 tcpdump 를 이용해서 dump 뜬 결과 이다.
23:32:49.951938 s210-205-210-195.thrunet.ne.kr.33638 > 211.234.96.141.4445: P 1:256(255) ack 1 win 5840 <nop,nop,timestamp 26681991 2314595836> (DF) 4500 0133 484f 4000 4006 176d d2cd d2c3 ---- 1 d3ea 608d 8366 115d 5b9e 5641 872e f2e8 8018 16d0 19eb 0000 0101 080a 0197 2287 89f5 edfc 6100 0000 5066 0140 0100 0000 dc81 0408 9460 0140 0f53 8e07 0f53 8e07 70f7 23:32:49.967321 211.234.96.141.4445 > s210-205-210-195.thrunet.ne.kr.33638: . ack 256 win 6432 <nop,nop,timestamp 2314596983 26681991> (DF) 4500 0034 1f16 4000 3806 49a5 d3ea 608d ---- 2 d2cd d2c3 115d 8366 872e f2e8 5b9e 5740 8010 1920 214f 0000 0101 080a 89f5 f277 0197 2287 23:32:49.971577 211.234.96.141.4445 > s210-205-210-195.thrunet.ne.kr.33638: P 1:256(255) ack 256 win 6432 <nop,nop,timestamp 2314596983 26681991> (DF) 4500 0133 1f17 4000 3806 48a5 d3ea 608d ---- 3 d2cd d2c3 115d 8366 872e f2e8 5b9e 5740 8018 1920 07d6 0000 0101 080a 89f5 f277 0197 2287 656e 6400 7365 6e64 2065 6e64 0a00 0000 0000 0000 0000 001c 9e04 0800 0000 23:32:49.971653 s210-205-210-195.thrunet.ne.kr.33638 > 211.234.96.141.4445: . ack 256 win 6432 <nop,nop,timestamp 26681993 2314596983> (DF) 4500 0034 4850 4000 4006 186b d2cd d2c3 ---- 4 d3ea 608d 8366 115d 5b9e 5740 872e f3e7 8010 1920 204e 0000 0101 080a 0197 2289 89f5 f277
서버에서 데이타를 받았다면 서버는 이에 대한 응답 메시지(저 메시지 잘 받았습니다) 를 클라이언트측에 보내야 할것이다.
2 패킷이 바로 응답 메시지가 된다. 2 패킷의 CODE BITS 를 보면 10 으로 세팅되어 있는데, 이것을 2진수로 변경하면 01 00 00 이 된다. 2번째 비트가 켜져 있는데 2번째 비트는 ACK 를 나타낸다. 그러므로 이 패킷은 응답용 패킷이라는 걸 알수 있다. 그렇다면 2 패킷을 받은 클라이언트는 이게 과연 2 패킷이 1 에 대한 응답 메시지인지를 확인해야 하는데 이는 SEQ 번호와 ACK 번호를 계산함으로써 알나 낼수 있을것이다.
3 번 데이타는 서버측에서 클라이언트로 보내는 패킷의 dump 내용이다. 클라이언트로 보내는 데이타는 "send end" 임을 알아낼수 있을 것이다. 4 번 데이타는 이에 대한 응답으로 클라이언트에서 서버측으로 보내는 패킷 dump 내용이다.