目录
[1. 拥塞控制问题的形式化](#1. 拥塞控制问题的形式化)
[2. AIMD与Reno的四阶段架构](#2. AIMD与Reno的四阶段架构)
[2.1 AIMD原则的收敛性](#2.1 AIMD原则的收敛性)
[2.2 慢启动：指数探测可用带宽](#2.2 慢启动：指数探测可用带宽)
[2.3 拥塞避免：加性增加的线性阶段](#2.3 拥塞避免：加性增加的线性阶段)
[2.4 快速重传与快速恢复](#2.4 快速重传与快速恢复)
[3. CUBIC：高BDP网络的窗口增长优化](#3. CUBIC：高BDP网络的窗口增长优化)
[3.1 Reno的线性增长在高带宽网络中的失效](#3.1 Reno的线性增长在高带宽网络中的失效)
[3.2 三次函数的窗口增长](#3.2 三次函数的窗口增长)
[3.3 CUBIC的实用地位](#3.3 CUBIC的实用地位)
[4. BBR：范式的根本转向](#4. BBR：范式的根本转向)
[4.1 从丢包到带宽-延迟模型](#4.1 从丢包到带宽-延迟模型)
[4.2 瓶颈带宽与最小RTT的持续估计](#4.2 瓶颈带宽与最小RTT的持续估计)
[4.3 稳态探测循环](#4.3 稳态探测循环)
[4.4 两种范式的本质差异](#4.4 两种范式的本质差异)
[5. 算法选择与共存](#5. 算法选择与共存)
[6. 结语](#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超时后，发送方对网络可用带宽一无所知。慢启动以指数方式快速探测：每收到一个ACK，cwnd加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。在快速恢复期间，每收到一个重复ACK，cwnd虚增一个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）和传播RTT（RTprop）。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 TCP's 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.