08-拥塞控制

网络设计第八问：拥塞控制——慢启动、拥塞避免、快重传

流量控制是接收方说了算。拥塞控制是发送方自己估——根据丢包、RTT——猜"现在网络中能承受多少数据"。这个猜难在哪里？你不知道中间路由器的缓冲区大小。而这个大小随每一次拥堵而变。

一、为什么需要拥塞控制

发送方拼命发——路由器排队——缓冲区满了——丢包——丢包触发重传——全网都是重传包——有效吞吐跌到零。这不是接收方的问题——是网络链路本身承载不了。

拥塞控制不给发送方一个固定的上限——它根据当前网络的拥塞情况——动态调整发送速率。丢包了→减小速率。没丢包→慢慢增大速率。

二、慢启动——不是你想象的那样

慢启动不是慢——是指数增长。开始窗口=1个 MSS（最大报文段长）——收到一个 ACK→窗口+1——窗口从 1→2→4→8→16→…——每 RTT 翻一倍。

为什么叫"慢"？不是增速慢——是起点小。正常窗口可能几百或几千——慢启动从 1 开始——虽然增长快——但初始值低——总体在前期是保守的。

阈值——当窗口超过 ssthresh——从慢启动切换为拥塞避免——线性增长。

三、拥塞避免——每 RTT 加 1

持续增加窗口直到丢包——窗口每 RTT 增加 1 个 MSS——增速平缓——避免突然冲垮网络——但也不能断掉——持续在网络容量边缘试探。

当检测到丢包——两种处理：

• 超时重传（RTO）——很可能发生了严重拥塞——把 ssthresh 设为当前窗口的一半——窗口退回 1——重新开始慢启动
• 快重传（3个重复ACK）——后面三个包到了——中间一个丢了——阻塞程度不严重——ssthresh=窗口/2——窗口=ssthresh+3——直接进入拥塞避免——不重新慢启动

四、丢包 ≠ 拥塞

现代网络更复杂——一个 Wi-Fi 干扰丢包——信号层问题——不是链路满——而传统 TCP 把它当拥塞——窗口减半——吞吐白跌。

BRR 基于 RTT 而非丢包——RTT 开始变大→缓冲区在满的边缘→开始减速——不等丢包。比丢包信号更精确——在 Wi-Fi 和卫星链路等误码高的环境下——BRR 不白减速。

五、社保系统里的现实

社保结算平台到银行之间的链路——RTT 15ms——带宽 100Mbps——丢包率极低。拥塞控制在这个链路上几乎不被触发——因为队列从不溢出。真正的瓶颈不是拥塞——是应用层串行的多次查询——改批处理才解决问题——不是调 TCP 参数。

但社保到外部系统的专线——经过运营商的 MPLS VPN——共享链路——可能某个其他客户的业务高峰期——路由器的队列满了——你的重传开始上升。你看到的不是页面慢——是 TCP 窗口闪降。而你能做的只是在应用层加超时和告警——你不能控制运营商的队列策略。

✅ 亮点：从慢启动的指数增长逻辑出发，拆开超时重传（严重）和快重传（中等）两种丢包响应的区别，用社保-银行专线讲链路稳定时拥塞控制不生效的情况。扩展方向：BBR 的非丢包拥塞检测、QUIC 的拥塞控制与 TCP 的差异。