拥控算法BBR入门1

拥塞控制算法只与本地有关

一个TCP会话使用的拥塞控制算法只与本地有关。
两个TCP系统可以在TCP会话的两端使用不同的拥塞控制算法

Bottleneck Bandwidth and Round-trip time

Bottleneck 瓶颈
BBR models the network to send as fast as the available bandwidth and is 2700x faster than previous TCPs on a 10Gb,
100ms link with 1% loss.
BBR powers google.com, youtube.com and apps using Google Cloud Platform services.

旧网络拥塞：只要丢包就代表网络环境不好

tcp默认的cubic拥塞控制算法频繁上下调整滑动窗口大小，锯齿状
bbr倾向于平稳发送，在实际带宽比较平稳的场景下，吞吐量更大

tcp为什么没有解决这个问题：
tcp在linux内核里，升级太困难。
tcp的一些约束导致rtt算不准，比如ack delay、重传包的seq number不变

cubic: 基于丢包；锯齿形吞吐；事件驱动； tcp的重传包seqId不变，rtt算不准（tcp的ack delay时间影响rtt计算，默认40ms）
bbr: 基于延迟； 有平滑区间；根据rtt建立对带宽（窗口大小）的模型，再加上定时器；quic的重传包，seqId增加（编号id），rtt算得准。区分了具体的重传类型。

bbr：当rtt开始增长时，就达到了最大带宽
cubic：把缓存塞满一直到丢包；对丢包率的容忍非常低，即使只有极少的丢包，吞吐量也会急剧下降

相关命令

在Linux 下检查当前可用的拥塞算法：
sysctl net.ipv4.tcp_available_congestion_control
比如：reno cubic bbr bbr2 hybla highspeed htcp veno westwood vegas

当前使用了哪一种拥塞算法：
sysctl net.ipv4.tcp_congestion_control

sudo tc qdisc replace dev eth0 root netem latency 50ms
在两台服务器的收发每个方向增加50ms的延迟。

sudo tc qdisc del dev eth0 root
取消上述的设置

sudo sysctl -w net.ipv4.tcp_congestion_control=cubic
sudo sysctl -w net.ipv4.tcp_congestion_control=bbr
sudo sysctl -w net.ipv4.tcp_congestion_control=bbr2
修改本机的拥控算法

sudo tc qdisc replace dev eth0 root netem loss 1.5% latency 50ms
在两台服务器的收发每个方向增加50ms的延迟 + 1.%的丢包

实验

作者在TCP上实验
作者这个图画的有点问题，应该是先确定loss，再传输特定数量包，统计不同拥塞控制算法的吞吐量和时延
Andree Toonk 在他的博客中验证了了使用不同拥塞控制算法、延迟和丢包参数所做的各种TCP吞吐量测试的全套测试，证明了在一定的丢包率（1.5%、3%）的情况下BBR的出色表现：

测试显示了丢包和延迟对TCP吞吐量的巨大影响。在一个高延迟的路径上，仅仅是少量的数据包丢失（1.5%）就会产生了巨大的影响。在这些较长的路径上使用除BBR以外的任何其他技术，当出现哪怕是少量的丢包时，都会造成很大的问题。也只有BBR在任何超过1.5%的丢包损失时都能保持一个不错的吞吐量数字。

BBR使用场景

网络在没有丢包的情况下，Cubic和BBR对于这些较长时延的链路都有很好的表现。而在中度丢包的情况下，BBR的表现就非常突出。

为什么要针对丢包情况而进行优化？
场景：在不同的地方放置有服务器，需要在系统或者服务器之间有源源不断的数据传输。例如日志文件、数据库同步、业务数据的异地备份等等。在复杂的网络环境下，会因为各种原因而出现丢包的情况。在这种场景下，BBR将会大放异彩，帮助维护更好的网络数据传输。

BBR对所谓的“长肥网络”（带宽延迟积大、丢包率高的网络）非常有效，在CDN和视频应用等场景下也被证明有很好的表现。
事实上，Youtube、Spotify和Dropbox大规模应用BBR已经有了很多的积累。这主要是因为BBR会积极地提升到最佳发送速率。

BBR缺点

wifi环境高抖动和波动导致网速变慢

（算不准实时可用带宽/RTT，就会导致流量偏大/偏小，说白了就是计划赶不上变化）

BBR算法以估测瓶颈带宽和RTT来调整发送速率，这种机制在高波动和不稳定的无线环境中可能表现不佳。
带宽估测误差：在WiFi环境中，实际的瓶颈带宽可能变化频繁，BBR的带宽估测如若不准确，会导致发送速率偏高或偏低。
RTT测量波动：高抖动和噪声引入的RTT测量误差，容易导致BBR无法准确捕捉真实网络状况，丢包和重传情况增加。

BBR依赖于精确的带宽估测和RTT测量来调整发送速率，但WiFi网络中的抖动（Jitter）和信号波动会对这些测量造成干扰
高实时抖动：WiFi信号质量因周围环境（如物理障碍、干扰设备、用户密度等）波动较大，导致RTT和带宽测量的不稳定
不可预测的丢包：WiFi网络中的随机丢包（而非拥塞引起的丢包）会导致BBR误判网络状况，影响其测量和调整

拥塞和无线信道竞争

（使用相同无线信道下的争抢，导致更糟）

WiFi网络中用户与用户之间使用相同无线信道，会出现频繁的竞争和碰撞，带来额外的传输延迟和带宽波动
共享信道：在高密度用户环境中，多用户竞争同一个无线信道资源，相互干扰，导致实际可用带宽降低。
复用性差：WiFi采用CSMA/CA（Carrier Sense Multiple Access with Collision Avoidance），高负载下其复用性差，增加拥塞和排队时延

