Ubuntu22.04下BBR与CUBIC拥塞控制算法的性能对比测试

1. 为什么我们要关心拥塞控制算法如果你用过家里的宽带或者在公司里传过大文件肯定遇到过这种情况明明网速标称很高但下载东西就是时快时慢看视频也总在缓冲。很多时候这口“锅”可能不全在运营商或者你的路由器上而是你电脑或服务器里一个默默工作的“交通警察”——TCP拥塞控制算法——在起作用。简单来说想象一下网络就是一条高速公路数据包就是上面跑的车。拥塞控制算法就是这个路口的智能信号灯系统。它的任务是既要让路上的车数据跑得尽可能快高吞吐量又要防止大家一窝蜂挤上去导致全线瘫痪网络拥塞。这个“信号灯系统”的策略好坏直接决定了你的网络体验是“一路绿灯”还是“堵到心塞”。在Ubuntu 22.04这类现代Linux系统中默认的“信号灯系统”是CUBIC一个非常经典、稳健的算法。而近几年一个由Google推出的新算法BBRBottleneck Bandwidth and Round-trip propagation time名声大噪被很多人誉为“网络加速神器”。那么问题来了在咱们日常使用的Ubuntu 22.04系统上把默认的CUBIC换成BBR到底能有多大提升是“史诗级增强”还是“感知不强”特别是在网络环境不那么理想比如延迟高、偶尔丢包的情况下两者的表现差距有多大这就是我今天想跟你聊的。我不是要给你讲一堆复杂的数学公式和论文理论而是想用最“土”的办法在真实的Ubuntu 22.04系统上搭个环境模拟出高延迟、丢包的场景然后让BBR和CUBIC真刀真枪地跑个分。咱们不看广告看疗效。无论你是运维工程师、开发者还是单纯想优化自己服务器或家庭网络性能的极客这篇基于实测的对比分析应该都能给你一些直观的参考。2. 测试前的准备搭建一个可控的“网络实验室”要做对比测试首先得有个公平的擂台。我们不能直接在公网服务器上测因为公网环境瞬息万变干扰因素太多。我的思路是在本地虚拟机或者同一内网的两台Ubuntu 22.04机器上用工具模拟出我们想要的“恶劣”网络条件。2.1 基础环境搭建我用了两台配置相同的虚拟机都安装Ubuntu 22.04 LTS。为什么选22.04因为它默认的内核版本5.15或更高已经原生支持BBR我们不需要折腾升级内核开箱即用这对新手特别友好。你可以用VirtualBox、VMware或者云服务商提供的同区域ECS实例原理都一样。首先在两台机器上我们都确认一下内核版本和支持的算法uname -r # 输出类似 5.15.0-xx-generic大于4.9就支持BBR sysctl net.ipv4.tcp_available_congestion_control # 查看所有可用算法应该能看到 cubic, reno, bbr 等一台机器作为服务端Server另一台作为客户端Client。我们需要一个能生成网络流量的工具这里我选择iperf3。它专门用来测试网络带宽性能能输出非常详细的吞吐量、延迟抖动等数据。在两台机器上安装iperf3sudo apt update sudo apt install iperf3 -y在服务端以守护进程模式启动iperf3监听5201端口iperf3 -s -D-s表示服务器模式-D表示后台运行。你可以用ps aux | grep iperf3检查是否运行成功。2.2 安装并配置网络模拟工具为了让测试有意义我们需要能“制造”出不同的网络环境。Linux下有一个强大的工具叫tc(Traffic Control)它是iproute2软件包的一部分通常系统已经自带。我们可以用它来给网卡“加戏”模拟出延迟、丢包、带宽限制等效果。首先确认一下which tc # 应该输出 /sbin/tc如果找不到安装iproute2sudo apt install iproute2 -y重要提示tc命令功能强大但也很危险操作不当可能导致网络中断。强烈建议你在虚拟机或测试机上操作并且记下清除规则的命令。我们主要用它的netem(Network Emulator) 模块。假设我们的测试网卡是eth0虚拟机通常都是云服务器可能是ens5等用ip addr命令查看。我们将在服务端的网卡上添加规则模拟网络瓶颈。因为在实际场景中服务器的出口网络状况往往决定了连接的性能上限。3. 第一轮对决风平浪静下的基线性能在“搞破坏”之前我们先看看在理想的局域网环境下BBR和CUBIC各自能跑多快。这相当于给两位选手测一下“平跑”成绩建立一个性能基线。首先我们把服务端的拥塞控制算法设置为CUBIC其实默认就是它sudo sysctl -w net.ipv4.tcp_congestion_controlcubic然后在客户端运行iperf3测试持续10秒尝试使用单个TCP连接跑满带宽iperf3 -c 服务端IP地址 -t 10你会看到类似这样的输出Connecting to host 192.168.1.100, port 5201 [ 5] local 192.168.1.101 port 12345 connected to 192.168.1.100 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 1.10 GBytes 9.45 Gbits/sec 0 637 KBytes [ 5] 1.00-2.00 sec 1.10 GBytes 9.45 Gbits/sec 0 637 KBytes ... [ 5] 9.00-10.00 sec 1.10 GBytes 9.45 Gbits/sec 0 637 KBytes --- [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 11.0 GBytes 9.45 Gbits/sec 0 sender [ 5] 0.00-10.00 sec 11.0 GBytes 9.45 Gbits/sec receiver重点关注最后一行的Bitrate这里显示大约9.45 Gbits/sec。这基本是我虚拟网络的理论上限了。同时注意Retr重传为0说明网络完美无丢包。接下来我们在服务端切换到BBR算法。启用BBR需要两步一是设置队列规则二是启用算法# 设置公平队列FQ作为默认队列规则BBR推荐搭配FQ使用 sudo sysctl -w net.core.default_qdiscfq # 启用BBR作为TCP拥塞控制算法 sudo sysctl -w net.ipv4.tcp_congestion_controlbbr验证是否生效sysctl net.ipv4.tcp_congestion_control # 应输出 net.ipv4.tcp_congestion_control bbr然后在客户端再次运行同样的iperf3命令。在我的测试中结果非常接近大约在9.43 Gbits/sec左右。注意这个“设置队列规则”的步骤很关键。我见过不少人只改了拥塞控制算法没改default_qdisc导致BBR效果打折扣甚至不如CUBIC。BBR的设计和FQ队列配合能更好地管理数据包发送节奏。第一轮小结在零延迟、零丢包的理想局域网环境下BBR和CUBIC的性能表现几乎没有区别都能轻松跑满物理带宽。这其实很好理解路又宽又空无论用什么交通调度策略车都能开到限速。所以如果你的服务器和应用都在同一个优质数据中心内网换BBR可能带来的提升微乎其微。真正的战场在“外面”。4. 第二轮对决引入高延迟模拟跨地域传输现实世界的网络很少是零延迟的。当你访问海外网站、跨可用区同步数据时几十到几百毫秒的延迟是家常便饭。延迟对TCP性能的影响是巨大的因为它直接决定了“发送-确认”这个循环的速度。我们用tc工具在服务端的eth0网卡上增加100ms的往返延迟RTT。这大致相当于从中国东部访问美国西海岸的延迟。# 在服务端执行添加50ms的延迟。数据包一去一回总延迟就是100ms。 sudo tc qdisc replace dev eth0 root netem delay 50ms用ping命令从客户端测试一下应该能看到RTT在100ms左右。现在我们先在CUBIC算法下测试# 确保服务端是CUBIC sudo sysctl -w net.ipv4.tcp_congestion_controlcubic # 客户端执行测试 iperf3 -c 服务端IP -t 30 # 时间加长到30秒让连接充分稳定结果让我有点吃惊平均吞吐量从之前的9.4 Gbits/sec 骤降到大约620 Mbits/sec。是的你没看错下降了超过93%这就是高延迟的威力它极大地限制了TCP在每个RTT内能发送的数据量即带宽延迟积。接着切换到BBR算法再测# 服务端切换为BBR sudo sysctl -w net.core.default_qdiscfq sudo sysctl -w net.ipv4.tcp_congestion_controlbbr # 客户端再次测试 iperf3 -c 服务端IP -t 30这次的结果大约是610 Mbits/sec和CUBIC的结果几乎一样甚至略低一点点。第二轮小结在仅有高延迟100ms RTT而没有丢包的情况下BBR和CUBIC的表现再次非常接近两者都因为高延迟而性能大幅下降且下降幅度相当。这说明单纯的高延迟并不是BBR的“主场”。传统的CUBIC算法在应对稳定延迟的网络时其拥塞窗口的增长机制基于三次函数也能较好地探索和利用可用带宽。BBR在这个场景下并没有展现出“魔法”。5. 第三轮对决高延迟丢包地狱难度下的真正考验真正的互联网环境尤其是长途链路往往是延迟和丢包并存的。丢包可能源于线路波动、路由器过载、无线信号干扰等等。传统算法如CUBIC将丢包视为网络拥塞的强烈信号一旦检测到丢包就会大幅降低发送速率这常常会导致性能“雪崩”。现在我们在之前100ms延迟的基础上再给服务端网卡增加1.5%的随机丢包率模拟一个相当恶劣但并非不常见的网络环境。# 在服务端执行在已有延迟规则上增加丢包 sudo tc qdisc replace dev eth0 root netem delay 50ms loss 1.5%首先测试CUBICsudo sysctl -w net.ipv4.tcp_congestion_controlcubic iperf3 -c 服务端IP -t 30测试结果堪称“灾难”平均吞吐量暴跌至仅11 Mbits/sec左右对比仅有延迟时的620 Mbits/sec性能损失超过了98%。iperf3的输出中Retr重传数字会非常高因为CUBIC不断地在“发送-丢包-超时重传-大幅降速”这个循环里挣扎。接下来见证“奇迹”的时刻。切换到BBRsudo sysctl -w net.core.default_qdiscfq sudo sysctl -w net.ipv4.tcp_congestion_controlbbr iperf3 -c 服务端IP -t 30结果出来了平均吞吐量保持在330 Mbits/sec左右虽然比无丢包时下降了约45%但相比CUBIC的11 Mbits/sec性能差距达到了30倍这个对比太鲜明了。我盯着这个结果看了好久反复测试了几次趋势完全一致。BBR之所以能创造这个“奇迹”核心在于其设计哲学的不同。BBR不再把丢包作为拥塞的主要信号而是通过持续测量路径的最小RTT和最大带宽来建立网络模型。它认为只要数据包交付的速率不超过这个最大带宽并且排队延迟没有增加网络就没有真正拥塞。因此即使有随机丢包发生BBR也不会恐慌性地大幅降速而是尝试维持一个接近最大带宽的发送速率通过更快的重传机制来弥补丢包。而CUBIC则像一个谨慎的司机一看到前方有车丢包就猛踩刹车导致速度一直提不上来。6. 深入分析BBR与CUBIC的核心差异与适用场景经过上面几轮实测我们可以更深入地聊聊这两个算法到底不同在哪以及你该在什么情况下选择谁。6.1 工作原理的“世界观”差异你可以把网络路径想象成一条水管。CUBIC是“敲打听声”派。它不停地向水管里注水发送数据然后听回声等待ACK确认。如果某个时间点没听到回声丢包了它就认为水管可能堵了拥塞于是大幅减少注水量拥塞窗口减半然后再慢慢试探着增加。它的核心目标是避免丢包认为丢包就等于拥塞。BBR则是“测量建模”派。它不关心是否丢包而是更关心两个核心指标1) 水管的最大粗细Bottleneck Bandwidth瓶颈带宽2) 水从这头流到那头再流回来的最短时间Minimum RTT。它会主动地、周期性地发送探测包来测量这两个值。一旦建立了这个水管模型BBR就努力让注水速率刚好等于最大带宽同时让水管里的蓄水量在途数据保持在一个很低的水平从而避免在水管里形成长长的“队列”Bufferbloat缓冲区膨胀这正是导致高延迟的元凶。BBR认为排队延迟的增加才是拥塞的真正标志而不是丢包。6.2 各自的优势与短板CUBIC的优势部署广泛极度成熟是Linux、Windows等系统多年的默认算法经过海量设备的长久考验行为可预测。公平性较好在共享带宽的网络中多个CUBIC流之间能够相对公平地竞争。对突发流量友好其“慢启动”和“拥塞避免”机制对短连接、突发性流量适应性不错。CUBIC的短板极度惧怕丢包如前所述在有一定丢包率的长距离网络长肥网络上性能会急剧恶化。容易导致缓冲区膨胀为了充分利用带宽它倾向于填满路由器的缓冲区造成排队延迟飙升这就是你玩游戏时突然高ping的原因之一。BBR的优势高丢包耐受性在丢包率1%-3%的网络中依然能保持很高的吞吐量这是其最亮眼的特性。低延迟通过避免填满缓冲区能显著降低网络排队延迟提升实时应用的体验如视频会议、在线游戏。高带宽利用率能更快地探测并稳定在最大可用带宽上。BBR的短板公平性问题在与CUBIC等传统算法共享带宽时BBR可能表现得“过于强势”抢占更多带宽影响公平性。重传率可能偏高由于其激进的重传策略在某些场景下可能产生不必要的重传浪费带宽。无线网络适应性在Wi-Fi等链路质量波动大的无线环境中其模型可能不准确表现有时反而不如CUBIC。6.3 我该选择BBR还是CUBIC根据我的测试和经验可以给你一些更具体的建议毫不犹豫用BBR的场景你的服务器主要面向公网用户尤其是存在跨运营商、跨国访问的情况。公网丢包难以避免BBR能提供更稳定、高速的体验。你在进行远距离数据传输如异地备份、跨数据中心同步。BBR能极大提升传输效率。你非常在意网络延迟比如运营游戏服务器、视频直播、实时通信服务。BBR降低排队延迟的效果立竿见影。你管理的CDN节点或视频服务器。YouTube、Netflix等大规模部署BBR已经证明了其价值。可以继续用CUBIC的场景你的服务全部运行在高质量的内网或数据中心内部延迟极低且基本无丢包。换BBR收益不大。你的网络环境非常稳定且可控比如实验室内的封闭网络。你非常看重流量公平性并且网络中存在大量混合的、不同算法的流量。一个实用的混合策略 对于一台既对内又对外的服务器其实可以更灵活。你可以通过sysctl为不同的服务监听套接字设置不同的算法需要应用程序支持设置 socket option或者更简单的办法是直接启用BBR。因为对于内网通信BBR和CUBIC性能相当而对于公网访问BBR则具备巨大优势。这相当于为你的服务器增加了一个强大的“公网加速器”。7. 如何在Ubuntu 22.04上启用与优化BBR经过对比如果你决定启用BBR在Ubuntu 22.04上非常简单因为内核支持是现成的。但有些优化步骤能让它工作得更好。7.1 基础启用方法临时生效就像我们测试时做的那样两条命令立即切换sudo sysctl -w net.core.default_qdiscfq sudo sysctl -w net.ipv4.tcp_congestion_controlbbr这能立即生效但重启后会恢复默认。7.2 永久启用并优化配置为了让配置永久生效并做一些常用优化我们需要编辑/etc/sysctl.conf文件。sudo nano /etc/sysctl.conf在文件末尾添加或修改以下几行# 启用BBR net.core.default_qdisc fq net.ipv4.tcp_congestion_control bbr # 以下是一些可选的网络优化参数有助于提升高并发下的性能 # 增大TCP连接可使用的端口范围 net.ipv4.ip_local_port_range 1024 65535 # 允许系统处理更多的TIME_WAIT状态连接 net.ipv4.tcp_max_tw_buckets 2000000 # 加快TIME_WAIT状态连接的回收 net.ipv4.tcp_tw_reuse 1 net.ipv4.tcp_tw_recycle 0 # 注意在较新内核中此参数已被废弃或建议设为0此处仅为示例实际可不加 # 增大最大连接跟踪数 net.netfilter.nf_conntrack_max 1048576 # 增加等待连接队列的长度 net.core.somaxconn 65535保存退出后执行以下命令使配置生效sudo sysctl -p7.3 验证与监控验证BBR是否成功启用sysctl net.ipv4.tcp_congestion_control # 应输出 bbr # 查看当前所有连接的拥塞控制算法使用情况 ss -tin在ss -tin的输出中你可以看到每个TCP连接的详细信息其中bbr会显示在拥塞控制字段。7.4 关于BBR v2和未来在测试和搜索资料时你肯定会看到BBR v2。它是BBR的改进版主要目标是解决v1的公平性问题和降低重传率并加入了ECN显式拥塞通知的支持。从一些公开测试看BBRv2在保持高吞吐量的同时行为上更“温和”更像CUBIC与其它算法的共存性更好。但是截至我写这篇文章的时候基于Ubuntu 22.04的稳定内核BBR v2还没有被合并到主线Linux内核中。它仍然处于开发和测试阶段。虽然你可以通过编译特定内核模块来尝鲜但对于生产环境我强烈建议暂时还是使用成熟的BBR v1。等未来BBR v2进入稳定的LTS内核分支后再迁移也不迟。技术的选择稳定压倒一切。最后我想说的是网络优化没有银弹。BBR在应对公网劣化场景时表现惊艳但它并非完美。最好的方法就是像我们今天做的一样理解原理在自己的业务场景和网络环境下进行实测。用数据说话选择那个能让你的用户和业务体验更流畅的方案。毕竟所有的技术折腾最终都是为了那一点点更快的速度和更顺滑的体验。