1. 背景
CUBIC 和 BBR 是两种用于网络流量控制的拥塞控制算法，广泛应用于传输中，本质上是用于提升网络速度、稳定性和效率的方案。CUBIC 和 BBR 在本质思想、设计目标和工作方式上存在很大的差异，以下是两者的详细对比。
1.1 CUBIC
提出者: CUBIC 是 TCP 拥塞控制的算法之一，于 2008 年提出，是 TCP Reno 和 TCP Vegas 的后继者。
默认算法:
- Linux 内核中的默认 TCP 拥塞控制算法。
- 特点为简单易实现，与传统 TCP 的兼容性良好。
核心特点:
- 基于增量式带宽探测，以时间和 RTT（Round Trip Time, 往返时间）为核心参数计算网络的可用带宽。
拥塞窗口（拥塞控制的核心变量）的增长由一个三次方函数（cubic 函数）描述。 - 更适合高带宽、高延迟的网络环境。
1.2 BBR (Bottleneck Bandwidth and RTT)
提出者: 谷歌（Google），首次发布于 2016 年。
默认算法:
- 正在逐步应用于一些服务（例如 Google 和 YouTube），作为替代传统 TCP 拥塞控制算法的优化方案。
核心特点:
- 基于可用带宽和往返时间的主动估算。
- 思路与传统 TCP 比较激进，倾向于紧贴「瓶颈带宽」传输，精准预测网络容量，最大化利用。
- 擅长处理高带宽、动态相变的网络（例如慢速 5G 信道）。
1.3 核心机制对比
| 特性 | CUBIC | BBR |
|---|---|---|
| 设计模型 | 以复合函数（时间和 RTT 结合）逐步增加窗口大小 | 主动探索网络「瓶颈带宽」和「最低 RTT」 |
| 拥塞处理 | 遵循「丢包信号」来判断拥塞，减少窗口大小 | 仅通过带宽测量和 RTT 来判断拥塞，无需依赖丢包信号 |
| 拥塞窗口增长 | 基于三次方函数，适合高延迟带宽产品（增长速度更快），尤其对长距离链路传输友好 | 无拥塞窗口概念，更专注于估计「实际带宽」而非增加传输速率 |
| RTT 对吞吐量的影响 | RTT 较长时增长更慢，表现会衰减（如 CUBIC 更适合 LAN 等网络）。 | RTT 对吞吐量几乎无影响（只需精准捕获最低 RTT，不依赖 RTT 测量传输性能）。 |
| 带宽使用优化 | 并未真实估算网络的瓶颈带宽。 | 测量网络瓶颈带宽，确保流量紧贴带宽上限，避免过多流量对网络导致拥塞。 |
| 恢复速度 | 默认使用丢包后退避方式逐步恢复流量速率，增长较慢 | 快速恢复网络速率，带宽调整较为灵活。 |
| 适应多样链路 | 对高带宽高延迟链路（如光纤线路）更优化 | 对不稳定网络（如卫星通信、无线网络）及非均匀链路自适应能力更好。 |
2. 实验
在异地场景下，ping大概39ms。
- 查看本地拥塞控制算法：
cat /proc/sys/net/ipv4/tcp_congestion_control
- 通过iperf3测试TCP网络的总体吞吐量以及带宽，用10个并发
iperf3 -c {ip地址} -P 10
- 使用cubic
执行iper3测试发现，部分链接带宽差异很大（甚至10倍）, 且频繁发生重传
- 使用bbr
sudo sysctl net.ipv4.tcp_congestion_control=bbr
执行iper3测试发现，显示所有链接都十分稳定
在异地网络不稳定场景下，使用BBR效果更好
