Google's BBR拥塞控制算法模型解析_Netfilter,iptables/OpenVPN/TCP guard:-(-CSDN博客_bbr拥塞控制算法； 笔记：

全文的大意： BBR的模型设计是基于延时策略的，完全不同于之前一直基于丢包策略判断网络的，比如cubic.基于延时发现带宽上限更早一点.
BBR原理是发现了，RTT最小，则BDP最大。
BBR的BDP不算路由器缓存。cubic则算.两者定义BDP意义不同。
BBR与vega的区别：vega也是基于延时的算法，但是其依赖于单一rtt测量。只要有一个假拥塞的rtt,就会造成vega调整带宽。所以和reno的算法比，会占用太少的带宽，即“饿死”
而bbr基于10s内的最小rtt,所以假拥塞会被排除掉，所以稳定。 冒泡排序计算最小rtt.
BBR: startup, drain,probe 3部分steps组成. 一个序列 1.25,0.75,1,1,1,1.25,0.75...主要在drain,probe之间切换。
BBR发送还增加了Pacing

这张图就是BBR网络传输的本质模型！
说明：RTT增加，flight 没有变化，只是路由器buffer数据增加，buffer满之后最终丢包
BBR对最大带宽和最小RTT的探测
从模型图上可以清楚的看出如何探测最大带宽：

        BBR在一个不随时间滑动的大概10秒的时间窗口中采集最小RTT，BBR只使用这个最小RTT计算Pacing Rate和拥塞窗口。使用10s内的最小RTT，可以防止假阻塞

,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,

BBR 拥塞控制算法解析（来自 Google 的 TCP 拥塞控制算法） | CCIE 工程师社区   笔记

摘要：

1) 基于延时比基于丢包码率评估的好处
2) BBR 的四个状态（启动、排空、带宽探测、时延探测）
10s没有测试出最小rtt，将进入probe探测即不发数据包，仅仅发送少量探测包，排空buffer,获取最小rtt.
3) 带宽的动态更新（带宽探测）cycle gain 的数组控制发送速率 (1.25,0.75,1,1,1,1,1,1)共8个rtt  
4) 多条 BBR 数据流分享瓶颈链路带宽
5) cubic 和bbr比较

基于延时比基于丢包码率评估的好处:

2.1 基于丢包的拥塞控制算法的两大缺陷

（ 1 ）不能区分是拥塞导致的丢包还是错误丢包

基于丢包的拥塞控制方法把数据包的丢失解释为网络发生了拥塞，而假定链路错误造成的分组丢失是忽略不计的,这种情况是基于当时 V. Jacobson 的观察，认为链路错误的几率太低从而可以忽略.然而在高速网络中，这种假设是不成立的，当数据传输速率比较高时，链路错误是不能忽略的。
在无线网络中，链路的误码率更高。因此，如果笼统地认为分组丢失就是拥塞所引起的，从而降低一半的速率，是对网络资源的极大浪费。

（ 2 ）引起缓冲区膨胀

我们会在网络中设置一些缓冲区，用于吸收网络中的流量波动，在连接的开始阶段，基于丢包的拥塞控制方法倾向于填满缓冲区。当瓶颈链路的缓冲区很大时，需要很长时间才能将缓冲区中的数据包排空，造成很大的网络延时，这种情况称之为缓冲区膨胀。在一个先进先出队列管理方式的网络中，过大的 buffer 以及过长的等待队列，在某些情况下不仅不能提高系统的吞吐量甚至可能导致系统的吞吐量近乎于零。并且当所有缓冲区都被填满时，会出现丢包。

4 设计细节

4.1 BBR 的四个状态（启动、排空、带宽探测、时延探测）

