【TCP优化 01】美国 VPS 跑不快？多半是没开 BBR，一个命令帮你提速几倍

先讲个让不少人破防的场景：同样一台美国 VPS，配置一模一样，价格一模一样，别人用它传大文件、看视频，速度嗖嗖的；你用它，下载个东西半天不动，网页打开要转圈圈。你以为是自己运气差抽到了"坑逼服务器"，其实真相很可能只有一个——对方开了 BBR，你没开。这个叫 BBR 的东西，是 Google 在 2016 年放出来的一个免费"外挂"，能让跨境传输速度翻好几倍。今天就用大白话把它讲明白。

延伸阅读

更多相关攻略推荐：刚买的 VPS 怎么连上去？SSH 新手教程（Windows / M、【VPS 硬件选型指南 (存储 篇) 03】主流商家磁盘实情横向盘点、【VPS 硬件选型指南 (存储 篇) 02】到手如何验货：fio 实、VPS 的带宽、流量、端口到底是啥？1Gbps 和 10TB 流量怎、【VPS 进阶玩法精选 022】VPS 计费门道：预付、按比例、发票。

先搞清楚：网络为什么会"堵车"？

想象一下，你从北京开车去洛杉矶，路上要经过很多"收费站"，这些收费站就是路由器。数据从你的 VPS 发到国内用户手里，要拆成一包一包的数据包，一个收费站一个收费站地过。每个收费站都有个"排队缓冲区"，来车太多了，先排着；缓冲区塞满了，后来的车直接劝返——这就是"丢包"。

问题来了：TCP 协议（互联网传输的基本规则）特别怕丢包。因为它把丢包当成"路太堵了"的信号，一旦发现有数据包丢了，立刻判断"前面堵车了，我刹车减速！"于是发送速度瞬间降下来，等一会儿再慢慢加油门。这个逻辑在 1988 年的互联网上是天才设计，但放到今天的中美线路上，就成了灾难。

传统算法（Cubic、Reno）的致命伤：一丢包就刹车

在 BBR 出现之前，主流拥塞控制算法是 Reno 和 Cubic，Linux 默认用的就是 Cubic。它们的思路可以用一句话概括：靠丢包来判断路况。路好就拼命加速，路差（丢包）就猛踩刹车。听上去挺合理对吧？但它有个致命问题：跨国线路上，丢包很多时候跟"堵车"没有半点关系。

中美之间的海底光缆大约 1 万公里，光信号一来一回就要 180 到 250 毫秒。这么长的路上，随便哪段线路出点小状况、路由器稍微忙一下、甚至运营商限个速，都会造成零星丢包。传统算法一看到这些丢包就以为"堵死了"，开始疯狂减速，于是你的带宽明明有 100M，实际跑出来只有几 Mbps——高速路空荡荡，你却在 40 码龟速爬行。

更扎心的是，Cubic 这类算法的窗口增长是"试探性"的：先加速，撞到丢包，砍半，再慢慢加。在美国国内低延迟环境里这套没问题，但换到 200ms 延迟的中美线路上，每个"试探—减速"周期都要等好几个来回，效率低到令人发指。有数据为证：Cubic 在丢包率超过 0.1% 时吞吐量就开始明显下滑，丢包率到 5% 时基本等于废掉；而 BBR 在 5% 丢包率下依然能跑出接近理论极限的速度。

还有一层更隐蔽的伤害叫"缓冲膨胀"。现代路由器缓冲区做得越来越大，丢包之前会先积压一大排数据，导致延迟悄悄暴涨。传统算法看不到排队，只会继续加速把缓冲区灌爆，于是你经常遇到这种怪事：网速没变快，延迟却越来越高。Cubic 对这种"假顺畅"毫无办法，因为它眼里只有丢包，压根不感知延迟。

BBR 的革命性玩法：不猜路况，直接量管道

2016 年 9 月，Google 的工程师团队（Neal Cardwell、Yuchung Cheng 等人）把 BBR 提交进了 Linux 内核，2017 年随内核 4.9 正式集成。BBR 全称 Bottleneck Bandwidth and Round-trip propagation time，翻译成人话就是"测量瓶颈带宽和往返时间"。

它和传统算法的最大区别在于：传统算法是"撞了网络封锁才知道有网络封锁"，BBR 是"先量好网络封锁在哪，再匀速通过"。BBR 不再把丢包当信号，而是不断测量两条关键数据——这条链路最大能跑多快（瓶颈带宽），以及数据一来一回最少要多久（最小 RTT）。两个数字一乘，就得到了"管道容量"，也就是 BDP（带宽延迟积）。之后 BBR 做的事只有一件：精确地按照管道容量去发数据，不多发一包、也不少发一包。

