拥塞控制算法cubic 和bbr

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。

1. 查看本地拥塞控制算法：

cat /proc/sys/net/ipv4/tcp_congestion_control

2. 通过iperf3测试TCP网络的总体吞吐量以及带宽，用10个并发

iperf3 -c {ip地址} -P 10

3. 使用cubic

执行iper3测试发现，部分链接带宽差异很大（甚至10倍）, 且频繁发生重传

4. 使用bbr

sudo sysctl net.ipv4.tcp_congestion_control=bbr

执行iper3测试发现，显示所有链接都十分稳定

在异地网络不稳定场景下，使用BBR效果更好