深入理解 TCP 拥塞控制：BBR, Cubic 与代理链路的化学反应

#拥塞控制#BBR算法#链路优化

阅读需 5 分钟|发布于 2026/10/10|更新于 2026/10/10

在探讨海外云服务器的网络优化时，TCP 拥塞控制算法如同调节汽车引擎喷油量的中枢。但对极客而言，仅仅“一键开启”是不够的，你必须理解 Cubic 与 BBR 算法的底层逻辑，才能明白为何乱调配置往往适得其反。

1. 拥塞算法是如何工作的？

您可以把从服务器到您家里的网络看作一条长满红绿灯的公路。由于跨国链路质量极其复杂，沿途有成百上千辆车（数据包）在行驶。

老派的 Cubic 算法：它的逻辑是盲目试探。服务器会不断疯狂发车，直到某一个十字路口（骨干网路由器）报告拥堵甚至强行拦停车辆（物理丢包）。Cubic 一旦收到丢包信号，会吓得立刻把后续的发车量直接砍半。如果这条公路本身路况极差、时不时因为坑洼丢失几辆车，Cubic 会判定这条路死堵了，结果明明还有很宽的车道，却只敢一辆一辆慢吞吞地发，导致您的代理速度常年锁定在几百 KB/s。
激进的 BBR 算法：Google 设计的 BBR 放弃了以“是否丢包”作为刹车信号。它派出了侦查兵去实时测量整条路的真实容量极限 (带宽) 和通过时间 (延迟)。即使路上丢了几辆车，只要侦查兵报告这条路上大卡车依然跑得飞快，BBR 就会继续全速发车，无视微小的物理颠簸，以此抢占最大的公网出口吞吐。

许多新手在自己家里的 OpenWrt 软路由上拼命开启并研究 BBR 的各种变种版。这是一个重大的认知误区。

当你在用代理看 YouTube 时，海量的数据是从海外节点服务器流向你家，此时发包的主动权掌握在远端海外服务器的内核手里。
你在本地软路由上开启 BBR，只能优化你向海外上传的零星数据包（比如上传一个照片）。只有当远端机场服务商的母鸡开启了卓越的 BBR，你的下载速度才会起飞。

BBR 是极其霸道的，它会强行排挤链路上其他老实巴交的 Cubic 流量。如果两台同样跑满 BBR 的机器在某条拥挤的海缆上相遇，可能会发生疯狂的碰撞。对于自建节点的极客，请使用新版的 BBRv3 等拥有更好退让和平滑机制的内核算法，避免由于发包过于野蛮被部分机房网管强制介入封禁端口。