这就像两个人从北京开车去上海：传统算法是"先油门踩到底，撞了护栏再退回来，再踩，再撞"；BBR 是先查清楚"这条路限速多少、有几条车道"，然后全程顶着限速稳稳开。前者在空旷高速上没问题，但一旦路上有坑坑洼洼（丢包），就会一直撞护栏；后者压根不受影响，照样匀速前进。这就是为什么高丢包、高延迟的跨境线路上，BBR 的收益能大到离谱。

具体怎么做到的？BBR 内部有一套"探路"流程：先用 Startup 阶段快速把速度顶到最高，再用 Drain 阶段把路上攒下的排队数据排空，接着进入 ProbeBW 周期性地小幅试探带宽有没有变化，最后用 ProbeRTT 阶段压低速率去量一次最小延迟。四个阶段轮流转，保证任何时候都贴着管道容量走——既不吃亏，也不冒进。

真实数据有多夸张？Google 自己都惊了

吹得再玄乎，不如看数字。Google 在自家 B4 骨干网上实测，BBR 比 CUBIC 的吞吐量稳定高出 2 到 25 倍；在一条高丢包的线路上，把接收缓冲区调大后，BBR 跑到了 2Gbps，而 CUBIC 只有 15Mbps——差了 100 多倍。在 YouTube 上做的大规模实验更直观：全球平均 RTT（延迟）中位数直接降了 53%，在发展中国家甚至降了 80% 以上；YouTube 全球平均吞吐量提升 4%，部分国家提升超过 14%。

对我们普通用户来说，最有共鸣的是那句"跨境翻倍"：有第三方在洛杉矶到上海的线路上实测，换成 BBR 后平均吞吐量提升了 47%，RTT 抖动减少了 63%。注意，这些不是玄学，是同一台机器、同一条线路、只改一个内核参数的结果。你的 VPS 跑得慢，很多时候真不是服务器的锅。

Google 论文里还给过一个吓人的对比：链路丢包率只要到 0.1%，CUBIC 的吞吐量就掉到原来的十分之一，丢包率到 1% 基本瘫痪；而 BBR 在 5% 丢包率下还能跑出接近理论极限的速度，到 15% 才明显衰减。换句话说，Cubic 眼里 0.1% 的"小堵"就够它放弃治疗，BBR 眼里 5% 的"堵车"也只是洒洒水。

两行命令，给 VPS 免费开外挂

好消息是，2017 年之后买的 VPS，系统内核基本都是 4.9 以上，BBR 早就内置了，只是默认没开。打开它只需要两行命令：

• 先确认内核版本：输入 uname -r，返回 4.9 以上就稳了。
• 写入配置：echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf 和 echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf。
• 让配置生效：sysctl -p。
• 验证一下：输入 sysctl net.ipv4.tcp_congestion_control，返回 bbr 就大功告成。

如果你买的是很老的机器，内核版本太低，也可以用网上的 BBR 一键脚本（比如知名魔改版）帮你自动升级内核并开启。Debian 9、Ubuntu 18.04 之后的系统，原生就支持，不用装任何额外软件，改完立即生效，连重启都不用，更没有封号风险。

顺便说两个排查小技巧：先用 sysctl net.ipv4.tcp_available_congestion_control 看看系统支持哪些算法，如果结果里没有 bbr，说明内核太老，得走一键脚本路线；改完再用 lsmod | grep bbr 确认模块加载成功。整个过程三五分钟，比跑去跟客服扯皮有效率多了。

对你买 VPS、用服务器有什么启发？

把话题拉回你关心的：买国外 VPS 跑国内业务，BBR 就是成本最低、见效最快的免费提速手段，没有之一。但不同线路，收益天差地别：

• 高丢包的普通线路（比如很多廉价美国 VPS）提升最猛，开完 BBR 速度翻倍是常态，这就是 RackNerd、CloudCone 这些便宜小鸡的"隐藏价值"。
• 优化线路（比如 CN2 GIA、DMIT 这类主打低延迟的商家）本身丢包就低，传统算法已经跑得不错，BBR 的提升空间有限，但开了也无妨，反正不花钱。
• 如果你是重度跨境用户（建站面向国内、挂代理、传数据），强烈建议一买来就顺手开掉 BBR。操作一分钟，收益一整年。

最后说句公道话：BBR 也不是没有争议，它占了带宽会挤占旁边用 Cubic 的流量，学术圈对它的公平性一直有讨论。但对你这种"个人用、买便宜 VPS 跑自己的站"的场景，这点争议可以忽略。记住这句话：如果你的美国 VPS 跑不快，先别急着骂商家、别急着退钱，开个 BBR 试试——很可能一个命令，世界就清爽了。

再补充一个进阶知识：BBR 后来还出了 BBRv2 和一堆民间魔改版（比如 BBR Plus、锐速），它们在公平性和抗丢包上各有取舍。对普通用户来说，原生 BBR 已经够用，魔改版提升有限还可能带来稳定性风险，不建议一上来就折腾。先开原生的，跑一周看看效果再说。