通过 TCP BBR 优化TCP连接的性能，提高数据传输的效率和稳定

1. BBR 算法解决了什么问题？

旨在解决传统拥塞控制算法（如 TCP Reno、CUBIC 等）把丢包就当成链路拥塞考虑，拥塞控制会导致发送端发包速度波动很频繁，导致整体网络利用率不高（即 BBR 视角丢包 ≠ 链路拥塞）

1. 传统拥塞控制算法问题：

   1. 丢包 = 链路拥塞：传统的 CUBIC 拥塞控制算法以来丢包来决策链路是否拥塞了，在丢包高延迟场景下，发送端对链路感知太滞后了；
   2. 大缓冲区问题：许多网络设备（如路由器、交换机）为了应对突发流量，会配置较大的缓冲区很大的网络设备，传统拥塞控制算法持续填充这些缓冲区时，会导致数据包在缓冲区中排队时间过长，从而显著增加延迟

2. BBR 目标

   1. 让发送速率达到瓶颈带宽，同时保持在最小 RTT 附近，从而避免队列膨胀，实现高吞吐量和低延迟

3. BBR 算法如何解决的？: 不断探测瓶颈带宽（Bottleneck Bandwidth）和往返时间（Round-Trip Time, RTT） 决策是否要控速

   • 瓶颈带宽探测：发送数据并观察数据包的传输速率来估算网络的最大传输能力
   • 最小 RTT：BBR 通过发送探测包并记录最短的往返时间来估算网络路径的传播延迟。

2. 在 Linux 服务器开启 BBR 算法

• TCP 连接是双向的： TCP 连接的数据传输是双向的，每个方向都有自己的拥塞控制。
• 发送方决定拥塞控制算法： TCP 拥塞控制算法是在发送方生效的。当你的客户端向服务器发送数据时，客户端的拥塞控制算法决定了发送速率；当服务器向你的客户端发送数据时，服务器的拥塞控制算法决定了发送速率。
• BBR 的优势在于发送方： BBR 算法通过测量瓶颈带宽和 RTT 来调整发送速率，这些测量和调整都是在发送方进行的。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

vim /etc/sysctl.conf
# bbr
net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr

# 加载conf生效
sysctl -p

# check
$ sysctl net.ipv4.tcp_congestion_control
net.ipv4.tcp_congestion_control = bbr

$ lsmod | grep bbr
tcp_bbr                20480  7

建议在所有你拥有控制权的 Linux 服务器（特别是提供服务的服务器）和你的 Linux 客户端（如果你经常进行大文件传输或对网络延迟敏感）上都开启 BBR。

3. BBR 动态生效（应用程序无需重启）

执行  sysctl -p  命令，BBR 就会立即生效，无需重启任何应用程序

• BBR 是内核级别的TCP拥塞控制算法，相关的应用程序（如 Web 服务器、数据库、SSH 会话、VPN 客户端/服务端等） 不需要重启
• 应用程序使用系统 TCP 栈****：  应用程序在进行网络通信时，它们并不直接实现 TCP 协议，而是调用操作系统提供的TCP/IP协议栈接口（系统调用）。当内核的 TCP 拥塞控制算法被更改时，所有新的TCP连接以及现有的TCP连接（在某些情况下，取决于内核实现和连接状态）都会自动使用新的算法。
• 动态生效： sysctl -p  命令会立即将  /etc/sysctl.conf  中的配置应用到当前运行的内核中。这意味着从那一刻起，所有新的 TCP 连接都会使用 BBR 算法。对于已经建立的 TCP 连接，它们的拥塞控制算法可能会在连接的生命周期内动态切换到新的算法，或者在下一次数据传输时开始使用新的算法，这取决于具体的内核实现和连接状态。但即使不立即切换，新的连接也肯定会使用 BBR。

3.1. 建议在客户端和服务端都配置 BBR

原因解释

• TCP 连接是双向的： TCP 连接的数据传输是双向的，每个方向都有自己的拥塞控制。
• 发送方决定拥塞控制算法： TCP 拥塞控制算法是在发送方生效的。当你的客户端向服务器发送数据时，客户端的拥塞控制算法决定了发送速率（反之亦然）
• BBR 的优势在于发送方： BBR 算法通过测量瓶颈带宽和 RTT 来调整发送速率，这些测量和调整都是在发送方进行的。

以在客户端下载文件或观看视频分析

这种场景下，数据流主要从服务器流向客户端，服务器配置 BBR 也是至关重要：  因为此时服务器也会作为发送方，其拥塞控制算法（BBR）将决定数据传输的效率。

如果服务器没有开启 BBR，即使客户端开启了 BBR，服务器仍然可能使用传统的拥塞控制算法（如 CUBIC），导致下载速度无法达到 BBR 的最佳效果。

4. BBR 算法这么好，为什么默认 linux 还是使用的 CUBIC 算法？

出于稳定性、兼容性、风险规避以及对普适性考虑

1. 兼容性和稳定性：CUBIC 经过了时间验证，另外，混合网络中，如果 BBR 流与 CUBIC 流竞争有限的带宽，BBR 可能会“饿死”CUBIC 流（导致 CUBIC 算法丢包更严重），导致 CUBIC 流的性能下降
2. OS 稳定考虑：OS 的默认设置通常倾向于保守和通用性
3. BBR 的适用场景****：在高带宽、高延迟（如跨国链路）、高丢包率（如无线、卫星）以及存在大缓冲区（Bufferbloat）的网络环境中表现尤为出色

5. 小结

BBR 和传统的 CUBIC 算法相比更加的主动，而不是以被动网络丢包信号来认为网络已经拥塞了。

即 BBR 会主动发送探测包，检测真实的 RTT 以及网络带宽来发现网络是否真的“拥塞”，所以 BBR 在高丢包率、高延迟、高带宽的场景非常出色～