美国服务器丢包率太高不用换服务器，试试BBR加速算法！

　　很多人以为丢包就是“网不好”，这个说法太笼统了。实际上，美国服务器的高丢包率，根源在于两个东西：物理距离和TCP协议的“老派作风”。

　　先说物理距离。从中国到美国西海岸，光缆长度大约1万多公里。光速再快，一个来回也要120-150毫秒。这还只是理论值，加上沿途路由器的处理时间，RTT普遍在180-250ms之间。距离远，意味着数据包在路上的时间长，遇到干扰、被丢弃的概率自然就高。

　　再说TCP协议的传统算法。你服务器上默认用的拥塞控制算法，多半是Cubic或者Reno。这两个算法有个共同特点——它们把“丢包”当作网络拥堵的信号。一旦检测到丢包，就立刻降低发送速度，等网络“缓过来”再慢慢提速。

　　这个设计思路在局域网或者延迟低的环境下没毛病，但在跨国链路上就出问题了。因为跨太平洋的链路本身就容易丢包，哪怕带宽还很充裕、路由器也没堵，传统算法也会“误判”为拥堵，然后主动“认怂”降速。结果就是：明明有路可以走，你的服务器却自己踩了刹车。

　　说白了，Cubic在丢包率超过0.1%的时候吞吐量就开始明显下降，到丢包率5%的时候基本就废了。而BBR呢?在同样的丢包环境下，依然能保持较高的吞吐量，直到丢包率超过5%才开始明显衰减。这个差距，用一句话总结就是：Cubic怕丢包，BBR不怕。

　　BBR到底是什么?用一句话说清楚

　　BBR的全称是Bottleneck Bandwidth and Round-trip propagation time，翻译过来是“瓶颈带宽和往返传播时间”。名字拗口，但道理不复杂。

　　传统的Cubic算法，它的工作方式是“试探-撞墙-后退”：先加速发数据，直到把路由器的缓存填满、开始丢包，然后立刻减速，等缓存清空再慢慢加速。周而复始。这个过程中，路由器缓存被填满的那段时间，数据包排队等着处理，延迟飙升;丢包发生的时候，数据被丢弃，效率下降。

　　BBR的做法完全不同。它不等到丢包才反应，而是实时测量两个关键数据：当前链路的实际带宽上限，以及数据包在路上“纯跑”需要的最短时间。有了这两个数据，BBR就能精确计算出“在不造成拥堵的前提下，我应该以多快的速度发数据”。

　　打个比方：Cubic像个毛头小伙子，跑到路口发现堵车了才猛踩刹车，等不堵了又一脚油门冲出去，反复折腾。BBR像个老司机，提前观察路况和车流速度，始终保持一个刚刚好的速度，既不闯红灯也不龟速行驶。

　　效果怎么样?Google在YouTube上实测的数据是：启用BBR后，全球平均吞吐量提升了4%，在日本等网络条件复杂的地区提升超过14%，同时RTT降低了33%。还有一家叫WordPress的托管平台，启用BBR后吞吐量提升了2700倍——当然这个数字太夸张了，应该是某些极端场景下的结果，但也足以说明BBR的威力。

　　怎么开启BBR?三分钟搞定

　　OK，理论说完了，来点实操。开启BBR真的不难，不需要编译内核、不需要安装额外软件，系统自带了，只是默认没开。

　　第一步：检查你的内核版本

　　BBR需要Linux内核4.9及以上版本。先看看你的服务器符不符合要求：

uname -r

　　如果输出类似5.x.x或者4.x.x且x≥9，恭喜你，可以直接开。如果输出是3.x.x，需要先升级内核(这一步稍微麻烦点，但网上教程很多，或者直接用一键脚本)。

　　第二步：确认系统支持BBR

sysctl net.ipv4.tcp_available_congestion_control

　　如果输出里包含bbr，说明内核已经编译了BBR模块，可以直接启用。

　　第三步：修改系统配置

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

　　第一行设置了队列规则(fq配合BBR效果最好)，第二行指定拥塞控制算法为BBR，第三行让配置生效。

　　第四步：验证是否成功

sysctl net.ipv4.tcp_congestion_control

　　输出应该是net.ipv4.tcp_congestion_control = bbr。再跑一个命令确认模块已加载：

lsmod | grep bbr

　　看到tcp_bbr字样，大功告成。

　　整个过程不超过3分钟，不需要重启服务器(某些情况下可能需要重启，取决于内核配置)。如果你嫌手动输入麻烦，网上也有一键脚本，但我建议手动操作，就两行命令的事儿，自己敲更放心。

　　BBR不是万能的，别神话它

　　说了这么多BBR的好，我也得泼点冷水。BBR不是“网络加速器”，它解决的是特定问题——高延迟、高丢包环境下的TCP传输效率。它不是CDN，不能帮你“就近分发”;它不是带宽扩容，不能突破你服务器实际带宽的上限。

　　另外，BBR也不是所有场景都适用。如果你服务器的流量主要是内网通信、延迟很低(比如10ms以内)、丢包率几乎为0，那BBR的优势就不明显，Cubic已经够用了。BBR的舞台是跨太平洋、跨大洲这种“长肥网络”。

　　还有一种情况：如果你的丢包是运营商线路质量问题导致的严重丢包(比如超过10%)，BBR也救不了你。算法优化不是魔术，物理层的顽疾还是要靠换线路来解决。

　　我的建议很简单：如果你的服务器满足Linux内核4.9+、主要服务对象在海外或跨网访问、偶尔感觉“卡卡的”但带宽又没跑满——直接开，没有副作用。

　　它不花钱、不改业务代码、不影响现有服务，两行命令的事。开了之后用一段时间感受一下，大多数情况都能感觉到变化。SSH敲命令的时候是不是更跟手了?网站后台是不是更快了?文件传输是不是更稳了?

　　如果开了之后还是慢，那问题可能真不在算法上，该换线路换线路，该加CDN加CDN。但至少，BBR帮你排除了一个最容易被忽视的可能性——不是服务器不行，是它没选对“走路姿势”。