[전송 계층] TCP 4-way handshake 및 TCP 리셋과 타이머

 

 TCP는 세션 연결을 설정할 때 3-way handshaking을 사용하며, 세션 종료를 위해 4-way handshaking 과정을 수행한다. 연결 설정 시 SYN 플래그가 사용되는 것처럼, 세션 종료 시에는 FIN(Finish) 플래그가 활용된다.

 

TCP 세션 종료는 크게 두 가지 방식으로 일반적인 종료 방식과 동시 종료 방식으로 나뉜다.

 

1. TCP 정상 종료의 4-way Handshake

 TCP 연결 종료는 일반적으로 4-way 핸드셰이킹 과정을 통해 이루어진다. 이 과정은 양방향으로 데이터를 주고받는 연결을 안전하게 종료하기 위한 절차이다.

 

- 4-way Handshaking 과정

클라이언트의 종료 요청	클라이언트는 애플리케이션으로부터 연결 종료 요청을 받고, FIN 세그먼트를 서버로 전송하며 FIN-WAIT-1 상태로 전이함.   · 이 상태에서 클라이언트는 여전히 서버로부터 데이터를 수신할 수 있음.   · 동시에 서버의 ACK 응답을 기다림.
서버의 ACK 전송	서버는 클라이언트로부터 FIN 세그먼트를 수신한 뒤, 이를 확인하기 위해 ACK 세그먼트를 클라이언트에 전송함.   · 이후 서버는 CLOSE-WAIT 상태로 전이하며, 애플리케이션에 연결 종료를 알리고 프로세스가 종료되기를 기다림.   · 클라이언트는 서버로부터 ACK를 수신한 후, FIN-WAIT-2 상태로 전이하며 서버의 종료를 기다림.
서버의 종료 통보	서버 애플리케이션이 종료되면 서버는 FIN 세그먼트를 클라이언트로 전송하며, LAST-ACK 상태로 전이함.   · 클라이언트는 이 FIN을 수신하면 종료 확인 응답을 준비함.
클라이언트의 ACK 응답 및 종료 대기	클라이언트는 서버로부터 FIN을 수신한 후, 확인 응답인 ACK 세그먼트를 서버로 전송하고 TIME-WAIT 상태로 전이함.   · TIME-WAIT 상태에서는 최대 세그먼트 생명 기간(MSL)의 두 배 동안 대기 후, 최종적으로 CLOSED 상태로 전이하며 연결을 종료함.   · 서버는 클라이언트의 ACK를 수신한 직후, CLOSED 상태로 전이하여 연결을 종료함.

 

- TIME-WAIT 상태의 역할

TIME-WAIT 상태는 TCP 연결 종료의 안정성을 보장하기 위해 필요한 단계로, 다음과 같은 역할을 수행한다.

ACK 재전송 시간 확보	클라이언트가 서버로 전송한 ACK 세그먼트가 손실된 경우, 이를 재전송할 수 있는 충분한 시간을 제공함
순서 번호 재사용 방지	이전 세션의 종료와 새로운 세션 간에 충분한 간격을 두어, 기존 세션에서 사용된 순서 번호가 새로운 세션에서 혼란을 일으키지 않도록 방지함

 

- TIME-WAIT 상태와 MSL

MSL(Maximum Segment Lifetime)은 네트워크 상에서 세그먼트가 유효한 최대 시간이다.

• TCP 표준에서는 MSL을 2분으로 정의하지만, 실제 구현에서는 시스템에 따라 수정 가능하다.
• 예를 들어, Windows 시스템(Windows XP, 2003)에서는 기본 TIME-WAIT 대기 시간이 240초(0xF0)로 설정되어 있으며, 최소 권장 값은 30초(0x1E)이다.

- TIME-WAIT 대기 시간 조정 방법(Windows 기준)

레지스트리 편집기 실행	시작 > 실행 > regedit 입력 후 확인.
레지스트리 경로 이동	HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters 경로로 이동.
값 수정	TcpTimeWaitDelay (REG_DWORD) 값을 원하는 값(예: 0x1E)으로 설정.

 

 

