拥塞控制算法BBR与CUBIC

可视化演示

通过CUBIC三次函数窗口增长、BBR带宽RTT建模和两者吞吐延迟对比，直观展示现代拥塞控制算法的核心差异。

拥塞控制起源

早高峰的高速路上，一辆车轻点刹车，后面几十辆车被迫减速，几公里后车流完全停摆。这种“幽灵堵车”不是某个司机技术差，而是反应链条太长。互联网同样如此：当大量数据包同时涌向一台路由器，路由器会先让它们排队，队列一旦溢出，新来的包只能被丢弃，于是发送方收不到确认，被迫重传，最终整个网络吞吐崩塌。

TCP 的拥塞控制就是那位“交警”。它让每个发送方都维护一个拥塞窗口（cwnd），相当于“允许同时在路上的卡车数”。窗口太小，道路空驶浪费带宽；窗口太大，路由器会变成停车场。最初的 TCP 只知道一个信号——丢包。丢包就像是前车的刹车灯：一旦看见，就赶紧减速；没看见，就放心加速。这种基于丢包反馈的机制简单，却容易反应过慢。

由于发送速率本质上是“拥塞窗口”除以“一趟往返耗时”，我们可以把网络吞吐率写成一个最基础的关系式：

这位“交警”的核心任务，就是在路况和车速之间不断试探，尽早发现前方拥堵，而不是等整条高速彻底停止才行动。

CUBIC机制

CUBIC 是一位“大开大合”的司机。它的驾驶风格很鲜明：看到刹车灯（丢包），立刻把车速砍掉一大截；随后重新加速时，不是匀速，而是踩着一块“越来越深”的油门，让速度以三次方的节奏冲上去。这种思路来自早期 BIC 算法的二分搜索，但 BIC 的窗口锯齿太剧烈，CUBIC 用一个三次函数把曲线磨得更平滑。

CUBIC 的核心是把“从上一次丢包到现在的时间”当成变量 t，再用一个三次方程描述窗口的恢复过程。为什么要三次方？因为三次函数既有快速爬升的“凸段”，也有接近上次峰值时逐渐放缓的“凹段”。这种节奏很像司机接近拥堵点时知道该收油，远离拥堵点时敢于猛踩。

窗口大小与时间的关系如下：

CUBIC 司机的优势在于：它能用“大油门”快速找回带宽，又能在接近堵点前自动收油，比老式 Reno 更适合高带宽、大延迟的网络。

CUBIC特征

如果一位 CUBIC 司机在城市里开车，你会看到他遇到红灯就猛刹，绿灯一亮就全力冲刺。这种风格在信号灯（丢包）频繁的路段没有问题，但在缓冲区很深的高速入口，问题就来了：司机在排队时并不着急，因为刹车灯还没亮，于是一辆接一辆地塞满匝道，最终把排队延续到主路上，造成“缓冲膨胀”。

当丢包真的发生时，CUBIC 会把窗口乘性降低到当前峰值的一个比例。这个动作非常重要，它决定了算法对丢包的敏感度：

CUBIC 整体上是“高带宽利用”和“丢包后快速恢复”的平衡。它在传统互联网中表现稳定，对路由器缓冲也不挑剔，适合大多数通用场景。但遇到深缓冲区链路时，它比 BBR 更容易制造排队延迟，这是它最明显的软肋。

BBR机制

BBR 这位司机完全是另一套哲学：它不盯着前车刹车灯，而是出发前先在高速上装一套传感器，精确测量两个数字——这条路最窄路段每秒能通过多少车（瓶颈带宽 BtlBw），以及一路绿灯时从起点到终点最短需要多久（最小 RTT）。有了这两个数字，它就不再靠“丢包”猜路况，而是直接算出最佳车速。

