Linux 服务器 BBR 拥塞控制开启与验证方法

服务器放在海外或者跨运营商访问时，经常会遇到一种很憋屈的情况：带宽明明买了 10M，实际下载只有一两兆，SSH 操作还一卡一卡的。很多人第一反应是加带宽，其实问题多半出在 TCP 拥塞控制算法上。这篇文章记录一下我在云服务器上开启 BBR 的完整过程，包括开启方法、验证手段和几个容易踩的坑。

一、BBR 解决的是什么问题

传统 Linux 默认的拥塞控制算法是 CUBIC，它的逻辑很直接：只要不丢包就一直加速发包，一旦丢包就认为网络拥塞，立刻降速。在同机房内网这种低延迟、无丢包的链路上这套逻辑没问题；但只要 RTT 上到 100ms 以上，或者链路存在轻微丢包（跨境、跨运营商、移动网络都很常见），CUBIC 就会反复误判拥塞，带宽利用率长期上不去，延迟还忽高忽低。

BBR 是 Google 提出的一套拥塞控制算法，全称 Bottleneck Bandwidth and Round-trip propagation time。它不盯着丢包看，而是周期性地测量两个值：瓶颈带宽（这条链路实际能跑多快）和最小 RTT（链路空闲时的基础延迟），然后算出一个“不排队、尽量不丢包”的最优发送速率，再按节奏均匀发包。效果就是在弱网、高延迟链路上，BBR 的吞吐经常是 CUBIC 的数倍，而且延迟曲线平稳得多。

二、先确认内核版本

BBR 从 Linux 内核 4.9 开始进入主线，先看一眼版本：

uname -r

输出 4.9 以上就可以。现在主流发行版基本都满足：CentOS 7.6+、Ubuntu 18.04+、Debian 9+、openEuler、华为云 EulerOS 都没问题。再确认一下系统自带的可用算法列表里有没有 bbr：

sysctl net.ipv4.tcp_available_congestion_control

输出类似 cubic reno bbr，只要列表里有 bbr 就能直接开，不需要换内核。

三、开启 BBR：只需要两行配置

把下面两行追加到 sysctl 配置里，然后让它立即生效：

echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf
echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf
sysctl -p

简单解释一下：net.ipv4.tcp_congestion_control=bbr 是把默认拥塞控制算法切到 BBR；net.core.default_qdisc=fq 是把队列调度算法换成公平队列，这是 BBR 官方推荐的搭配，能配合 BBR 的 pacing（发包节奏控制）一起工作。sysctl -p 让配置立即生效，不用重启服务器。

如果系统比较新，更推荐把配置写到独立文件里，后续管理更清晰：

cat > /etc/sysctl.d/99-bbr.conf <<'EOF'
net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr
EOF
sysctl --system

两种写法效果一样，选一种就行，不要重复配置。

四、验证是否真的生效

改完不要想当然，用两个命令确认。第一个看当前默认算法：

sysctl net.ipv4.tcp_congestion_control

预期输出：net.ipv4.tcp_congestion_control = bbr。第二个看内核模块有没有加载：

lsmod | grep bbr

预期能看到 tcp_bbr 这一行。两个都对上，说明新建立的 TCP 连接就会走 BBR 了。

还有一个更直观的验证方式：找一条正在传数据的连接，看它实际协商的拥塞控制状态：

ss -tin

输出里连接详情如果带 bbr 字样，还能看到 bw、mrtt 这类字段，说明这条连接正在用 BBR 的带宽模型发包，这是最硬的证据，比只看配置靠谱。

五、实际效果对比

我在一台海外地域的 ECS 上做过简单测试：2 核 4G、5M 带宽，用 iperf3 从一个 RTT 约 180ms 的客户端往服务器打流，两种算法各测三轮取平均：

5M 带宽基本能跑满。当然这个数字仅供参考，提升幅度跟链路质量强相关：RTT 越大、丢包越明显，BBR 的优势越大；如果是同地域同可用区的内网互访，延迟只有零点几毫秒，换不换 BBR 体感几乎没区别，没必要折腾。

六、几个注意事项

第一，不要和其他“加速”脚本叠加使用。 网上一些一键脚本会通过更换内核或者加载锐速一类的内核模块来加速，和 BBR 的机制冲突，叠加后经常出现断流、速度不升反降，二选一就行。

第二，关注多流共存时的公平性。 BBR 在和 CUBIC 流量共存时相对强势，会抢占更多带宽。在自家服务器的出方向上用没问题；如果是在共享出口的内网环境大面积部署，建议先小范围上线观察一周。

第三，新版本 BBR 的变化。 较新的内核合入了 BBRv2，对丢包的容忍度更好，多流公平性也有改进。如果是新装的机器、内核够新，直接用系统默认带的版本就可以；老机器没必要为了 v2 专门折腾换内核，v1 在绝大多数场景下已经够用了。

第四，容器环境要在宿主机上开。 拥塞控制是内核层面的机制，Docker 容器和宿主机共用内核，在容器里改 sysctl 不生效，得在宿主机上开；ECS 这类虚拟机有自己独立的内核，在系统内开启即可。

七、小结

BBR 是那种成本几乎为零、收益看得见的优化：两行配置、一条命令生效、一分钟验证完成。对于面向公网提供服务、用户分布跨地域跨运营商的服务器，建议把它作为装机后的标准动作之一。当然它也不是万能药，如果瓶颈本身就在带宽上限或者应用层性能上，应该先解决主要矛盾，拥塞控制优化更多是锦上添花。