做跨境业务的人，应该都有过这种体验——服务器在日本东京，机房看着挺高级，带宽给的也不少，可一到国内晚高峰，SSH敲个命令都卡得跟幻灯片似的，更别提传文件或者跑API了。问题出在哪?很多时候不是带宽不够，是TCP拥塞控制算法在跨太平洋这种“长肥管道”上水土不服。这篇文章不聊虚的，直接从内核层面讲清楚BBR的原理，以及在日本服务器上怎么把它配好、调稳。

　　BBR解决的是什么问题?

　　传统Linux默认的CUBIC算法，本质上是个“基于丢包”的拥塞控制。它的逻辑很简单：没丢包就往死里发，直到把路由器的缓存塞满，开始丢包了，再乘性减窗退回去。

　　这个逻辑在局域网或者跳数少的网络里还行，但在中日跨境这种场景下就出问题了。因为丢包不一定是因为拥塞，也可能是线路干扰、运营商限速、甚至是路由器的ECN策略导致的。但CUBIC不管这些，只要丢包它就认为是拥塞，然后猛降发送速率，吞吐量直接断崖。

　　BBR的思路不一样。它不再把“丢包”当成减速的信号，而是主动去测量链路的瓶颈带宽和最小往返时间，然后把发送速率精确控制在BDP(带宽时延积)附近。这样一来，数据包排队的现象少了，RTT稳了，吞吐量自然就上去了。

　　根据Google在YouTube上的实践数据，BBR上线后网络吞吐量平均提升了4%以上，在一些高延迟链路场景下甚至能达到14%的增幅。

　　内核版本与前置检查

　　BBR算法是在Linux内核4.9版本正式合入主线的。日本的VPS或独立服务器，如果是近两年的镜像，内核版本通常都在4.9以上。但如果你的机器是CentOS 6或者Debian 8这种老古董，就得先升级内核。

　　登录服务器后，第一件事是确认当前内核版本：

uname -r

　　如果输出是4.9.0或更高，那就省事了。接着看看当前系统支持的拥塞控制算法列表：

sysctl net.ipv4.tcp_available_congestion_control

　　正常情况下，输出里应该能看到bbr。如果bbr没出现在列表里，说明内核编译时没把它编进去，这种情况比较少见，遇到了就只能换内核或者自己编译模块。

　　开启BBR与队列规则配置

　　开启BBR的操作不复杂，核心就两行sysctl配置，但这里有个细节很多人会忽略——队列规则的搭配。

　　BBR官方推荐配合fq(公平队列)使用。fq的作用是对不同TCP流做公平调度，避免某个大流量连接把整个出口带宽占死，这样BBR的 pacing( pacing 是 BBR 的速率整形机制，用来平滑发包间隔)机制才能发挥最大效用。

　　编辑/etc/sysctl.conf文件，在末尾追加：

net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

　　保存后，让配置生效：

sysctl -p

　　验证是否切换成功：

sysctl net.ipv4.tcp_congestion_control

　　看到输出net.ipv4.tcp_congestion_control = bbr，就说明当前所有新建TCP连接都已经在用BBR了。再用lsmod | grep bbr看一眼内核模块有没有加载，如果没输出也正常，很多发行版直接把BBR编译进内核了，不需要单独挂载。

　　进阶调优：针对日本跨境链路的参数微调

　　BBR打开只是第一步，想要让它在日本到中国的链路上跑得更好，下面这几个参数值得调整。

　　初始拥塞窗口调大

　　TCP的初始拥塞窗口(initcwnd)默认是10个MSS(最大报文段长度)，对于跨境这种高延迟链路来说太保守了。把初始窗口调到20甚至30，能明显减少小文件传输的往返次数，加快页面加载速度。

# 临时调整（重启网卡或系统后失效）
ip route change default via 网关IP dev eth0 initcwnd 20

# 永久生效需要在网卡配置或rc.local里写脚本

　　TCP时间戳与窗口缩放

　　对于RTT超过50ms的跨境链路，TCP窗口缩放(Window Scaling)必须开启，否则窗口大小受限，带宽再大也跑不满。

　　检查下面几个参数是否已经设为1：

sysctl net.ipv4.tcp_timestamps=1
sysctl net.ipv4.tcp_window_scaling=1
sysctl net.ipv4.tcp_sack=1

　　这些在较新的Linux发行版里通常默认就是开的，但老系统可能不是，确认一下没坏处。

　　MTU与MSS的坑

　　日本机房到国内骨干网，中间经过的路由器MTU(最大传输单元)可能不一致。如果MTU设置不当，数据包被分片，性能会大打折扣。

　　有的日本机房为了避免IPsec封装导致的问题，建议把eth0的MTU改到1440甚至更小。但具体设多少，得看机房的网络环境。一个比较稳妥的做法是开启PMTU(路径MTU发现)：

sysctl net.ipv4.ip_no_pmtu_disc=0

　　这样内核会自动探测路径上的最小MTU，避免手动设置不当导致丢包。

　　验证加速效果

　　改完参数，别急着欢呼，先跑个实测。

　　看RTT和丢包率，用mtr看比ping直观得多。从国内机器往日本服务器打mtr，观察每一跳的丢包率和延迟。理想情况下，开启BBR后虽然中间节点的延迟不会变，但尾部的延迟抖动(jitter)应该会降下来，因为排队现象减轻了。

　　看吞吐量，在服务器端起一个iperf3服务：

iperf3 -s

　　在国内客户端用多线程打流：

iperf3 -c 日本服务器IP -t 60 -P 10

　　对比开启BBR加速前后的带宽数值，如果能看到明显提升，那这几分钟的配置就没白干。

　　BBR不是银弹，它解决的是“拥塞控制”的问题，救不了物理距离和光速延迟，也替代不了CN2 GIA这种优质线路。但如果你的日本服务器跑跨境业务总觉得“发不上力”，那么BBR这套组合拳，值得一试。