拥塞控制与公平性

（高效利用带宽，但挤占cubic算法带宽）

BBR设计目标：高效利用带宽
在WiFi环境中未必能与其它传统拥塞控制算法（如Cubic）的流量公平发挥作用

Aggressive的探测行为：BBR在初期阶段会探测更高的发送速率，可能导致瞬时拥塞，丢包率增加，反而影响到实际传输性能
对竞争流的不友好：BBR可能在多用户共享信道条件下显得不够温和，导致竞争流公平性问题，影响整体网络性能。

BBR会导致高重传率

拥塞窗口计算方式

BBR的拥塞控制逻辑基于其对网络带宽和RTT的估计，这与传统TCP拥塞控制算法如Cubic或Reno不同
发送速率高：BBR本质上是激进的，它尝试利用尽可能多的带宽。当BBR认为有较高带宽时，它会快速增加发送速率。如果网络没有足够的带宽来支持这个速率，就会导致队列溢出和丢包。
突发流量：由于BBR在探测瓶颈带宽的过程中可能会发送短时高峰流量，容易在网络中产生突发拥塞，导致包丢失和重传。

RTT估算的敏感性

BBR依赖于RTT的精确测量来调整发送速率，但在高抖动网络中，RTT的波动性会影响BBR的准确判断。
RTT波动：在高抖动的网络中，RTT测量的不稳定性会导致BBR频繁调整发送速率。如果RTT波动大，BBR可能会误判当前网络状况，导致不适当的发送速率调整，增加了丢包和重传的概率

带宽探测机制

BBR通过探测高带宽以尽可能利用网络链路，但是这种探测策略在某些情况下会增加丢包率和重传次数。
主动探测：BBR会定期发送探测包来评估网络带宽，这种主动探测行为在网络容量不足时会导致丢包。
过度带宽利用：BBR的设计目标之一是高效利用可用带宽，但在一些环境中（如共享宽带或限带宽环境），这个行为可能会引发频繁的拥塞和重传。

适应性反馈机制

传统TCP拥塞控制算法如Reno和Cubic基于丢包或延时来调整拥塞窗口，而BBR依赖于带宽和RTT估计，这使得它在某些情况下面对高丢包率时的反应可能不够迅速和适应。
过度探测：BBR的拥塞控制主要依据带宽估测，一旦带宽估测过高而实际网络容量不足，容易持续导致大量丢包。
反馈滞后：网络负荷变化频繁时，BBR的调整可能存在滞后。然而主流TCP算法在这种情况下可能会更快地收敛到较为稳定的状态。

优化建议

在WiFi环境中优化BBR算法

调整BBR参数
优化探测和测量周期，适应更高抖动的网络环境。

使用混合控制机制
在WiFi环境中，结合BBR和其他较为保守的拥塞控制算法（如Cubic或Reno），通过混合控制策略提高网络适应性

BBRv2

BBRv2的目标就是解决第一版中存在的一些主要缺点，其改进包括了还使用聚合/运行中的参数增强了网络建模，并增加了对ECN(显式拥塞通知)的支持等

ECN(显式拥塞通知)

附录

缓冲膨胀

网络设备/系统不必要地设计了过大缓冲区
当网络链路拥塞时，就会发生缓冲膨胀，从而导致数据包在这些超大缓冲区中排队很长时间
在先进先出队列系统中，过大的缓冲区会导致更长的队列和更高的延迟，并且不会提高网络吞吐量
bbr并不会试图填满缓冲区，所以在避免缓冲区膨胀方面有更好表现

弱网环境,引入1.5%的丢包：
cubic：吞吐量下降99.7%
bbr: 吞吐量下降45%

Cubic

一种较为温和的拥塞算法，它使用三次函数作为其拥塞窗口的算法，并且使用函数拐点作为拥塞窗口的设置值。
Linux内核在2.6.19后使用该算法作为默认TCP拥塞算法。
今天所使用的绝大多数Linux 分发版本，例如Ubuntu、Amazon Linux 等均将Cubic作为缺省的 TCP拥塞算法

iperf3

iperf3 是一个用于测量网路吞吐量的工具，可以在网络性能测试中生成 TCP 和 UDP 流量负载。它被广泛用于测试网络的带宽和性能。

iperf3 -c 10.0.1.196 -p 8080

iperf3
用于启动 iperf3 客户端或服务器

-c
表示客户端模式。iperf3 可以运行在客户端模式和服务器模式中。这里的客户端模式用于发送流量到指定的服务器。

10.0.1.196
服务器的 IP 地址。在客户端模式下，这个地址指定了要连接的 iperf3 服务器的 IP 地址

-p 8080
这个选项指定要连接的服务器的端口号

使用 iperf3 工具来启动一个客户端，并连接到 IP 地址为 10.0.1.196，端口为 8080 的 iperf3 服务器。
客户端会生成流量并发送到服务器，从而对网络带宽和其他性能指标进行测试。

以下是一些常用的 iperf3 选项，可以根据具体需求和测试目标来进行配置：
-t：指定测试的持续时间（例如 -t 10 表示进行10秒的测试）
-u：使用UDP而不是默认的TCP协议进行测试
-b：指定带宽，比如UDP模式下可以使用-b 10M限制带宽为10Mbps
-R：反向测试，在客户端接收流量，而不是发送流量
-f：指定输出格式（例如 -f m 表示输出以兆比特为单位的结果）