( 1 ）当连接建立时，BBR 采用类似标准 TCP 的 slow start ，指数增加发送速率，目的也是尽可能快的占满管道，经过三次发现投递率不再增长(rtt开始增加)，说明管道被填满，开始占用 buffer ，接下来进入排空阶段（事实上此时占的是三倍带宽 * 延迟）。
（ 2 ）在排空阶段,指数降低发送速率,(相当于是 startup 的逆过程)将多占的 2 倍 buffer 慢慢排空
notes:上面两步init工作，填满buffer然后又排空，这是何必呢？发现占用buffer就降低发送码率就行了哈。此处理解为，第一次测量整个infight+buffer的总量。后面采用了发现填buffer就减速.
buffer对于bbr仅仅是一个rtt增加，即延时增加的信号。bbr不需要buffer 缓存数据，这点不同于基于丢包的tcp协议。
（ 3 ）完成上面两步，进入稳定状态后，BBR 改变发送速率进行带宽探测：先在一个 RTT 时间内增加发送速率探测最大带宽，如果 RTT 没有变化，后减小发送速率排空前一个 RTT 多发出来地包，后面 6 个周期使用更新后的估计带宽发包。
notes:此处说明有个错误”如果 RTT 没有变化“应该是RTT增大，然后减小发送一个后减小发送速率排空前一个 RTT 多发出来地包.因为只是最近的RTT的1.25是过量的,所以后面一个0.75做排空
（ 4 ）还有一个阶段是延迟探测阶段：BBR 每过 10 秒，如果估计延迟不变，就进入延迟探测阶段，为了探测最小延迟，BBR 在这段时间内发送窗口固定为 4 个包，即几乎不发包，占整个过程 2 % 的时间。
notes:只发很少的探测包，这个阶段用于排空buffer，获取最小的RTT。

4.2 带宽的动态更新（带宽探测）

带宽探测占据 BBR 绝大部分时间。在 startup 阶段，BBR 已经得到网络带宽的估计值。在带宽探测阶段，BBR 利用一个叫做 cycle gain 的数组控制发送速率，进行带宽的更新。cycle gain 数组的值为 5 / 4 （1.25）, 3 / 4（0.75） , 1 , 1 , 1 , 1 , 1 , 1 ，BBR 将 max BtlBW * cycle gain 的值作为发送速率。一个完整的 cycle 包含 8 个阶段， 每个阶段持续时间为一个 RTprop 。
故如果数组的值是 1 ，就保持当前的发送速率，如果是 1.25 ，就增加发送速率至 1.25 倍 BW ，如果是 0.75 ，BBR 减小发送速率至 0.75 倍 BW 。
notes:上图中灰色是cycle gain

带宽的动态更新（带宽探测）

上图显示的是一个 10-Mbps , 40-ms 的数据流在第 20 s 时网络带宽增加一倍至 20 Mbp 时，BBR 是如何更新的。
向上的尖峰表明它增加发送速率，向下的尖峰表明它降低发送速率。
如果带宽不变,增加发送速率肯定使RTT增加,降低发送速率是为了让他要把上一周期多发的包排空.
如果带宽增加,则增加发包速率时 RTT 不变。
这样经过三个周期之后，估计的带宽也增加了一倍。
notes：RTT不变，说明有上升可以加大发送码率。RTT增加说明有buffer,因为其只增加了一个周期1.25,所以用一个周期0.75排空。然后恢复到rtt增大之前的情况，发送1.如果稳定6个周期，继续上探（说明抢占了其他的带宽，有的带宽在快速重传）。
如果rtt在0.75排空之后，恢复到1，rtt还是增加，则继续排空（带宽被其他人的抢占了）

带宽的动态更新（带宽探测）

上图所示为在第 40s,是当网络带宽由 20 Mbps 减半至 10 Mbps 时,BBR 的带宽探测如何发挥作用?因为发送速率不变，inflight（飞行中进行的）增加，多出来的数据包占用了 buffer ，RTT 增加，BBR 从而减小发送速率，经过 4 秒后，有效带宽也降低为一半。

4.3 多条 BBR 数据流分享瓶颈链路带宽

上图所示为多条独立的 BBR 数据流分享 100-Mbps / 10-ms 瓶颈链路的情况:一条连接独占整个链路时,它的可用带宽近似为链路的物理带宽,n 条连接共享链路时,最理想最公平的情况就是 BW / n .
每条连接的 startup 阶段都会尝试增加带宽，所以吞吐量会有一个向上的尖峰，已经在链路中的连接会检测到拥塞而减小自己的发送速率，吞吐量会下降。
最后通过反复的带宽探测，他们都会趋于收敛，带宽得到均分。

5 实验结果(cubic 和bbr抢占)

上图所示为 CUBIC（红线）和 BBR（绿线）的 RTT 随时间的变化：

• CUBIC（红线）：可见周期性地延迟变化，缓存几乎总是被填满。
• BBR（绿线）：除了在 statup 和 drain 阶段，RTT 会发生较大的变化，在网络带宽保持不变时，RTT 只有细微的变化，这些小尖峰是 BBR 尝试增加发包速率产生的，每 8 个往返延迟为周期的延迟细微变化。

在有随机丢包情况下BBR（绿线）和CUBIC（红线）吞吐量的比较

上图所示为在有随机丢包情况下 BBR（绿线）和 CUBIC（红线）吞吐量的比较。

如图所示，CUBIC（红线）在万分之一丢包率的情况下，CUBIC 带宽只剩 30 % ；千分之一丢包率时只剩 10 % ；在百分之一丢包率时就几乎没有吞吐量 。
而 BBR 在丢包率 5 % 以下几乎没有带宽损失。

横轴是 CUBIC 的吞吐量，纵轴是 BBR 的吞吐量与 CUBIC
吞吐量之比

上图中，横轴是 CUBIC 的吞吐量，纵轴是 BBR 的吞吐量与 CUBIC 吞吐量之比，可见在吞吐量情况低的情况下，BBR 与 CUBIC 吞吐量之比很大 ，说明吞吐量越低的网络，BBR 性能越卓越。

6 总结

（ 1 ）吞吐量的显著提高

BBR已经在 Google跨数据中心的内部广域网(B4)上部署,相对于 CUBIC,BBR 的吞吐量提高了133 .

（ 2 ）易于集成

能够在开源的 Linux kernel 中应用且只需要改变数据发送端。