TCP 拥塞避免算法( 七 ) _算法

看到这里时候我开始一直有个疑问，在 42s 到 44s 期间，队列内一直有堆积，一个周期发送速度是 1.25 ，一个周期发送速度是 0.75 ，岂不是刚好把发多少数据消费掉，但队列内堆积的 inflights 不是依然保持没有被消费掉吗？不该是下降趋势。
后来知道， ProbeBW 期间一个周期大致上是一个 RTT 时间，但发送速度 1.25 的周期和发送速度 0.75 的周期并不是严格等长的。1.25 周期时长是 inflights 数量到达 1.25 倍估计的 BDP 或有数据丢包。0.75 周期长度是一个完整的估计的 RTprop ，或者 inflights 低于估计的 BDP 。发送者能感知到 inflights 低于 BDP 的时候实际 inflights 一定低很多了，所以 BBR 的 inflights 曲线都是像心跳一样，上面一个三角下面一个三角，而不是只有上面的三角。在 19 ~ 20s 的时候，上三角比下三角大。20 ~ 21s 因为带宽变大了，但发送带宽只是缓慢增加上去，所以下三角比上三角大很多，等到稳态以后又变成上三角大于下三角。42s 以后因为每个减周期都要等到 Inflights 低于估计的 BDP ，所以绿线一路向下。
对于蓝色的线我们知道链路上延迟是固有时间，所以它最低点是一条直线，增周期时延迟只会有上三角，没下三角。
注意下图没有 ProbeRTT 出现。我理解是因为 RTprop 还未超时就被更小的值更新了。

文章插图

来自[4]
BBR 的 startup链路上带宽跨度很大，从几个 bps 到上百 Gbps ，所以 BBR 一开始也会以指数形式增大 BtlBw ，每一个 RTT 下发送速度都增大 2/ln(2) 约 2.89 倍，从而在 O(log(BDP)) 个 RTT 内找到链路的 BtlBw ， log 的底是 2 。BBR 在发现提高发送速度但 deliveryRate 提高很小的时候标记 full_pipe ，开始进入 Drain 阶段，将排队的数据包都消费完。BBR 能保证排队的数据最多为实际 BDP 的 1.89 倍。BBR 下并没有 ssthresh ，即 CUBIC 那样增加到某个配置值后开始进入线性增加 CWND 阶段。
Drain 阶段就是把发送速率调整为 Startup 阶段的倒数。比如 Startup 阶段发送速度是 2.89 ，那 Drain 阶段发送速度是 1/2.89。BBR 会计算 inflights 数据包量，当与估计的 BDP 差不多的时候， BBR 进入 ProbeBW 状态，后续就在 ProbeBW 和 ProbeRTT 之间切换。
下图是在 10Mbps ， 40ms 延迟网络下的 Startup 阶段的图，绿色是发送方发送数据量，蓝色是接收方收到的数据量。红色是 CUBIC 在同样环境的发送数据量，作为对比。下图绿色线的斜率就是发送速度，同一时间点绿色线上的点和蓝色线上的点的差值就是那个时刻 inflights 数据量。
看到 BBR 在 0.25s 之前是曲线， 10Mbps 40ms 延迟的网络下 BBR 允许的 BDP 为 0.04Mb ， 0.25 时间点上绿色和蓝色线差值大约 0.1Mb ，大致是 0.04Mb 的 2.89 倍。即 BBR 在一开始指数的快速提升发送速度，但快到了 0.25s 的时候， RTT 开始升高， inflights 提高后 deliveryRate 并没有相应提高， BBR 开始维持在一个速度等待几个 RTT 周期以确认链路确实承载不了当前的发送速度，所以 0.25s ~ drain 之前绿线斜率不变。到 Drain 后 RTT 迅速下降， Acked 数据量图的斜率也降低很多。在找到 RTprop 之后进入 ProbeBW 状态。
红线的话就是看到 CUBIC 更早的切换到线性增长，但之后会逐步增加发送包数量直到丢包。但下图上半部分看红线看不太出来发送率在增加，只是能隐约的感觉到 0.25 时间点时红线和蓝线的间隔似乎小于 0.75 时间点时他俩的间隔。

文章插图

来自[4]
下面是 BBR 和 Cubic 在延迟时间上的对比。BBR 开始延迟大但随即恢复。CUBIC 一直增长下去直到丢包，再减小再增长。

文章插图

来自[4]
当多个 BBR 流在同一个链路时如下图。基本上就是靠 BtlBw max filter 内 BtlBw 超时过期以及 ProbeRTT 逐步让每个 BBR 流都找到自己合适的份额。在一开始只有红色的线，之后绿的来了，红色线继续按原来速度发数据链路一定会拥塞，并且因为有两个流了红线的 deliveryRate 一定会下降， BtlBw 超时后红线降低发送速率。大致上就是这么相互作用，每来一个流需要调整一下直到稳定。