[Nework] TCP 3-way Handshake, 4-way Handshake, TIME_WAIT 정리

1. 문서 제목 제안

• TCP 3-way Handshake, 4-way Handshake, TIME_WAIT 정리

---

2. 기술 개요 요약

TCP는 연결 지향 전송 프로토콜이다. 데이터를 보내기 전에 3-way handshake로 양쪽의 송수신 가능 상태와 초기 sequence number를 확인하고, 연결 종료 시에는 각 방향의 송신을 독립적으로 닫기 위해 일반적으로 FIN, ACK, FIN, ACK 흐름을 사용한다. 마지막 ACK를 보낸 쪽은 바로 연결 상태를 제거하지 않고 TIME_WAIT 상태로 잠시 대기한다. 이는 마지막 ACK 유실에 대응하고, 이전 연결의 지연 세그먼트가 같은 4-tuple의 새 연결에 섞이는 것을 방지하기 위한 목적이다.

---

3. 핵심 기능/개념 정리

3-1. TCP 기본 특성

항목	설명	실무 포인트
연결 지향	데이터 전송 전 연결 상태를 수립	3-way handshake 필요
신뢰성	손실 시 재전송, ACK 기반 확인	handshake만으로 신뢰성이 완성되는 것은 아님
순서 보장	sequence number로 데이터 순서 추적	수신 측에서 재조립 가능
흐름 제어	수신자가 처리 가능한 만큼 전송	receiver window
혼잡 제어	네트워크 혼잡에 따라 전송량 조절	slow start, congestion avoidance 등

3-2. 주요 플래그와 번호

개념	의미	설명
SYN	synchronize	연결 시작 시 sequence number 동기화
ACK	acknowledgment	상대 세그먼트 수신 확인
FIN	finish	더 이상 보낼 데이터가 없음을 알림
Sequence Number	송신 데이터의 순서 번호	TCP byte stream 순서 추적
ACK Number	다음에 받기를 기대하는 번호	“여기까지 받았다”는 의미

3-3. 3-way handshake

Client                              Server
  | -------- SYN(seq=x) ----------> |
  | <---- SYN(seq=y) + ACK(x+1) --- |
  | -------- ACK(y+1) ------------> |

단계	방향	의미
1	Client -> Server: SYN	클라이언트가 연결 요청과 초기 sequence number 전달
2	Server -> Client: SYN + ACK	서버가 클라이언트 SYN을 확인하고 자신의 SYN 전달
3	Client -> Server: ACK	클라이언트가 서버 SYN을 확인

3번이 필요한 이유:

확인할 것	확인 시점
클라이언트가 보낼 수 있음	서버가 SYN 수신
서버가 받을 수 있음	서버가 SYN 수신
서버가 보낼 수 있음	클라이언트가 SYN+ACK 수신
클라이언트가 받을 수 있음	클라이언트가 SYN+ACK 수신
서버가 “클라이언트가 내 SYN을 받았다”는 사실을 앎	마지막 ACK 수신

3-4. 4-way handshake

Client                              Server
  | -------- FIN -----------------> |
  | <------- ACK ------------------ |
  | <------- FIN ------------------ |
  | -------- ACK -----------------> |

단계	방향	의미
1	Client -> Server: FIN	클라이언트가 더 이상 보낼 데이터가 없다고 알림
2	Server -> Client: ACK	서버가 FIN 수신을 확인
3	Server -> Client: FIN	서버도 더 이상 보낼 데이터가 없다고 알림
4	Client -> Server: ACK	클라이언트가 서버 FIN 수신을 확인

4번인 이유:

• TCP 연결은 양방향 byte stream이다.
• 한쪽이 FIN을 보냈다는 것은 그쪽 송신 방향만 닫겠다는 뜻이다.
• 상대방은 아직 보낼 데이터가 남아 있을 수 있다.
• 따라서 FIN 수신 ACK와 자신의 FIN이 분리될 수 있다.

상대도 바로 닫을 준비가 되어 있다면 FIN과 ACK가 합쳐져 실제 패킷 수가 줄어드는 경우도 있지만, 기본 개념은 양방향 종료를 각각 처리한다는 점이다.

3-5. TIME_WAIT

항목	설명
누가 들어가나	일반적으로 active close를 수행하고 마지막 ACK를 보낸 쪽
목적 1	마지막 ACK가 유실되면 상대의 FIN 재전송에 다시 ACK하기 위함
목적 2	이전 연결의 지연 세그먼트가 새 연결에 섞이는 것 방지
영향	같은 4-tuple 재사용이 일정 시간 제한될 수 있음

RFC 9293은 TIME-WAIT 상태를 남은 세그먼트가 네트워크에서 사라질 충분한 시간이 지나기를 기다리는 상태로 설명한다.

---

