TCP 握手、断连和流量控制是如何工作的？

Question

IT Interview Practice · Accepted Answer

TCP 用一次 **3-way handshake** 建立连接，用一次 **4-way teardown** 关闭它，并靠**流量控制（flow control）**和**拥塞控制（congestion control）**让数据安全地流动。握手同步各方的起始序列号（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 ───────▶│
```

**流量控制**阻止一个快速的发送方压垮一个缓慢的接收方。每一方在每个 ACK 中通告一个 **receive window**——它当前有多少字节的缓冲空间。发送方在途中最多只能有一个窗口的未确认数据（一个 **sliding window**）；如果接收方的窗口收缩到零，发送方就暂停。这是一个*由接收方驱动*的限制。

**拥塞控制**则不同：它保护*网络*（而非接收方）不被压垮。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 *为何*可靠的人区分开来。握手、序列号和 ACK 是顺序与重传背后的机制；流量控制和拥塞控制是为什么单个连接既不会淹没一个缓慢的客户端、也不会拖垮一条共享链路的原因。这直接解释了现实世界的行为——连接建立延迟（有任何数据之前要一个来回）、为什么吞吐量是逐步爬升而不是一开始就满速、以及为什么长距离链路上的丢包会重创性能——所有这些都是你在调优或调试网络系统时需要推理的。

为什么这很重要

相关问题