TCP 拥塞控制算法详解：CUBIC、BBR 与传统演进

TCP 拥塞控制算法详解：CUBIC、BBR 与传统演进

CUBIC 拥塞控制算法

背景与特点

CUBIC 是一种基于窗口的拥塞控制算法，它是对传统 BIC（Binary Increase Congestion Control）的改进。自 Linux 2.6.19 引入以来，它已成为许多现代操作系统的默认 TCP 拥塞控制算法，尤其在高带宽、高延迟（长肥网络，LFN）环境中表现优异。

它的核心在于以时间为基准调整拥塞窗口（cwnd），使用立方函数而非简单的线性或指数增长。这意味着在发生丢包后，CUBIC 不会像旧算法那样盲目地线性恢复，而是根据距离上次最大窗口 W_max 的时间差快速逼近，再缓慢达到新平衡点。这种机制让它对高 BDP 网络非常友好，扩展性也更好，适合数据中心和互联网骨干网。

工作原理与局限

当检测到丢包时，CUBIC 会将拥塞窗口降至 W_max × β（β通常约为 0.7）。随后，它不再依赖线性增加，而是按照三次函数公式 W(t) = C(t − K)³ + W_max 进行增长。其中 t 是自上次丢包以来的时间，K 是达到 W_max 所需的时间。

尽管性能出色，CUBIC 仍主要依赖丢包作为拥塞信号。这导致它在存在较大缓冲队列的网络中可能引起较高的排队延迟（bufferbloat），难以区分真正的拥塞丢包和网络抖动引起的延迟。

BBR 拥塞控制算法

设计初衷

BBR（Bottleneck Bandwidth and RTT）由 Google 于 2016 年提出，旨在解决传统基于丢包的算法在高延迟、高带宽环境下效率低下的问题。它不依赖丢包判断拥塞，而是通过主动探测瓶颈带宽（BtlBw）和往返时延（RTprop）来动态调整发送速率。

核心机制

BBR 周期性地在两种模式间切换：

• PROBE_BW（带宽探测）：逐步增加发送速率以探测可用带宽上限。
• PROBE_RTT（最小 RTT 探测）：定期降低发送速率以测量无排队时的最小 RTT。

这种模型驱动的方式让 BBR 能显著减少排队延迟，提升响应速度和吞吐量。特别是在视频流、大文件传输等对带宽敏感的场景中，它能有效缓解 bufferbloat。

优缺点分析

BBR 的优势在于高带宽、高延迟网络中的卓越表现，以及对延迟的敏感度较低。但部署上需要操作系统支持（Linux kernel ≥ 4.9），且多 BBR 流竞争时可能存在公平性问题。部分老旧网络设备也可能不支持非传统的拥塞控制算法。

CUBIC 与 BBR 对比总结

特性	CUBIC	BBR
拥塞判断依据	丢包	带宽 & 延迟（不依赖丢包）
拥塞窗口增长方式	基于时间的立方函数	基于带宽/延迟模型的速率控制
对延迟的敏感性	较低，易受 bufferbloat 影响	高，能显著降低延迟
适用场景	高带宽延迟网络、通用场景	高速网络、实时业务、视频流、云应用
公平性	较好	多 BBR 流间可能存在竞争问题
默认支持	Linux 默认（老版本）	需手动开启（Linux 4.9+ 支持）

传统算法演进：从 Tahoe 到 SACK

Tahoe 与 Reno

Tahoe 是最早引入拥塞控制的算法之一（约 1988 年）。它采用慢启动（指数增长）和拥塞避免（线性增长）机制。一旦检测到丢包，它将 ssthresh 减半，cwnd 重置为 1，重新进入慢启动。缺点是恢复太慢，没有快速恢复机制。