BBR 把网络建模成“最窄管道加一段传播时间”。发送速率不能超过瓶颈带宽，否则数据会在路由器排队；在途数据量又不能太少，否则管道空着。它用四个阶段循环探测：启动（Startup）、排空（Drain）、带宽探测（ProbeBW）和 RTT 探测（ProbeRTT）。每次探测都像无人机重新扫一遍路况，保证模型不过时。

BBR 的发送节奏不是一次塞一车，而是用“流量整形”均匀地发送，像洒水车一样平稳。它决定发送速度的方式是：

BBR 最大的改变，是让发送方第一次“看见”道路的真实容量。它不等到刹车灯亮起才减速，而是始终保持一种接近物理极限但又不打破平衡的驾驶节奏。

BBR特征

想象你开在一条空旷的长距离高速上，普通司机会忍不住把油门踩到底，结果在某个狭窄的立交桥前大排长龙；BBR 司机清楚地知道立交桥的通过能力，会把车速控制在刚好不排队的水平。于是整条路的延迟始终接近“一路畅通”的最短时间，这就是 BBR 缓解缓冲膨胀（bufferbloat）的秘密。

BBR 在控制“在途数据量”时，会参考一个被称为 BDP（带宽延迟积）的数字。BDP 就是这条管道里能装下的最大数据量：如果路上只有一辆车，太浪费；如果塞得满满当当，一遇到出口就只能排队。理想状态是刚好装满：

BBR 在长肥管道（高带宽、高延迟）中表现尤其亮眼：吞吐稳定，延迟不随着队列增长而恶化。不过它也并非没有争议，当它与 CUBIC 流共享同一瓶颈时，BBR 有时会挤占带宽，这让公平性问题成为它最常被讨论的弱点。

对比与选型

回到城市驾驶：如果每天穿越红绿灯密集的老城区，CUBIC 这种“看到刹车灯才反应”的司机更可靠；如果经常跑跨省的宽阔高速公路，BBR 这种“提前测量路况”的司机体验更好。这两种选择不是谁替代谁，而是看路况。

从原理上看，CUBIC 依赖丢包反馈，适合路由器缓冲区不深的传统网络；BBR 依赖时延和带宽建模，更适合高带宽、高延迟且希望低排队延迟的网络。实际部署中，Linux 内核可以通过 net.ipv4.tcp_congestion_control 切换算法，也可以在容器或云主机里针对不同出口链路分别配置。

无论选哪条路，我们都可以用一个利用率指标判断“有没有跑满道路”：

工程上的最优解，往往是“混合驾驶”：默认用 CUBIC 保证公平与兼容，在长距离专线或云骨干上改用 BBR 换取更低延迟。理解了这两种算法，你才能在网络调优时真正说出“为什么快”和“为什么慢”。

AI 应用场景

Python 演示

import math C = 0.2BETA = 0.3 def cubic_recovery(w_max):    # 计算CUBIC丢包后0到10秒的拥塞窗口变化    k = (w_max * BETA / C) ** (1 / 3)    return [max(1.0, w_max + C * (t - k) ** 3) for t in range(11)] def bbr_target(bottleneck_bw, min_rtt):    # BBR用瓶颈带宽乘以最小RTT得到BDP    return bottleneck_bw * min_rtt if __name__ == "__main__":    print("CUBIC窗口:", cubic_recovery(30))    print("BBR在途目标:", bbr_target(120, 0.25))

1. k = (w_max * BETA / C) ** (1 / 3)计算恢复时间 K，它是 CUBIC 曲线从丢包低点爬回 Wmax 需要的秒数。
2. return [max(1.0, w_max + C * (t - k) ** 3) for t in range(11)]用列表推导式生成 0 到 10 秒的窗口值，模拟 CUBIC 的三次方爬升。
3. return bottleneck_bw * min_rtt计算 BBR 的目标在途数据量，也就是让管道刚好装满而不排队的 BDP。
4. print("CUBIC窗口:", cubic_recovery(30))输出示例，窗口从低点一路涨上去，体现 CUBIC 对丢包的快速恢复能力。

常见误区

面试题