BBR
Bottleneck Bandwidth and Round-trip propagation time——Google 提出的模型驱动拥塞控制算法。
不等待丢包信号，直接测量网络物理容量，在 Kleinrock 最优点 运行，实现高吞吐与低延迟的同时达成。
01 · Overview
为什么需要 BBR
传统的 Reno / CUBIC 拥塞控制依赖丢包作为拥塞信号。但在 bufferbloat 时代，路由器缓冲区膨胀至 MB 甚至 GB 级，丢包发生时瓶颈队列早已满载数百毫秒——丢包不是及时的拥塞信号，而是拥塞灾难的迟到通知。
核心洞察
02 · Diagrams
三张图理解 BBR
点击图片两侧或下方标签切换。三张图覆盖 BBR 的物理模型、控制闭环和状态机。
物理约束模型
inflight 与吞吐/延迟的双曲线关系
03 · Mechanisms
六大关键机制
-
BtlBw 估计Bottleneck Bandwidth
在每个 ACK 到达时计算瞬时送达速率，在 6-10 RTT 滑动窗口中取最大值作为瓶颈带宽估计。最大值在发送速率受瓶颈约束时等于真实瓶颈带宽——这是无偏估计，不会被 ACK 压缩或调度抖动拉低。
-
RTprop 估计Round-Trip Propagation
在 10 秒滑动窗口中取最小 RTT 作为传播时延估计。当 inflight 低于 BDP 时队列为空，RTT = RTprop。10 秒长窗口确保路由切换后也能在下一次 PROBE_RTT 中捕获新的传播时延。
-
Pacing速率平滑
将数据均匀分布在一个 RTT 时间窗内发送，每发完一个包等待
packet_size / pacing_rate再发下一个。Pacing 消除了发送端自制造的 burst，是 BBR 实现低延迟的核心手段。 -
Inflight Cap在途数据上限
Pacing 控制发送节奏，inflight cap（= cwnd_gain × BDP）控制已发出但未确认的数据总量。两者解耦但协同：即使 pacing rate 被设得很高（如 STARTUP），inflight cap 也确保网络总数据量不超安全倍数。
-
增益循环Gain Cycling
PROBE_BW 稳态的 8 相循环
[1.25, 0.75, 1, 1, 1, 1, 1, 1]。75% 的时间以恰好等于 BtlBw 的速率发送，仅在 1/8 相位主动探测更多带宽（1.25×），紧随的 1/8 相位排空队列（0.75×）。 -
应用受限检测App-limited filter
当发送端因应用层数据不足而未填满 cwnd 时，该期间的 RTT 样本被排除在 RTprop 估计外（因低 RTT 不代表网络空载），BtlBw 样本也被排除（因测量速率被应用限制而非瓶颈限制）。
04 · Design Philosophy
设计哲学
BBR 不是对 AIMD 的参数调优——它是拥塞控制范式的根本转换。这五条原则定义了 BBR 与其他算法最本质的区别。
- 1模型驱动，非信号响应不等网络发信号（丢包），而是主动测量网络物理容量。Reno/CUBIC 是反应式的，BBR 是预测式的。
- 2解耦吞吐与延迟传统算法的吞吐与延迟不可兼得——大窗口=高吞吐=高延迟。BBR 通过 pacing 和 inflight cap 打破了这个耦合。
- 3不依赖丢包，对随机丢包容忍1% 随机丢包能让 CUBIC 吞吐崩溃（窗口反复减半），但 BBR 的 BtlBw 估计完全不受丢包影响——测量的是送达速率，不是丢包率。
- 4快速收敛，持续探测STARTUP 在 2-3 RTT 内找到 BtlBw（vs CUBIC 数分钟），PROBE_BW 的增益循环持续探测带宽变化，不假设链路是静态的。
- 5仅需修改发送端接收端和路由器无需任何改动。BBR 的部署成本极低——Linux 内核开关即可启用，Google 已在 YouTube 全球边缘部署。
- 6状态机分离探测与稳态通过四态分离不同目标——STARTUP 探测上限，DRAIN 排空副作用，PROBE_BW 巡航+微调，PROBE_RTT 刷新基线。每个状态做一件事且只做一件事。
05 · Performance
BBR vs CUBIC
在深缓冲区+低丢包链路上两者差异不大；但在以下真实世界场景中，BBR 的优势是数量级的。
| 网络条件 | CUBIC 行为 | BBR 行为 | BBR 吞吐优势 |
|---|---|---|---|
| 浅缓冲区 | 周期性丢包，窗口大幅回退 | 控制在 BDP 附近，不丢包 | 2-3× |
| 1% 随机丢包 | 每个丢包窗口减半，吞吐崩溃 | 丢包不影响 BtlBw 估计 | 10-100× |
| 高 BDP 洲际链路 | 慢启动+AIMD 收敛极慢 | STARTUP 2-3 RTT 内发现 BtlBw | 3-5×（冷启动） |
| 移动网络（LTE/5G） | 丢包后低窗口浪费带宽 | 持续探测，快速适应速率变化 | 2-4× |
06 · Evolution
版本演进：v1 → v2 → v3
BBR 的核心模型在 v1 中已经足够优美。v2 和 v3 主要解决部署中的实际摩擦——公平性、ECN、Wi-Fi 聚合。
-
2016 · v1
模型驱动的诞生
建立 BtlBw/RTprop 双参数模型和四态状态机。Linux 4.9 进入主线。缺陷：与 CUBIC 共存时公平性差，对 Wi-Fi ACK 聚合过度敏感，会将瞬时高速率误判为瓶颈带宽。
-
2019 · v2
丢包感知 + ECN
引入丢包率作为补充拥塞信号——丢包超阈值时主动降低 inflight cap 以改善公平性。支持 ECN（显式拥塞通知），在丢包发生前探测队列积压。带宽探测更保守，避免在已有拥塞时进一步加剧。
-
2023 · v3
收敛与公平性修复
修复 v2 在高 BDP+低丢包链路上收敛过慢的问题。增强 bandwidth 估计器滤除 Wi-Fi ACK 聚合尖峰。公平性目标从「不比 CUBIC 差」升级为「BBR 流之间均分带宽」。Linux 内核主线推进中。
07 · FAQ
常见问题
- BBR 和 CUBIC 可以共存吗？
- 可以。BBR 和 CUBIC 运行在同一台服务器上不同连接时互不冲突，因为拥塞控制是 per-connection 的。但在同一瓶颈链路竞争时，BBR v1 会抢占 CUBIC 的带宽（CUBIC 丢包后回退给 BBR 留出空间），v2/v3 通过丢包感知和更保守的探测改善了这一问题。
- BBR 需要路由器支持吗？
- 不需要。BBR 只需修改发送端的 TCP 实现。这是它相比「主动队列管理（AQM）」类方案（如 CoDel、FQ）最大的部署优势。当然，如果路由器同时开启了 FQ（Fair Queuing），BBR 的表现会更优。
- 如何在我的 Linux 服务器上启用 BBR？
echo bbr > /proc/sys/net/ipv4/tcp_congestion_control。前提是内核 >= 4.9 且模块已加载（modprobe tcp_bbr）。确认生效：sysctl net.ipv4.tcp_congestion_control。BBR v2 需要内核 >= 5.19 并加载tcp_bbr2模块。- BBR 适合所有场景吗？
- BBR 在大多数场景下优于 CUBIC，尤其在高 BDP、高损、浅缓冲区链路。但在极低带宽（< 100Kbps）或应用层数据断续的场景，BBR 的 pacing 精度会受影响。此外 BBR v1 在 Wi-Fi 环境下可能高估 BtlBw。v3 已针对这些场景做专项优化。
- BBR 和 QUIC / HTTP/3 有什么关系？
- QUIC 在用户空间实现传输层，可以用任意拥塞控制算法。Google 的 QUIC 实现（Chromium）默认使用 BBR。因此 YouTube 等 Google 服务的 HTTP/3 流量天然走 BBR。BBR 的 pacing 在 QUIC 中比内核 TCP 更容易实现（用户空间更容易做精确的定时器调度）。