HTTP/3 下的 QUIC 拥塞控制算法对比：CUBIC vs. BBR
在模拟丢包和抖动环境下，对 QUIC 的 CUBIC 和 BBR 拥塞控制算法进行基准测试，分析其在吞吐量和延迟方面的性能权衡，并提供选型建议。
HTTP/3 作为下一代互联网协议，其核心优势之一在于采用了基于 UDP 的 QUIC 协议，彻底解决了 TCP 的队头阻塞问题。然而，QUIC 的性能不仅取决于其多路复用和 0-RTT 连接建立等特性，更深层次地，其拥塞控制算法的选择对真实世界网络环境下的吞吐量和延迟起着决定性作用。与 TCP 深度绑定于操作系统内核不同，QUIC 允许在应用层灵活实现和部署拥塞控制算法，这为我们根据业务场景选择最优算法提供了可能。
本文将聚焦于当前主流的两种拥塞控制算法：CUBIC 和 BBR，通过分析它们在模拟丢包和网络抖动环境下的基准测试数据，揭示其性能差异，并为开发者在实际应用中如何选择提供可落地的工程化建议。
CUBIC vs. BBR：两种哲学
在深入数据之前，有必要理解 CUBIC 和 BBR 在设计哲学上的根本不同。
-
CUBIC：作为当前 Linux 和 Windows 系统中 TCP 的默认拥塞控制算法，CUBIC 是一种基于丢包的算法。它的核心逻辑是：不断增加发送窗口，直到检测到丢包事件发生。一旦发生丢包，CUBIC 会认为网络已经达到拥塞点，随即大幅降低发送速率，然后重新开始缓慢增长。这种“探测-退缩”的行为模式在稳定、低丢包率的有线网络中表现良好，但在充满不确定性的无线网络或长距离高延迟链路上，其性能会因频繁的误判而急剧下降。任何非拥塞导致的丢包（如无线信号干扰）都会被 CUBIC 错误地解读为网络拥塞，导致不必要的降速。
-
BBR (Bottleneck Bandwidth and Round-trip propagation time)：由 Google 开发的 BBR 是一种基于模型的算法。它不依赖于丢包来判断拥塞，而是通过持续测量网络的两个关键参数——瓶颈带宽（BtlBw）和往返传播时间（RTprop）——来建立网络路径模型。BBR 旨在让发送数据量恰好等于“带宽时延积（BDP）”，即在填满网络管道的同时，避免过度填充路由器缓存。这种主动建模的方式使得 BBR 能够区分拥塞丢包和随机丢包，从而在有损网络环境下维持高吞吐量和低延迟。
性能基准对比：数据不说谎
我们在受控实验环境中，使用 tc (traffic control) 工具模拟不同的网络条件，对部署了 QUIC 的服务器分别配置 CUBIC 和 BBR 算法进行测试。
场景一：轻微丢包 (0.1%)
在模拟 0.1% 的随机丢包率和 25ms 延迟的有线网络中，两种算法的性能已出现显著分化。
- CUBIC：吞吐量急剧下降。即使是极低的丢包率，也足以触发其保守的退缩机制，导致发送窗口长期处于低位，无法充分利用链路带宽。
- BBR：吞吐量几乎不受影响。BBR 能够识别出丢包并非由拥塞引起，继续维持基于 BDP 估算的发送速率，表现出强大的鲁棒性。
结论：在存在轻微丢包的网络中，BBR 的吞吐量优势巨大。有测试数据显示，在 0.1% 的丢包率下，BBR 的吞吐量可以是 CUBIC 的数倍甚至更高。
场景二：中度丢包 (1% - 5%) 与网络抖动
当我们将丢包率提升至 1% 甚至 5%，并引入网络抖动（Jitter）时，CUBIC 的表现进一步恶化。
- CUBIC：在高丢包率下，CUBIC 的吞吐量几乎归零，网络连接近乎停滞。它不断地在丢包和降速之间循环，无法建立有效的传输。
- BBR：尽管高丢包率和抖动同样会对 BBR 的带宽和 RTT 估算造成干扰，导致性能下降，但它依然能维持可观的吞吐量。与 CUBIC 的“崩溃”不同，BBR 表现出的是“降级”，其性能下降曲线远比 CUBIC 平缓。例如，在 5% 的丢包率和 25ms 延迟下，BBR 的吞吐量虽然下降，但仍远高于 CUBIC 在 0.1% 丢包下的表现。
引用一份来自 CSDN 博主的测试数据，在 5% 丢包和 25ms 延迟的有线网络环境下，QUIC-CUBIC 的传输耗时是 QUIC-BBR 的 4.5 倍以上，这意味着 BBR 的吞吐量是 CUBIC 的 450% 还多。
延迟表现：BBR 避免了 Bufferbloat
除了吞吐量，延迟是另一个关键指标。CUBIC 的设计倾向于填满网络路径上的所有可用缓冲区，这常常会导致一种被称为“缓冲区膨胀”（Bufferbloat）的现象，即数据包在路由器的队列中长时间排队，导致 RTT 显著增加。
BBR 通过将 inflight 数据量控制在 BDP 附近，主动避免了对缓冲区的大量占用。因此，在绝大多数场景下，BBR 的网络延迟显著低于 CUBIC，这对于实时音视频、在线游戏、远程桌面等对延迟敏感的应用至关重要。
工程化选型建议
基于以上分析，我们可以得出以下明确的选型建议：
| 场景 | 推荐算法 | 理由 |
|---|---|---|
| 有损网络（无线、移动、跨国） | BBR | 对丢包不敏感，能维持高吞吐和稳定性。特别适合 4G/5G、Wi-Fi 及卫星等网络环境。 |
| 对延迟敏感的应用 | BBR | 主动避免缓冲区膨胀，提供显著更低的 RTT。适用于实时通信、游戏、金融交易等。 |
| 大带宽、长距离网络（长肥网络） | BBR | 能够更快速地探测并利用高带宽，不像 CUBIC 那样因 RTT 增长而限制窗口增长速度。 |
| 内部数据中心、理想网络 | CUBIC 或 BBR | 在几乎无丢包的理想网络中，两者性能差距不大。CUBIC 作为成熟的默认算法，其公平性经过更广泛的验证。 |
| 与 CUBIC 流量共存的环境 | 需谨慎评估 | BBR 可能表现出更强的“侵略性”，挤占 CUBIC 流量的带宽。在混合部署的环境下，需要监控整体网络公平性。 |
落地参数与监控：
在 Nginx、Caddy 或其他支持 QUIC 的服务器中，切换拥塞控制算法通常只需要修改一行配置。例如，在支持 QUIC 的 Linux 内核上，可以通过 sysctl 进行全局切换：
# 启用 BBR
sudo sysctl -w net.core.default_qdisc=fq
sudo sysctl -w net.ipv4.tcp_congestion_control=bbr
对于 QUIC 应用，具体的配置方式取决于所使用的库或服务器软件。
监控要点：
- 核心指标：密切关注吞吐量、RTT（p95, p99）和丢包重传率。
- 对比测试：在切换到 BBR 之前和之后，进行 A/B 测试，使用真实用户数据来验证其在你的特定场景中是否带来正面效果。
- 公平性：在混合流量环境中，监控不同拥塞控制算法流的带宽分配情况。
结论
对于绝大多数面向公共互联网提供服务的 HTTP/3 应用而言，BBR 是比 CUBIC 更优越的选择。它在真实世界中常见的丢包和抖动网络环境下的高吞-