TCP handshake, teardown, flow control은 어떻게 동작하는가?

Question

IT Interview Practice · Accepted Answer

TCP는 **3-way handshake**로 연결을 수립하고, **4-way teardown**으로 닫으며, **flow control**과 **congestion control**로 데이터가 안전하게 흐르게 유지한다. handshake는 양쪽의 시작 sequence number를 동기화하여 둘 다 모든 바이트를 추적하고 확인(ACK)할 수 있게 한다:

```text
   3-WAY HANDSHAKE (open)                4-WAY TEARDOWN (close)
 Client            Server              Client            Server
   │──── SYN ───────▶│                   │──── FIN ───────▶│
   │◀── SYN, ACK ────│                   │◀──── ACK ───────│
   │──── ACK ───────▶│                   │◀──── FIN ───────│
   │   connected     │                   │──── ACK ───────▶│
```

**Flow control**은 빠른 송신자가 느린 수신자를 압도하는 것을 막는다. 각 측은 모든 ACK에 **receive window** — 현재 버퍼 공간이 있는 바이트 수 — 를 광고한다. 송신자는 확인되지 않은 데이터를 최대 한 window만큼만 전송 중에 둘 수 있고(**sliding window**); 수신자의 window가 0으로 줄면 송신자는 멈춘다. 이것은 *수신자 주도*의 한계다.

**Congestion control**은 다르다: 그것은 (수신자가 아니라) *네트워크*를 과부하로부터 보호한다. TCP는 성공하면 커지고 패킷 유실 시 줄어드는 **congestion window**를 유지한다(유실은 혼잡 신호로 읽힌다). slow start와 CUBIC 같은 알고리즘은 점진적으로 올렸다가 유실이 나타나면 물러난다:

```text
cwnd
 │        /\        /\
 │       /  \      /  ...   loss → halve/back off, then probe up again
 │      /    \    /
 │  ___/      \__/
 └───────────────────────▶ time
```

TCP가 실제로 보내는 양은 `min(receive window, congestion window)` — 수신자와 네트워크 양쪽에 의해 제한된다.

## 왜 중요한가

이 질문은 "SYN-SYN/ACK-ACK"를 암기한 지원자를 TCP가 *왜* 신뢰할 수 있는지 이해하는 지원자와 갈라놓는다. handshake, sequence number, ACK는 순서와 retransmission 뒤의 메커니즘이고; flow control과 congestion control은 하나의 연결이 느린 클라이언트를 익사시키거나 공유 링크를 무너뜨리지 못하는 이유다. 이것은 실제 동작을 직접 설명한다 — 연결 설정 지연(데이터 전에 한 번의 round trip), throughput이 최고 속도로 시작하지 않고 점차 올라가는 이유, 장거리 링크에서의 유실이 성능을 무너뜨리는 이유 — 이 모두는 네트워크 시스템을 튜닝하거나 디버깅할 때 추론하는 것들이다.

왜 중요한가

관련 질문