- 조정 효과

TIME-WAIT 상태 세션의 빠른 해제	TIME-WAIT 상태의 세션을 빠르게 종료하여 새로운 세션 설정 시간을 단축할 수 있음.
TCP 처리 성능 향상	많은 세션이 존재하는 애플리케이션 환경에서 TCP 성능을 최적화할 수 있음.

※ 참고 : FIN-WAIT-2와 CLOSE-WAIT 상태  TCP 통신 중 클라이언트 애플리케이션에서 문제가 발생하면 서버에도 영향을 미칠 수 있다. 이러한 상황에서 자주 언급되는 상태로는 FIN-WAIT-2와 CLOSE-WAIT가 있다.  FIN-WAIT-2 상태는 서버가 능동적으로 세션을 종료하기 위해 FIN 패킷을 클라이언트로 전송하고, 클라이언트로부터 ACK 응답을 받은 상태이다. 이와 동시에 클라이언트는 CLOSE-WAIT 상태로 전환된다. 문제는 클라이언트가 FIN 패킷을 보내기 전에 애플리케이션이나 클라이언트 자체가 중단되거나, 클라이언트 또는 서버 프로그램에 존재하는 버그로 인해 이를 제대로 처리하지 못할 경우 서버에 FIN-WAIT-2 상태가 계속 유지될 수 있다는 점이다. TCP 프로토콜의 특성상 FIN-WAIT-2 상태는 타임아웃 값이 기본적으로 정의되어 있지 않으므로, 서버를 재시작하기 전까지 이러한 상태가 지속될 가능성이 있다.  이 상태가 장시간 유지되면 서버가 새 TCP 세션을 처리할 수 있는 자원이 고갈될 수 있다. TCP 세션의 수는 서버에서 처리 가능한 한계를 가지고 있기 때문에, FIN-WAIT-2 상태가 많아질 경우 신규 세션 연결이 어려워지고 서비스 장애로 이어질 수 있다. 이 문제를 해결 방법은 다음과 같다.   1. 버그 수정: 근본적인 해결책은 클라이언트와 서버 애플리케이션의 버그를 수정하는 것다. 대부분의 FIN-WAIT-2 문제는 소프트웨어의 결함으로 인해 발생한다. 이를 해결하기 위해 소스 코드를 점검하고 수정해야 한다.   2. SO_LINGER 옵션 사용: 아파치 웹 서버 등에서는 lingering_close() 대신 SO_LINGER 옵션을 사용하도록 권장한다. 이를 통해 세션 종료를 보다 효과적으로 처리할 수 있다.   3. 타임아웃 값 설정: 일부 유닉스 시스템(Solaris, HP/UX, Linux 등)에서는 FIN-WAIT-2 상태에 대해 타임아웃 값을 설정할 수 있는 옵션을 제공한다. 이는 RFC 793을 엄격히 따르지 않는 방식이지만, 문제를 완화하는 실질적인 해결책이 될 수 있다.   4. TCP 유지 타이머 사용: AIX와 같은 유닉스 시스템은 Keepalive Timer를 제공하여 FIN-WAIT-2 상태를 관리한다. 이는 최근의 slow read DoS 공격 방어를 위해서도 활용되며, 비정상적인 세션을 종료하는 데 유용하다. 이와 같은 방법들을 활용하면 FIN-WAIT-2 상태의 지속으로 인한 서버 자원 문제를 예방하고, 안정적인 서비스 운영이 가능해진다.

 

2. 동시 연결 종료의 4-way handshake

 동시 연결 종료(Simultaneous Close)는 클라이언트와 서버가 서로 FIN 세그먼트를 전송하며 동시에 세션 종료 절차를 진행하는 방식이다. 이는 두 시스템이 서로 상호작용하며 세션을 종결하지만, 실제로 시간적으로 완전히 동시에 종료되는 것을 의미하지는 않는다.

 

