•2025年10月
systems

HTTP/3拥塞控制：CUBIC vs. BBR性能对决

在模拟丢包和抖动环境下，对HTTP/3底层QUIC协议的CUBIC和BBR拥塞控制算法进行基准测试，深入分析其在吞吐量和延迟方面的性能权衡，并提供选型建议。

随着HTTP/3的逐步普及，其底层的QUIC协议因其出色的性能表现而备受关注。与依赖于TCP的HTTP/2不同，QUIC基于UDP构建，并集成了自己的拥塞控制逻辑。这使得我们有机会在应用层选择和优化拥塞控制算法，以适应不同的网络环境和业务需求。其中，CUBIC和BBR是最具代表性的两种算法。本文将对这两种算法在HTTP/3下的性能表现进行深入的对比分析，并为开发者提供在不同场景下的选型参考。

CUBIC与BBR：两种迥异的设计哲学

要理解CUBIC和BBR的性能差异，首先需要了解它们在设计思想上的根本不同。

CUBIC是一种基于丢包的拥塞控制算法，也是当前许多操作系统中TCP的默认算法。它的核心思想是，将网络中的数据包丢失（Packet Loss）作为发生拥塞的主要信号。当CUBIC检测到丢包时，它会迅速降低其拥塞窗口（Congestion Window，cwnd），即减少网络中未确认的数据包数量，从而减缓发送速率以缓解拥塞。在没有丢包的情况下，它会采用一个三次函数（Cubic Function）来平滑地增加拥塞窗口，积极地探测可用带宽。这种方法的优点是实现相对简单，且在大多数通用网络环境下表现良好。然而，它的一个主要缺点是，在存在随机丢包（非拥塞引起的丢包，例如无线网络中的信号干扰）的网络中，CUBIC会错误地判断为网络拥塞，从而导致不必要的降速，无法充分利用链路带宽。

**BBR（Bottleneck Bandwidth and Round-trip propagation time）**则是一种基于模型的拥塞控制算法，由Google提出。BBR不依赖于丢包来判断拥塞，而是通过持续测量网络的瓶颈带宽（BtlBw）和往返传播时间（RTprop）这两个关键参数，来构建一个网络路径模型。它的目标是让发送的数据量恰好等于网络的带宽时延积（Bandwidth-Delay Product, BDP），从而在不产生额外排队延迟的情况下，最大化数据传输速率。因为BBR不将丢包作为拥塞的主要信号，所以它在有损网络（lossy networks）中的表现通常远优于CUBIC。即使在丢包率较高的情况下，BBR依然能够维持较高的吞吐量。

性能对决：吞吐量、延迟与CPU开销

在不同的网络条件下，CUBIC和BBR展现出了截然不同的性能取向。

高丢包网络：BBR的绝对主场

大量的测试数据表明，在高丢包率的网络环境中，BBR的吞吐量优势极为明显。一份针对QUIC的测试报告显示，在5%的丢包率下，BBR的性能可以数倍于CUBIC。其根本原因在于CUBIC的“丢包即拥塞”的假设在这种环境下失效了，它会频繁地降低发送速率，导致带宽利用率低下。而BBR则能“无视”这些非拥塞丢包，持续以接近瓶颈带宽的速率发送数据。对于需要穿越骨干网、无线网络等复杂网络环境的应用，例如视频流、大文件下载和游戏加速，BBR无疑是更优的选择。

低延迟与高吞吐的权衡

BBR的核心目标是最大化吞吐量，同时尽量降低排队延迟。它通过主动探测带宽和延迟，试图找到一个最佳平衡点。相比之下，CUBIC的窗口增长模型更为激进，在网络稳定且无丢包时，可能会更快地占满缓冲区，这在某些情况下可能导致延迟的增加。

然而，BBR也并非完美无缺。为了精确测量最小RTT（PROBE_RTT阶段），BBR会周期性地主动降低发送速率，排空网络管道中的数据包。这个过程虽然短暂，但可能导致瞬时的吞吐量下降，对于一些对延迟极其敏感的应用（如实时互动），可能会造成可感知的抖动。

CPU使用率的考量

从实现上看，BBR的算法逻辑比CUBIC更为复杂。它需要持续地进行数据包的采样、模型的计算和状态的维护。因此，在相同的流量下，BBR可能会比CUBIC消耗更多的CPU资源。在一项针对Redis性能的测试中发现，当连接数增多时，采用BBR的服务器其内核态（sys）CPU占用率明显高于采用CUBIC的服务器。对于CPU资源非常受限的设备，或者需要处理海量并发短连接的场景，这可能会成为一个需要权衡的因素。

如何选择：场景化的参数调优

综合来看，CUBIC和BBR没有绝对的优劣之分，而是适用于不同的场景。

  • 推荐使用BBR的场景：

    • 高丢包、高延迟的长肥网络（Long-Fat Networks）：例如，跨国数据传输、卫星互联网、移动网络等。在这些场景下，BBR的吞吐量优势能够得到最大程度的发挥。
    • 大文件传输和视频点播：这类应用的核心诉求是高吞吐量，BBR能够确保在复杂的网络条件下依然有流畅的下载体验。
    • 作为服务器端的默认算法：对于大多数提供内容服务的服务器，开启BBR可以显著提升在恶劣网络环境下用户的访问体验。

  • 可以考虑CUBIC的场景：

    • 数据中心内部网络：这类网络通常具有极低的丢包率和延迟，CUBIC的简单高效以及较低的CPU开销，使其成为一个不错的选择。
    • CPU资源高度敏感的嵌入式设备：如果设备性能瓶颈在于CPU，而非网络带宽，使用CUBIC可以节省宝贵的计算资源。
    • 对瞬时延迟抖动极其敏感的应用：虽然BBR的整体延迟表现优秀，但其PROBE_RTT阶段可能引入的微小抖动，在某些极端场景下可能需要被规避。

在实践中，现代的HTTP/3服务器（如Nginx、Caddy）和QUIC库（如quiche、msquic）都提供了切换和配置拥塞控制算法的选项。开发者可以通过简单的配置来启用BBR。例如，在Linux环境下，升级内核至4.9或更高版本，并通过以下sysctl命令即可为系统级的TCP和QUIC连接启用BBR：

sudo sysctl -w net.core.default_qdisc=fq
sudo sysctl -w net.ipv4.tcp_congestion_control=bbr

通过对服务器进行A/B测试，监控关键性能指标（如页面加载时间、视频卡顿率、下载速度），是找到最适合自身业务的拥塞控制策略的最佳途径。HTTP/3赋予我们的这种灵活性，正是其相较于传统协议栈的一大进步，值得每一位网络工程师深入探索和利用。