你可能遇到过这样的情况：家里明明是百兆甚至千兆宽带，但在下载海外开源代码包、拉取镜像或观看 4K 高清内容时，速度仍然很慢。这类问题不一定是“带宽不够”，也可能来自传统拥塞控制算法在长距离跨境链路中的滞后性。
传统 CUBIC 算法：丢包即减速
互联网早期，为了避免网络过载，TCP 拥塞控制算法（如 Reno、CUBIC）采用了相对保守的判断逻辑：只要发生丢包，就倾向于认为链路已经拥堵。
在跨国长距离传输（High BDP 网络）中，无线干扰、跨境节点转发、链路质量波动都可能产生少量“随机非拥堵丢包”。一旦触发丢包，CUBIC 可能会误以为网络已经堵塞，快速降低发送速率，然后再缓慢试探带宽。这会导致长距离公网传输的带宽利用率明显下降。
CUBIC 更像是“看到丢包就刹车”；BBR 更像是“持续估算这条路真实能跑多快”。两者关注的信号不同，弱网和跨境场景下的表现也会不同。
BBR 的思路：看容量，不只看丢包
Google 推出的 BBR（Bottleneck Bandwidth and RTT） 拥塞控制算法，不再只把丢包当作拥堵的唯一信号。它会动态估算链路中的瓶颈带宽和最小往返时间，从而推算整个传输链条的“管道容量”。
只要管道没有被真正塞满，即使跨境链路中出现一定比例的随机丢包，BBR 仍然可以保持更稳定的发送效率。它的目标是让链路尽量接近可用容量，而不是因为少量波动就大幅降速。
| 算法 | 主要关注点 | 跨境弱网中的常见表现 |
|---|---|---|
| CUBIC | 丢包信号 | 遇到随机丢包时容易降速，吞吐波动更明显 |
| BBR | 瓶颈带宽与 RTT | 更重视链路真实容量，速度曲线通常更平稳 |
公网直连（CUBIC）：上升 -> 随机丢包 -> 快速降速 -> 缓慢恢复 优化链路（BBR）： 探测容量 -> 稳定发送 -> 动态调整 -> 持续利用带宽
自研协议栈和链路优化的意义
普通公共网络很难直接干预底层拥塞控制行为。对于跨境下载、远程开发、视频数据流等场景，优化链路需要同时关注节点位置、转发路径、协议策略和弱网下的恢复能力。
稳如狗加速在传输节点和客户端之间构建更稳定的探测与转发链路，目标是在高延迟、高抖动或轻微丢包环境中，让数据流保持更连续的吞吐表现，减少“明明有带宽却跑不起来”的体验。
对大文件下载、依赖拉取、高清视频和持续数据同步来说，稳定吞吐通常比瞬时峰值更能决定真实体验。