- 동시 연결 종료 과정

클라이언트의 FIN 전송	- 클라이언트가 능동 종료를 수행하기 위해 FIN 세그먼트를 서버로 전송함. - 서버는 이 FIN에 대해 ACK를 보내는 대신, FIN 세그먼트를 전송하여 종료를 요청함.
서버의 FIN 전송	- 서버는 클라이언트로부터 FIN을 수신한 뒤, 자신도 종료를 요청하는 FIN 세그먼트를 즉시 클라이언트에 전송함. - 양측은 서로 FIN을 수신하며, 종료 요청이 대칭적으로 이루어짐.
확인 응답(ACK) 전송	- 클라이언트와 서버는 각각 상대방으로부터 FIN을 수신한 후, 이를 확인하는 ACK 세그먼트를 전송함.
TIME-WAIT 상태	- 동시 연결 종료 상황에서는 클라이언트뿐만 아니라 서버도 TIME-WAIT 상태를 가질 수 있음. - 각 시스템은 TIME-WAIT 상태에서 일정 시간 대기 후 CLOSED 상태로 전이하여 연결을 완전히 종료함.

 

- 동시 연결 죵료의 특징

대칭적인 상태 전이	클라이언트와 서버는 서로 동등한 입장에서 연결 종료를 진행하므로 TCP 상태 전이가 대칭적임.
PUSH 플래그 활용	연결 종료 시, 각 TCP는 남아 있는 데이터를 애플리케이션으로 즉시 전송하기 위해 PUSH 플래그를 사용함. 이는 데이터를 지체 없이 처리하고 세션을 종료하기 위한 절차임.
TIME-WAIT 상태	동시 연결 종료 상황에서는 서버 역시 TIME-WAIT 상태를 갖음. 이는 ACK 손실 시 재전송을 보장하고, 세션 혼선을 방지하기 위한 시간 대기임.

 

- 동시 연결 종료의 중요성

 동시 연결 종료는 대칭적인 종료 과정을 통해 데이터 무결성을 유지하고, 효율적인 세션 관리를 가능하게 한다. 서버와 클라이언트가 동등하게 FIN과 ACK를 교환하며, 이를 통해 TCP의 안정성과 신뢰성을 강화할 수 있다.

 

3. TCP 리셋(TCP Reset)

 TCP 리셋(Reset, RST)은 TCP 헤더의 코드 비트 중 하나로, 가상 회선(TCP 세션)을 강제로 종료하고 세션을 재설정하도록 유도한다. 이는 주로 비정상적인 TCP 통신 상황에서 발생한다.

 

- TCP 리셋이 발생하는 주요 상황

사용되지 않는 포트로 SYN 요청이 전송된 경우	- 서버 애플리케이션(데몬)이 Listen 상태가 아닌 포트 번호로 SYN 요청을 수신하면, 해당 연결을 거부하기 위해 RST를 전송함. - 또한, 초기 연결 과정에서 하프오픈(half-open) 상태로 대기 중인 연결의 백로그(backlog)가 초과되거나, 대기 시간이 초과된 경우에도 RST가 발생함.
세션이 없는 상태에서 세그먼트를 수신한 경우	- 세션이 맺어지지 않은 상태에서 TCP 세그먼트를 수신하면, 시스템은 RST를 전송하여 해당 세그먼트를 거부함.
잘못된 순서 번호 또는 확인 응답 번호를 포함한 세그먼트 수신 시	- 순서 번호(sequence number)나 확인 응답 번호(ACK number)가 예상 범위를 벗어난 세그먼트를 수신하면 RST를 통해 이를 재설정함.
중단 해제를 수행하는 경우	- 특정 상황에서 가상 회선을 강제적으로 종료(abort release)할 필요가 있을 때, FIN 대신 RST를 사용해 연결을 즉시 해제함.

 

- TCP 리셋의 특징

