BBR vs BBRplus vs BBR3 实测：同链路同规则下的吞吐与抗丢包对比

发表于 分类于
拒绝脑补脑测。公开同机、同链路、同 fq 排队规则下的 BBR / BBRplus / BBR3 对比实测方法与基线数据，吞吐与重传率等核心指标待实测补全。

在各类 VPS 交流群和论坛里，关于拥塞控制算法的争论从未停止过：“BBRplus 才是晚高峰战神”、“BBR3 修复了一切”、“原版 BBR 已经足够好”。

但绝大多数讨论要么停留在几年前的经验主义，要么是不同机器、不同线路之间的"跨服比较"。本篇实测坚持控制变量原则：在同一台测试 VPS、同一条跨洋网络链路、相同的 fq 排队规则下，分别切换原版 BBR、BBRplus 与 BBR3 进行量化实测。

一、测试环境与测试方法（控制变量）

为了避免链路波动干扰，所有测试均在固定时间窗口内交叉重复 3 次取中位数。

  • 服务端（VPS）配置：
    • 系统基准：Debian 12 纯净系统
    • 机房链路：美西圣何塞普通骨干网（平均 RTT 约 165ms，晚高峰伴随 3%~8% 随机丢包，基线用 NextTrace 测得）
    • 排队规则（qdisc）：统一锁定为 fq（net.core.default_qdisc = fq）
  • 客户端（测试端）：
    • 国内家庭宽带（千兆下行 / 100M 上行）
  • 受测内核与算法版本：
    1. 原版 BBR (BBRv1)：Debian 12 官方 Linux 6.1 LTS 内核自带 tcp_bbr
    2. BBRplus：第三方维护的 Linux 5.15 BBRplus 移植分支
    3. BBR3 (BBRv3)：XanMod 6.x 内核内置的 Google BBRv3 分支

注意：三者分别依赖不同内核（6.1 / 5.15 / 6.6-xanmod），内核版本本身也是一个变量。严格说这是"同机、同链路、不同内核"的对比，解读结果时要留这个余量——这是目前个人实测条件下能做到的最接近控制变量的方案。

测试执行命令链

1
2
3
4
5
6
7
8
9
10
11
12
# 1. 确认当前生效算法与排队规则
sysctl net.ipv4.tcp_congestion_control
sysctl net.core.default_qdisc

# 2. 服务端启动 iperf3
iperf3 -s -p 5201

# 3. 客户端单线程测极限吞吐与重传率（持续 30 秒，反向下载流）
iperf3 -c [服务端IP] -p 5201 -t 30 -P 1 -R

# 4. 本地真实大文件单流拉取耗时测试
curl -o /dev/null -w "AvgSpeed: %{speed_download} B/s, Time: %{time_total}s\n" http://[服务端IP]/test_1gb.bin

二、实测对比数据汇总

说明：下表中已出数值的为当前基准环境实测所得；链路波动大、需针对特定弱网条件复测的指标如实标注为 [待实测]，不脑补、不美化，测出来就补上。

评估维度 原版 BBR (v1) BBRplus BBR3 (v3)
内核版本 Linux 6.1.0-amd64 Linux 5.15.x-bbrplus Linux 6.6.x-xanmod (BBRv3)
基准闲时 RTT ~163 ms ~164 ms ~163 ms
闲时单流极限吞吐（0%丢包） [待实测] Mbps [待实测] Mbps [待实测] Mbps
晚高峰单流吞吐（中度丢包） [待实测] Mbps [待实测] Mbps [待实测] Mbps
iperf3 统计重传次数（Retr） [待实测] 次 [待实测] 次 [待实测] 次
满载时 RTT 延迟膨胀 [待实测] ms [待实测] ms [待实测] ms
系统运行稳定性 / 崩溃风险 官方级，极高 依赖第三方补丁，中等 良好，随现代内核演进

三、基于算法原理的预期差异（待实测验证）

以下为根据各算法设计原理推导的预期，不是实测结论。等上面的 [待实测] 数据补全后，再回头验证这些预期对不对。

1. 面对随机丢包时的窗口退让策略

  • 原版 BBR (v1)：依靠 BtlBw（瓶颈带宽）和 RTprop（往返传播时间）模型运行，轻度丢包下速度衰减预计明显好于传统 Cubic；但在多流并发或突发恶劣丢包下，理论上可能陷入"过度悲观"降低发包速率。
  • BBRplus：设计上非常激进，修改了丢包判断和发包时限，即使丢包也不轻易大幅退让。预期在晚高峰高丢包链路上单流测速能跑出亮眼数据，但代价可能是重传包数量大幅攀升——用浪费带宽换吞吐，实测时重点看 Retr 列。
  • BBR3 (v3)：Google 针对 BBRv1 饱受诟病的"抢占不公"和"拥塞响应迟钝"做了重构。预期它对丢包的响应比 BBRplus 更克制，重传率更低，拥塞恢复时升窗爬坡更平滑。

2. Bufferbloat（缓冲膨胀 / 排队延迟）

测试方法：满速下载大文件时同步对 VPS 发起连续 ping 探测。预期：

  • BBRplus 因发包激进，可能把中间路由器缓冲区塞满，延迟抖动最大，打游戏或 SSH 操作时或有顿挫感；
  • BBR3 在抗 Bufferbloat 方面预期表现最收敛。

四、选型结论与实操建议

根据算法特性和已出基线数据，给出阶段性建议（等完整实测数据出来后更新）：

  1. 不想折腾、求绝对稳定 → 直接用原版 BBR
    • Debian 10/11/12 及现代 Ubuntu 系统开箱即用，两行 sysctl 命令开启，不需要更换任何第三方内核，杜绝换内核后失联进不去系统的风险（换内核前建议先看《Linux VPS 排障手册》里的救砖部分）。
  2. 重度恶劣丢包线路、只看极致单流速度 → 可尝试 BBRplus
    • 仅推荐在玩具小鸡或非核心业务机上使用。注意：BBRplus 内核版本较老，如果宿主机 CPU 架构较新可能存在兼容隐患。
  3. 长期主力建站、兼顾速度与低延迟 → 推荐 BBR3
    • 配合更新活跃的 XanMod 内核使用（XanMod 搭配 BBR3 教程），既有现代内核的安全补丁和调度器优势，又享受 Google 最新的拥塞控制算法迭代。