目录1. 拥塞控制问题的形式化2. AIMD与Reno的四阶段架构2.1 AIMD原则的收敛性2.2 慢启动指数探测可用带宽2.3 拥塞避免加性增加的线性阶段2.4 快速重传与快速恢复3. CUBIC高BDP网络的窗口增长优化3.1 Reno的线性增长在高带宽网络中的失效3.2 三次函数的窗口增长3.3 CUBIC的实用地位4. BBR范式的根本转向4.1 从丢包到带宽-延迟模型4.2 瓶颈带宽与最小RTT的持续估计4.3 稳态探测循环4.4 两种范式的本质差异5. 算法选择与共存6. 结语参考文献1. 拥塞控制问题的形式化1986年Lawrence Berkeley实验室与UC Berkeley之间的网络吞吐量从32Kbps断崖式跌至40bps。Jacobson追踪到问题根源拥塞崩溃——网络中的重传包多于有效数据包链路带宽被重复发送的旧数据吞噬却没有机制限制发送方的注入速率。拥塞控制要解决的根本问题是如何在多个竞争流之间公平分配瓶颈链路带宽同时避免网络陷入拥塞崩溃。不同于流量控制的端到端接收方约束拥塞控制是发送方对网络状态的自主推断与响应。发送方维持一个拥塞窗口cwnd实际发送窗口取cwnd与接收通告窗口两者的较小值。cwnd的任何变化都是发送方对网络反馈信号的解读与行动——这是所有TCP拥塞控制算法的共同框架差异仅在于解读什么信号以及如何行动。2. AIMD与Reno的四阶段架构2.1 AIMD原则的收敛性AIMD——加性增加、乘性减少——是TCP拥塞控制的理论基石。理想条件下多个流在瓶颈链路上各自以AIMD规则调节窗口长期来看公平共享瓶颈带宽。规则极简每RTT未发生丢包拥塞窗口加1个MSS加性增加一旦发生丢包拥塞窗口减半乘性减少。加性增加保证了在无拥塞时窗口缓慢扩张以探测可用带宽乘性减少在检测到拥塞时快速收缩以释放队列。AIMD的收敛性有理论保证两个窗口不同的流减半操作缩小绝对窗口差值加性增大保持差值稳定长期迭代后窗口趋于均等。但AIMD的收敛速度与链路带宽和RTT密切相关——高BDP网络中加性增加每RTT仅增一个MSS从半窗口恢复到满窗口需要极长时间。这是Reno在高速长时延网络上的根本性能缺陷。2.2 慢启动指数探测可用带宽连接建立或RTO超时后发送方对网络可用带宽一无所知。慢启动以指数方式快速探测每收到一个ACKcwnd加1个MSS每RTT本质上cwnd翻倍。从一个MSS开始经过N个RTT窗口达到2^N个MSS。慢启动并非字面意义上的慢在低延迟链路上窗口增长极快。其慢仅相对于直发接收通告窗口满值的行为而言——旧TCP在连接建立后立即将一整个接收窗口的数据注入网络在瓶颈链路上直接触发大量丢包。慢启动用指数逐渐逼近可用带宽。慢启动阈值ssthresh标志从慢启动切换至拥塞避免的窗口值。当cwnd超过ssthresh或发生丢包时慢启动终止。ssthresh的初值通常较高但在发生拥塞后被设为当前cwnd的一半——这是AIMD乘性减少在慢启动阈值上的映射。2.3 拥塞避免加性增加的线性阶段cwnd超过ssthresh后进入拥塞避免阶段。每RTT窗口加1个MSS而非每ACK——实现上通常取cwnd MSS * MSS / cwnd使得每RTT窗口面积增加一个MSS。线性增长持续进行直到丢包发生——丢包是Reno唯一认可的拥塞信号。2.4 快速重传与快速恢复三个重复ACK触发快速重传Reno在此之后执行快速恢复而非进入慢启动。快速恢复的核心操作是ssthresh设为当前cwnd的一半cwnd也减半而非减为1。在快速恢复期间每收到一个重复ACKcwnd虚增一个MSS以保持管道满载。当新数据的ACK到达快速恢复结束cwnd保持减半后的值进入拥塞避免。快速恢复将单次丢包的损失从完全重新慢启动压缩到半窗口继续线性增长显著提升了偶发丢包时的吞吐量。但Reno在单个窗口内发生多个丢包时表现急剧恶化——快速恢复一次只能处理一个丢包多段丢失迫使超时重传和慢启动重新进入。3. CUBIC高BDP网络的窗口增长优化3.1 Reno的线性增长在高带宽网络中的失效Reno在拥塞避免阶段每RTT仅增1个MSS。在典型的跨洲光纤链路上BDP可达12MB以上——以MSS 1460字节计窗口约8000个段。当丢包发生后窗口减半从4000恢复到8000需要4000个RTT。若RTT为100ms这意味着近7分钟的恢复时间。在此期间链路大量时间空闲有效吞吐量远低于链路物理容量。问题的根源在于Reno的窗口增长函数与可用带宽完全脱钩——无论链路是10Mbps还是100Gbps恢复速度相同。3.2 三次函数的窗口增长CUBIC以三次函数替代Reno的线性增长窗口大小取决于自上次丢包以来经过的时间而非RTT计数。设丢包发生的时间点为参考点CUBIC的窗口增长曲线分三个阶段。凹增长阶段——离丢包较近时窗口快速恢复凸增长阶段——接近上次丢包窗口值时增长趋缓以探测可能存在的拥塞点超过旧窗口后增长再次加速以寻找更高的可用带宽。CUBIC的窗口增长与RTT无关——几条共享瓶颈链路的流无论各自RTT如何从相同窗口减少后的恢复速度大体相近。RTT公平性是Reno的已知缺陷短RTT流每RTT更频繁地获得窗口增量在相同丢包率下挤占长RTT流的带宽。CUBIC以时间为增长单位而非RTT缓解了这种偏差。3.3 CUBIC的实用地位CUBIC自Linux内核2.6.19起被设为默认拥塞控制算法在全世界绝大多数服务器上运行。它的突出优点是部署简单——不需要网络交换机的特殊支持不需要接收方配合仅发送方单侧调整即可工作。三次函数计算快速没有复杂的状态维护同时在高BDP网络中的传输效率远超Reno。但CUBIC仍是丢包驱动的算法——它仍然需要丢包或ECN标记作为拥塞信号。当网络中存在显著的缓冲膨胀时链路RTT远高于本征延迟丢包发生在缓冲区满之后而非瓶颈带宽饱和之时。CUBIC无法区分这两种延迟来源持续增大窗口直到填满所有可用缓冲区。4. BBR范式的根本转向4.1 从丢包到带宽-延迟模型自Jacobson 1988年的开创性工作以来丢包一直是TCP拥塞控制的唯一信号源。这种设计的核心假设是丢包意味着瓶颈带宽饱和队列已满。在缓冲区较小的传统路由器中这个假设基本成立——队列填入少量包即溢出丢包与拥塞几乎同时发生。但现代网络中交换机缓冲区常达数MB甚至更大——缓冲膨胀。在丢包发生之前数据包已在缓冲区中排队数百毫秒RTT远高于本征延迟。丢包驱动的算法在丢包出现前持续填满缓冲区产生极高的排队延迟。对于实时交互和网页浏览延迟的恶化不亚于带宽的减少。BBR的范式转向在于拥塞不是在丢包时才发生的而是在瓶颈带宽饱和、排队延迟开始累积的时刻就已经发生。BBR试图操作在带宽刚好用满、队列尚未堆积的状态——这是Kleinrock提出的最佳操作点。4.2 瓶颈带宽与最小RTT的持续估计BBR维护两个关键估计值瓶颈带宽BtlBw和传播RTTRTprop。BtlBw是过去若干个RTT窗口内送达速率的滑动窗口最大值。RTprop是过去一段时间内观察到的最小RTT作为网络本征延迟的估计。当送达速率触及BtlBw且RTT接近RTprop时链路处于最佳操作点——满带宽、零排队。BBR据此计算发送速率和窗口上限保持在BDP附近注入数据而不是像丢包驱动算法那样持续增加窗口直到引发丢包。4.3 稳态探测循环BBR在稳态下循环探测更多带宽和更小RTT。大部分时间处于PROBE_BW状态以BtlBw的指定增益循环尝试更高的发送速率——偶尔以1.25倍增益探测是否有更多带宽可用多周期以0.75倍增益排空可能积累的队列。周期性进入PROBE_RTT状态将发送窗口急剧缩小强制排空路径上所有缓冲区测量真正的本征RTT。BBR算法的核心复杂度在于这两个探测过程的协同和增益参数的调节。探测带宽过激则不公平挤占其它流探测太保守则无法发现新的带宽释放。BBR经验上达到在多数网络状况下高吞吐量与低延迟的共存但具体参数仍在随着BBRv2和BBRv3的迭代调整。4.4 两种范式的本质差异丢包驱动范式Reno、CUBIC将拥塞理解为一个二元事件——有丢包则拥塞无丢包则未拥塞。窗口持续线性或三次增长直到碰触丢包这一信号。这种模式在缓冲膨胀环境下将网络长期维持在满队列状态——链路利用率高延迟也高。模型驱动范式BBR将拥塞理解为带宽和延迟的连续型状态——拥塞是瓶颈饱和导致排队延迟增长的渐进过程而非丢包这一事件。发送方主动估计网络路径的物理局限将自己在BDP附近调节避免进入满队列-丢包-回退的循环。两种范式的根本分歧不在具体算法参数的设定而在对拥塞是什么的定义。这个定义决定了算法如何看待网络——是等待网络发出明确的丢包故障信号还是通过测量主动推断网络的有效容量边界。5. 算法选择与共存不同拥塞控制算法在设计目标和假设网络上存在根本差异单网络内多种算法共存时共享瓶颈带宽的分配并不均等。BBR与CUBIC在瓶颈链路上竞争时BBR倾向于占取更大带宽份额——它主动探测带宽而非被动响应丢包而CUBIC在排队压力下主动收缩。公平性不属于拥塞控制算法的单算法设计目标而是多算法部署时需要额外考虑的跨算法资源分配问题。从工程运维角度理解网络中部署的具体拥塞控制算法类型及其交互是诊断带宽分配不公平、个别流吞吐量异常的基础。6. 结语TCP拥塞控制三十余年的演化从Reno固定的AIMD线性增长到CUBIC以三次函数适应高带宽网络再到BBR以带宽-延迟模型重定义拥塞本身——刻画了一条从响应丢包到探测容量的方法论转向。这种转向的驱动是网络物理属性本身的变化缓冲区从浅到深带宽从Mbps到Gbps延迟从毫秒到百毫秒。丢包信号作为拥塞代理的假设越来越偏离真实链路的物理行为。BBR的模型驱动方案仍非最终答案但它开辟了从被动响应网络信号到主动建模网络容量的理论路径。未来的研究将继续在这条路径上调节探测增益与公平性之间的平衡。参考文献[1] Jacobson, V. Congestion avoidance and control.ACM SIGCOMM CCR, 18(4): 314-329, 1988.[2] Floyd, S., Henderson, T. RFC 2582: The NewReno Modification to TCPs Fast Recovery Algorithm. IETF, 1999.[3] Ha, S., Rhee, I., Xu, L. CUBIC: A new TCP-friendly high-speed TCP variant.ACM SIGOPS OSR, 42(5): 64-74, 2008.[4] Cardwell, N., Cheng, Y., Gunn, C. S., Yeganeh, S. H., Jacobson, V. BBR: Congestion-based congestion control.Communications of the ACM, 60(2): 58-66, 2017.