TCP の handshake、teardown、flow control はどう動きますか？

Question

IT Interview Practice · Accepted Answer

TCP は **3-way handshake** でコネクションを確立し、**4-way teardown** でそれを閉じ、**flow control** と **congestion control** でデータを安全に流し続けます。handshake は各側の開始シーケンス番号を同期させ、双方があらゆるバイトを追跡し acknowledge（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** — 現在どれだけのバイト分のバッファ空間があるか — を通知します。送信側は最大でも 1 ウィンドウ分の未 ACK データを飛行中に持てます（**sliding 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、シーケンス番号、ACK は、順序づけと再送の背後にある仕組みです。flow control と congestion control は、1 つのコネクションが遅いクライアントを溺れさせたり共有リンクを崩壊させたりできない理由です。これは実世界の振る舞いを直接説明します — コネクション確立の latency（データの前に 1 往復）、なぜ throughput が最初から全速力ではなく徐々に立ち上がるのか、なぜ長距離リンクでの損失が性能を大きく落とすのか — これらはすべて、ネットワークシステムをチューニングまたはデバッグするときに推論するものです。

なぜ重要なのか

関連する質問