TCP流量与拥塞控制
数据传输中有两个”发太快”的问题：
- 接收方处理不过来 → 流量控制，接收方说了算
- 网络本身堵了 → 拥塞控制，发送方自己判断
两个机制共同决定发送窗口的大小：
- ：接收窗口，接收方缓冲区剩余空间，接收方在 ACK 里告知
- ：拥塞窗口，发送方根据网络状况自己维护
- ：实际发送窗口，取两者最小值
流量控制
接收方缓冲区满了，就在 ACK 里把 rwnd 设为 0，发送方收到后停止发送。
零窗口问题：窗口空出来了，但接收方发的”窗口恢复”报文丢了，双方就会僵住。解决方法是发送方定时发探测报文，主动问接收方窗口是否恢复。
为什么不让接收方主动通知？因为如果网络已经堵死，接收方的通知也发不出去，还是会僵住。发送方探测才能确认是接收方没处理完，而不是网络不通。
拥塞控制
发送方通过丢包信号判断网络是否拥堵，动态调整 cwnd。
慢启动
起步阶段，cwnd 从 1 开始，每收到一个 ACK 就翻倍（1→2→4→8…），增长极快。
增长到 ssthresh（慢启动门限） 时停止，切换到拥塞避免。
拥塞避免
每经历一个 RTT，cwnd 只加 1，线性增长，小心试探网络上限。
超时重传时
网络严重拥堵，惩罚最重：
- ssthresh 降为当前 cwnd 的一半
- cwnd 重置为 1
- 重新进入慢启动
快恢复
连续收到 3 个重复 ACK，说明网络还没彻底堵死：
- ssthresh 降为当前 cwnd 的一半
- cwnd 直接设为新的 ssthresh
- 跳过慢启动，直接进入拥塞避免
如果你正在跟随梳理, 返回 TCP←