cubic与bbr性能实测

自1988年第一代TCP算法Tahoe诞生依赖，相继出现了reno、new reno、sacks、cubic、bbr等多种拥塞控制算法，在较常见的有reno、cubic以及linux 4.9以上内核搭载的bbr算法，在ubuntu 16.04包括之前的系统版本之前，默认使用cubic算法，在19.04之后的版本已经切换为默认bbr算法了，以这两大经典算法为例，分析一下优劣。

1.cubic

      谈到cubic算法，就不得不谈谈它的前世：bic算法，bic算法是在ack的驱动下，对窗口的最大值进行二分查找，传输过程中首先会记录拥塞窗口的一个最大值点w1，那么理论上实际窗口最大值应该在w1以下，同时记录一个rtt周期内没有出现丢包时的最小窗口大小w2，将拥塞窗口设为二者中间值，如果没有出现丢包，说明窗口值还可以增加，将窗口值设为w2，持续用二分法寻找最佳窗口值，并在最佳窗口值之间不断震荡，除了这个基本机制之外，bic还包括最大值探索阶段以及丢包时乘性缩小因子和步长等等，这里就不一一展开了，bic窗口探测过程图如下所示。

      cubic是bic的下一版本，由于bic算法和rtt强相关，如果发生丢包等事件会严重影响探测过程，那么如何让二者解耦并且保持这样一个斜率成u型的趋势呢，就是让所有tcp连接的探测曲线的趋势都保持相同，利用一个固定的三次方程使得窗口增长速率保持与bic一致，带宽探测公式如下所示：

      其中，C是常数因子，β是乘性减小因子，Wmax是最近一次发生丢包时的窗口大小，可以看到窗口探测过程不再与rtt强相关，修正了丢包时探测异常的问题。

      cubic拥塞窗口增长曲线如上图所示：在初始阶段，斜率逐渐降低，逐步逼近最大带宽（不丢包时），中点Wmax附近开始缓慢的探测网络最大带宽（因为上一次拥塞发生点在Wmax），越过Wmax后进入最大带宽探测阶段（越过中线意味着网络最大带宽应当在Wmax之上），直到发生丢包后乘性减小，重新开始此过程。

2.bbr

      在bbr诞生以前，所有拥塞控制算法都是基于抢占带宽的耍流氓模式去探测最佳发送窗口，想要获取最大带宽就必须不断的增加发送窗口，使得信道及相关缓存区堆满发生丢包，再通过快速恢复与快速重传等极致弥补这个短板，后续的几类算法也都是希望基于一种温和的形式去获取最大窗口，并没有从根源上解决问题，直到googlez在16年底提出bbr算法，极大的提高了TCP吞吐量。
      BBR的核心思想就是在TCP整个连接过程中不断的探测网络的最大带宽和最小RTT来控制发送端的发包间隔和数据包个数，较传统传输控制算法不同的是，不再探测缓存溢出丢包时的节点，而是探测缓存开始堆积的节点。在数据传输过程中主要分为四个阶段。
      1.Startup阶段，类似Reno算法中的慢启动，此阶段中pacingrate和cwnd都是以2-3之间的增益进行增长，当连续三轮测得的有效带宽的增长不超过25%以上时，表明数据包开始占用缓存区，缓存区出现堆积，此时要退出startup阶段，进入drain阶段。
       2.Drain阶段主要是为了解决startup阶段堆积的数据包问题，startup阶段的退出条件具有一定程度的滞后性，导致缓存区数据包堆积，此阶段中pacing rate的增益系数为1000/2885，cwnd的增益系数为1000/2005+1,直到inflight(在途数据量)小于BDP（带宽时延乘积）时，认为此时数据链路中已经不再存在堆积问题，退出drain阶段，进入PROBE_BW阶段。
      3.PROBE_BW是整个bbr算法中持续时间最长的阶段，此阶段会以5/4,3/4,1,1,1,1,1,1的增益系数温和的探测最下rtt和最大带宽。
      4.上述三种状态就是bbr算法的主流程，除此之外还有一个异步的流程贯穿始终，这个阶段被称为PROBE_RTT。如果在10秒内没有采集到新的最小RTT，就会进入PROBE_RTT阶段，此阶段中cwnd会骤降为4个MSS，持续时间最少200ms，强行清空网络管道。

3.性能实测

                                                                                          图一

                                                                                                图二
      实验过程中，购买了芝加哥服务器进行远程测试，图一是ubuntu 16.04系统，cubic算法，图二是将ubuntu升级到19.04系统，linux内核升级至5.3，系统已经默认开启了bbr算法。通过speedtest-cli测速工具进行测试，可以明显看到bbr算法比cubic带来的增益高很多，bbr算法只对服务器方有效，所以上行速度的增益比下行速度要高很多。

4.综述

      虽然从结果上看，bbr传输速度较cubic有所提升，但是由于probe_rtt阶段cwnd强制降为4MSS，导致传输几乎陷入中断的情况，此阶段带宽利用率也会降低，收敛也慢。
      cubic不存在bbr的probe_rtt阶段，是以探寻缓存溢出导致丢包点为目标，所以带宽利用率整体上会优于bbr。
      bbr在处理丢包情况时较cubic更优，原因是cubic在丢包时会被tcp拥塞控制所接管，而bbr则会全权接管拥塞控制过程，快速重传丢失数据包并且cwnd不会骤降。