The three-way TCP handshake

1. The three-way TCP handshake

TCP는 장치들 사이에 논리적인 접속을 성립(establish)하기 위하여 three-way handshake를 사용한다.

Client > Server : TCP SYN
Server > Client : TCP SYN ACK
Client > Server : TCP ACK

여기서 SYN은 'synchronize sequence numbers', 그리고 ACK는'acknowledgment' 의 약자이다.
이러한 절차는 TCP 접속을 성공적으로 성립하기 위하여 반드시 필요하다.

TCP는 windowing을 사용한다. (윈도우는 현재 네트웍 혼잡과 수신 용량에 따라 조정될 수 있는 데이터 플로우의 크기)

구체적인 TCP three-way handshake 과정은 다음과 같다.

요청 단말(클라이언트)은 아래 요소를 포함하는 서버에게 TCP SYN 세그먼트를 송신
- 연결하고자하는 서버의 포트 번호
- 클라이언트의 Initial Sequence Number (ISN)
- 옵션인 Maximum Segment Size (MSS)


TCP SYN ACK
아래와 같은 SYN 정보를 가지고 있는 서버의 응답
- 서버의 ISN
- 클라이언트의 ISN + 1 에 대한 ACK
- 옵션인Maximum Segment Size (MSS)

서버의 SYN에 대한 클라이언트의 ACK (TCP ACK)
- 서버의 ISN + 1

TCP를 통한 TCP 통신의 분석 시, MSS는 접속 시간내에 다른 peer에게 알리며 MSS 옵션이 존재하지 않으면 디폴트로 536 bytes를 사용한다는 사실을 명심하라. (이것은 디폴트 IP MTU인 576 bytes에서 20-bytes의 IP 헤더와 20-bytes의 TCP 헤더를 뺀 값이다.)
옵션인 MSS는 일반적으로 클라이언트와 서버 사이의 경로상의 Maximum Transmission Unit (MTU)에서 프로토콜 오버헤드를 뺀 값이며 네트웍 계층(Network Layer)의 헤더를 포함하고 있다. 예를 들어, Ethernet에 대하여 요구되는 MSS는 1460 bytes 이며 IEEE 802.3에 대한 것은 1452 bytes 이다. (8-byte LLC SNAP 헤더에 대해 허용) 만약 어떤 네트웍 사이에 MTU에 대해 세그먼트 크기가 너무 크면 필요하지 않은 IP Fragmentation이 발생할 수 있음에 주의하라.


2. TCP Retransmissions

TCP는 수신자의 윈도우 크기에 따라서 다수의 TCP 패킷의 데이터를 전송하므로써 시작되며 그 후 수신자의 ACK로 인지 되는 버퍼 크기 (윈도우 크기)가 허용되는 비율만큼 계속 전송된다. 만약, TCP 세그먼트가 ACK를 보지 못하고 패킷이 유실되면 송신자는 반드시 어떤 순차적인 세그먼트를 다시 보내야 한다.
하나의 TCP 패킷 재전송에 대해 오직 하나의 패킷에 대한 재전송으로 생각하지는 말아야 한다.

패킷 재전송이 발생하는 상황:

- 전송되는 TCP 세그먼트 혹은 되돌아온 ACK가 스위치나 라우터에의해서 유실(dropped) 되는 경우
- 패킷이 전송하는 동안 손상될 때 (패킷은 CRC 에러를 가지고 있음)
- 패킷의 TCP 데이터 부분이 스위치나 라우터에 의해서 손상될 때 (TCP 체크섬 에러 발생)
- 수신자가 패킷을 버퍼에 저장할 수 없을 때
- TCP 세그먼트가 fragment 되고 fragment가 손상되거나 유실(dropped) 될때
- ACK가 너무 늦게 돌아오고 송신자가 하나 혹은 그 이상의 세그먼트를 재전송 할 때

만약 ACK가 수신되지 않으면 세그먼트는 다시 전송하지만, 첫번째 대기 시간의 두배가 된다. TCP 스택은 접속의 round-trip 시간에 기반하여 초기 timeout 값을 동적으로 계산한다.
각각의 성공적인 재전송은 이전 시도의 두배로 연기된다. TCP 스택은 포기하기 전에 미리 정해진 시간 만큼 시도할 것이다. Windows 95/98/NT 상에서 디폴트 설정은 5번의 시도로 레지스트리상에 설정되어 있다.

Expert 시스템이 없는 Protocol Analyzer를 가지고도 다음과 같은 3가지 순서에 따라 TCP에 대한 재전송을 인지할 수 있다:

1. Analyzer상의 display 버퍼상에서 통신하고 있는 IP 스테이션의 두쌍에 대한 필터를 적용한다.
2. 성공적으로 전송된 패킷 사이의 대략 1초의 3/1에 해당하는 long delay 혹은 주요 delay들을 관찰한다.
3. 이전의 패킷에 대하여 전송하는 sequence number를 체크한다. 오리지널 전송은 몇몇 패킷 이전에 위치할 수 있음을 명심하라.

각각의 패킷 사이의 long delta 시간과 주요 delay에 지시되는 패킷 재전송을 확인하라.
이러한 패킷 재전송의 증거는 패킷내의 sequence number가 동일하다는 것으로 증명될 수 있다.
즉, TCP 패킷 재전송은 sequence number가 동일하다는 것을 의미한다.

몇 가지 경우, Analyzer의 버퍼 상에 왜 그런 재전송이 발생하는 지에 대한 실마리가 이미 있다.
몇 가지 가능성은 다음과 같다.

- 이전 세그먼트 혹은 ACK가 CRC 에러를 가지고 있다. (Ethernet상)
- 토큰링 상에서 스테이션은 대략 2초후에 소프트 에러를 보고한다.
- 이전 패킷에서 TCP 체크섬 에러는 가능한 브리지 혹은 라우터의 손상을 나타낸다.
- 이전 패킷의 TCP 체크섬 에러와 현재 패킷이 재전송되고 있는 패킷은 송신자의 문제이다.
(예를 들면, TCP 체크섬이 올바르게 계산되지 않을 수 있다.)
- 유실되거나 지연된 ACK가 있을 경우, Analyzer를 다른 세그먼트로 이동해서 문제를 정확하게 지적해야 한다.

만약 특정한 서버나 워크스테이션에서 많은 수의 TCP 재전송이 의심되면 netstat 명령어를 사용할 수 있다.
Netstat 명령의 일반적인 사용 (netstat –r)으로 라우팅 정보 - 예를들면 서버나 워크스테이션과 연관된 라우터등의 route table 등 – 를 얻을 수 있다. Netstat 명령으로 또한 “netstat –s” 를 사용하여 프로토콜 통계에 대한 정보를 얻을 수 있다. Windows 95/98/NT 상의 netstat 명령은 특정 프로토콜을 명시할 수 있다.
예를 들어, “netstat –s –p tcp” 명령으로 특정 NT 서버의 대한 다음과 같은 정보들을 얻을 수 있다.

C:\>netstat -s -p tcp

TCP Statistics

Active Opens = 204
Passive Opens = 734
Failed Connection Attempts = 2
Reset Connections = 263
Current Connections = 2
Segments Received = 44759
Segments Sent = 26058
Segments Retransmitted = 15

Active Connections

Proto Local Address Foreign Address State
TCP elca:1123 64.12.24.58:5190 ESTABLISHED
TCP elca:1549 203.231.222.194:pop3 TIME_WAIT
TCP elca:1553 203.231.222.194:pop3 TIME_WAIT
TCP elca:31510 test.iworld.co.kr:1635 ESTABLISHED

상기의 netstat 예제를 보면 26,058 TCP 세그먼트가 서버에 의해 전송되었고 15개의 재전송이 발생하였다. 이것은 1% 보다 작다. 만약, 퍼센트가 이보다 높아진다면 다음 순서는 Analyzer를 서버의 세그먼트에 Tapping하여 TCP 트래픽을 조사해야 한다.

Sniffer Expert System의 Symptom 설명

- 중요도: Minor

- 현상: 이 메시지는 특정 TCP 패킷의 순서 번호가 이전 것과 비교하여 같거나 작을 때, 즉 이전에 이미 전송된 TCP 세그먼트에 대한 ACK 신호를 받지 못하여 시간 초과 상태에서 해제되었던 패킷이 재전송되었을 경우에 발생한다.

- 원인:
. 네트웍 트래픽이 정체되었을 경우
. 수신하는 스테이션이 과부하 상태인 경우
. 라우터가 과부하 상태이거나 다른 이유로 전송지연이 되는 경우
. ACK 신호를 보냈지만 유실된 경우
. 원래의 패킷이나 ACK이 손상을 입은 경우
. ACK 신호가 늦은 경로로 전송되었을 경우
. IP 조각을 읽어버린 경우
. 네트워크의 완결성에 문제가 있는 경우
[이 게시물은 아쿠아님에 의해 2007-05-05 13:51:42 시스템자료실에서 이동 됨]