4. 사용 예시 및 코드 스니펫

4-1. 연결 수립 흐름

SYN
  -> 클라이언트 초기 sequence number 전달

SYN + ACK
  -> 서버 초기 sequence number 전달
  -> 클라이언트 SYN 수신 확인

ACK
  -> 서버 SYN 수신 확인

4-2. 연결 종료 흐름

FIN
  -> 나는 더 이상 보낼 데이터가 없다

ACK
  -> 네 FIN은 받았다

FIN
  -> 나도 더 이상 보낼 데이터가 없다

ACK
  -> 네 FIN도 받았다

4-3. 면접 답변 예시

3-way handshake는 TCP 연결 수립 과정입니다.
클라이언트가 SYN을 보내고, 서버가 SYN-ACK로 응답한 뒤,
클라이언트가 마지막 ACK를 보내면 양쪽의 초기 sequence number와
송수신 가능 상태가 확인되어 연결이 수립됩니다.

4-way handshake는 TCP 연결 종료 과정입니다.
TCP는 양방향 통신이므로 한쪽이 FIN을 보내도 상대방은 아직 보낼 데이터가
남아 있을 수 있습니다. 그래서 FIN 수신에 대한 ACK를 먼저 보내고,
자신의 송신이 끝난 뒤 별도의 FIN을 보내는 흐름으로 설명합니다.

---

5. 실제 사용 시 주의점 / Best Practice

5-1. 3-way handshake는 “인사”가 아니라 sequence number 동기화다

단순히 연결 전에 인사한다고 설명하면 꼬리질문에서 약하다. SYN은 초기 sequence number를 동기화하고, ACK는 상대가 보낸 sequence를 받았음을 확인하는 역할을 한다.

5-2. TCP 신뢰성은 handshake 이후에도 계속 작동한다

3-way handshake는 연결 시작 조건을 맞추는 과정이다. 실제 데이터 전송 중에는 sequence number, ACK, retransmission, flow control, congestion control이 계속 작동한다.

5-3. 연결 종료가 항상 물리적으로 4개 패킷인 것은 아니다

개념적으로는 양쪽 송신 방향을 각각 닫기 때문에 FIN/ACK 한 쌍씩 필요하다. 다만 상황에 따라 FIN과 ACK가 한 패킷에 합쳐질 수 있다.

또한 양쪽이 거의 동시에 close를 수행하는 simultaneous close에서는 상태 전이가 일반적인 "한쪽 FIN -> ACK -> 반대쪽 FIN -> ACK" 설명과 다르게 보일 수 있다. 면접에서는 일반적인 active close 흐름을 기준으로 설명하되, 실제 TCP 상태 머신에는 예외 흐름이 있음을 덧붙이면 안전하다.

5-4. TIME_WAIT은 비효율이 아니라 안전장치다

TIME_WAIT이 많으면 포트 고갈이나 리소스 문제가 생길 수 있지만, 무조건 없애야 하는 대상은 아니다. 마지막 ACK 유실 대응과 지연 세그먼트 격리를 위한 TCP 안전장치다.

5-5. 면접 답변으로 압축하기

3-way handshake는 TCP 연결 수립 과정입니다. 클라이언트가 SYN을 보내 초기 sequence number를 전달하고, 서버는 SYN-ACK로 이를 확인하면서 자신의 sequence number를 보냅니다. 마지막으로 클라이언트가 ACK를 보내면 양쪽의 송수신 가능 상태와 초기 sequence number가 확인됩니다. 4-way handshake는 연결 종료 과정입니다. TCP는 양방향 통신이라 한쪽이 FIN을 보내도 상대는 아직 보낼 데이터가 남아 있을 수 있어, FIN에 대한 ACK와 자신의 FIN이 분리될 수 있습니다. 마지막 ACK를 보낸 쪽은 TIME_WAIT에 머물러 ACK 유실 시 FIN 재전송에 대응하고 이전 연결의 지연 세그먼트가 새 연결에 섞이는 것을 막습니다.

---

검증 메모

• TCP 상태 전이와 TIME-WAIT 설명은 RFC 9293 기준으로 확인했다.
• TIME_WAIT은 active close 이후 2MSL 대기와 FIN 재전송 ACK 처리가 핵심임을 유지했다.
• 4-way 종료가 항상 물리적 4패킷이라는 오해를 막기 위해 FIN+ACK 결합과 simultaneous close caveat을 보완했다.

6. 참고자료 / 공식 문서 출처

• RFC 9293: Transmission Control Protocol
  https://datatracker.ietf.org/doc/html/rfc9293
• RFC 793: Transmission Control Protocol
  https://www.rfc-editor.org/info/rfc793/
• RFC 1122: Requirements for Internet Hosts — Communication Layers
  https://datatracker.ietf.org/doc/html/rfc1122