FIN과의 차이점	- FIN 종료는 정상적인 세션 종료 절차를 따르며, 큐에 대기 중인 데이터를 모두 전송한 뒤 종료됩니다. 이를 정규 해제(Orderly Release)라고 하며 데이터 손실이 발생하지 않음. - 반면, RST 종료는 데이터 대기 여부와 관계없이 즉시 연결을 종료하며, 대기 중인 데이터는 모두 폐기됨.
수신 측의 반응	- RST를 수신한 시스템은 이를 강제 중단(Forced Termination)으로 간주하며, 해당 TCP 세션을 즉시 종료함.

 

- TCP 리셋의 활용과 주의점

정상적인 상황에서 RST 사용은 지양	- TCP 리셋은 비정상적인 연결 상황에서 주로 사용되며, 의도적으로 남용되면 네트워크의 신뢰성을 저하시킬 수 있음.
데이터 손실 가능성	- RST를 통한 세션 종료 시 대기 중인 데이터가 손실될 수 있으므로, 안정적인 데이터 전송이 요구되는 상황에서는 FIN을 활용한 정규 종료를 사용하는 것이 적절함.

 

TCP 리셋은 비정상적인 연결 상황을 빠르게 정리하는 유용한 도구이지만, 데이터 무결성을 유지해야 하는 경우에는 주의 깊게 사용해야 합니다.

 

4. TCP 타이머

TCP는 동작을 위해 타이머를 관리하는데, 타이머에는 휴면 세션에 대한 검사를 위해 사용되는 유지 타이머(Keepalive Timer), 제로 윈도우 크기(Zero Window Size)의 갱신을 확인하기 위한 지속 타이머(Persist Timer), 상대로부터 응답을 기대하는 대기 만료 시간인 재전송 타이머(Retransmission Timeout, RTO), 가상 회선의 종료 전 연결이 TIME_WAIT 상태에서 머무는 2MSL 타이머 등 4가지다.

 

(1) TCP 유지 타이머(Keepalive Timer)

역할	장시간 유휴 상태인 연결을 탐지해 세션 종료 여부를 확인.
작동 방식	- 연결 유지를 위해 주기적으로 데이터 없는 널(Null) 세그먼트를 전송. - 수신자가 응답하지 않으면 연결 종료.
사용 이유	비정상적인 세션 지속 방지 (예: 한쪽 시스템의 비정상적 종료
기본값 (Windows)	2시간 (7,200,000ms)
조정 방법 (Windows)	- regedit 실행. - HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters로 이동. - KeepAliveTime 값을 생성하거나 수정 (msec 단위).

 

(2) TCP 지속 타이머(Persist Timer)

역할	- 수신 윈도우 크기가 0(Zero Window Size) 상태에서 갱신 여부를 확인
작동 방식	- 송신자는 지속적으로 길이가 0인 윈도우 탐색(Window Probe) 세그먼트를 전송. - 수신자가 윈도우 개방을 확인하면 정상적인 데이터 전송 재개.
목적	- 윈도우 갱신 세그먼트가 손실될 경우 교착 상태(Deadlock)를 방지.

 

(3) TCP 재전송 만료 타이머(Retransmission Timer, RTO)

역할	데이터 세그먼트의 손실을 감지하고 재전송 시점을 결정.
작동 방식	- 세그먼트 전송 시 타이머 시작. - ACK 수신 실패 시 재전송 및 타이머 간격 증가 (지수적 백오프). - 기본값: 약 3초 (대부분 시스템에서는 1초 이하로 구현).
재전송 횟수	- 기본값: 최대 5회. - 조정 방법 (Windows):   · regedit 실행.   · HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters로 이동.   · TcpMaxDataRetransmissions 값을 생성하거나 수정.

 

(4) 2MSL 타이머(2 Maximum Segment Lifetime, MSL).

역할	연결 종료 후 TIME_WAIT 상태에서 패킷의 재전송 및 중복 제거 보장.
기간	두 배의 최대 세그먼트 생존 시간(Maximum Segment Lifetime, MSL).