网络设计第八问拥塞控制——慢启动、拥塞避免、快重传流量控制是接收方说了算。拥塞控制是发送方自己估——根据丢包、RTT——猜现在网络中能承受多少数据。这个猜难在哪里你不知道中间路由器的缓冲区大小。而这个大小随每一次拥堵而变。文章目录网络设计第八问拥塞控制——慢启动、拥塞避免、快重传一、为什么需要拥塞控制二、慢启动——不是你想象的那样三、拥塞避免——每 RTT 加 1四、丢包 ≠ 拥塞五、社保系统里的现实一、为什么需要拥塞控制发送方拼命发——路由器排队——缓冲区满了——丢包——丢包触发重传——全网都是重传包——有效吞吐跌到零。这不是接收方的问题——是网络链路本身承载不了。拥塞控制不给发送方一个固定的上限——它根据当前网络的拥塞情况——动态调整发送速率。丢包了→减小速率。没丢包→慢慢增大速率。二、慢启动——不是你想象的那样慢启动不是慢——是指数增长。开始窗口1个 MSS最大报文段长——收到一个 ACK→窗口1——窗口从 1→2→4→8→16→…——每 RTT 翻一倍。为什么叫慢不是增速慢——是起点小。正常窗口可能几百或几千——慢启动从 1 开始——虽然增长快——但初始值低——总体在前期是保守的。阈值——当窗口超过 ssthresh——从慢启动切换为拥塞避免——线性增长。三、拥塞避免——每 RTT 加 1持续增加窗口直到丢包——窗口每 RTT 增加 1 个 MSS——增速平缓——避免突然冲垮网络——但也不能断掉——持续在网络容量边缘试探。当检测到丢包——两种处理超时重传RTO——很可能发生了严重拥塞——把 ssthresh 设为当前窗口的一半——窗口退回 1——重新开始慢启动快重传3个重复ACK——后面三个包到了——中间一个丢了——阻塞程度不严重——ssthresh窗口/2——窗口ssthresh3——直接进入拥塞避免——不重新慢启动四、丢包 ≠ 拥塞现代网络更复杂——一个 Wi-Fi 干扰丢包——信号层问题——不是链路满——而传统 TCP 把它当拥塞——窗口减半——吞吐白跌。BRR 基于 RTT 而非丢包——RTT 开始变大→缓冲区在满的边缘→开始减速——不等丢包。比丢包信号更精确——在 Wi-Fi 和卫星链路等误码高的环境下——BRR 不白减速。五、社保系统里的现实社保结算平台到银行之间的链路——RTT 15ms——带宽 100Mbps——丢包率极低。拥塞控制在这个链路上几乎不被触发——因为队列从不溢出。真正的瓶颈不是拥塞——是应用层串行的多次查询——改批处理才解决问题——不是调 TCP 参数。但社保到外部系统的专线——经过运营商的 MPLS VPN——共享链路——可能某个其他客户的业务高峰期——路由器的队列满了——你的重传开始上升。你看到的不是页面慢——是 TCP 窗口闪降。而你能做的只是在应用层加超时和告警——你不能控制运营商的队列策略。✅ 亮点从慢启动的指数增长逻辑出发拆开超时重传严重和快重传中等两种丢包响应的区别用社保-银行专线讲链路稳定时拥塞控制不生效的情况。扩展方向BBR 的非丢包拥塞检测、QUIC 的拥塞控制与 TCP 的差异。