BBR 拥塞控制算法：为什么服务商端的系统内核优化如此重要？
#BBR加速#拥塞控制#TCP原理
阅读需 4 分钟||
在使用跨国网络节点时，您是否发现有些节点即使延迟高达 200ms，播放 4K 视频依然顺畅；而某些节点稍有丢包，速度便呈断崖式下跌？这与服务器底层的 TCP 拥塞控制算法 息息相关。
1. 传统拥塞控制的痛点 (如 Cubic)
互联网是由无数个路由器串联而成的。由于早期带宽昂贵，传统的拥塞控制算法（如 Cubic）采取了“基于丢包的退让机制”。 它的逻辑是：一旦检测到网络链路上发生丢包，算法就会认为“网络拥堵了”，并立即将发送窗口减半，大幅降低发送速度。 在跨国长距离传输中，由于物理线路复杂，偶尔因为信号波动产生几丁丢包是常态。Cubic 会将这些物理丢包误判为拥堵，导致速度被牢牢锁死在低位，这也是早期代理网络体验极差的根源。
2. Google BBR 的颠覆性逻辑
Google 开发的 BBR (Bottleneck Bandwidth and Round-trip propagation time) 抛弃了把丢包当作唯一标准的做法。 BBR 的核心在于实时测量链路上真实的瓶颈带宽与往返延迟：
- 它不再害怕偶发的物理丢包，只要测量到链路上还有可用带宽，它就会持续向网络中注入数据，直到探测到延迟开始显著攀升（真正发生拥堵堆积）。
- 这种主动测量机制使得 BBR 能够在丢包率高达 5% 甚至 10% 的恶劣跨国线路上，依然维持极其可观的吞吐量，拯救了无数低质量线路。
3. BBR 是如何生效的？
单边加速机制：必须注意，BBR 是作用于数据发送端的。 对于下行流量（如观看 YouTube 视频），数据的发送方是代理节点服务器，因此BBR 必须在机场服务商的 VPS 节点系统内核中开启才能起效，你在本地电脑或软路由开启 BBR 对下载速度的提升微乎其微。只有当你向海外上传大量数据时，本地路由器开启的 BBR 才具备决定性作用。