浅谈TCP拥塞控制算法

 TCP经过维护一个拥塞窗口来进行拥塞控制，拥塞控制的原则是，只要网络中没有出现拥塞，拥塞窗口的值就能够再增大一些，以便把更多的数据包发送出去，但只要网络出现拥塞，拥塞窗口的值就应该减少一些，以减小注入到网络中的数据包数。

TCP拥塞控制算法发展的过程当中出现了以下几种不一样的思路：

• 基于丢包的拥塞控制：将丢包视为出现拥塞，采起缓慢探测的方式，逐渐增大拥塞窗口，当出现丢包时，将拥塞窗口减少，如Reno、Cubic等。
• 基于时延的拥塞控制：将时延增长视为出现拥塞，延时增长时增大拥塞窗口，延时减少时减少拥塞窗口，如Vegas、FastTCP等。
• 基于链路容量的拥塞控制：实时测量网络带宽和时延，认为网络上报文总量大于带宽时延乘积时出现了拥塞，如BBR。
• 基于学习的拥塞控制：没有特定的拥塞信号，而是借助评价函数，基于训练数据，使用机器学习的方法造成一个控制策略，如Remy。

拥塞控制算法的核心是选择一个有效的策略来控制拥塞窗口的变化，下面介绍几种经典的拥塞控制算法。

 

Vegas

Vegas^[1]将时延RTT的增长做为网络出现拥塞的信号，RTT增长，拥塞窗口减少，RTT减少，拥塞窗口增长。具体来讲，Vegas经过比较实际吞吐量和指望吞吐量来调节拥塞窗口的大小，指望吞吐量：Expected  = cwnd /  BaseRTT，实际吞吐量：Actual = cwnd / RTT，diff = (Expected-Actual) * BaseRTT，BaseRTT是全部观测来回响应时间的最小值，通常是创建链接后所发的第一个数据包的RTT，cwnd是目前的拥塞窗口的大小。Vegas定义了两个阈值a，b，当diff > b时，拥塞窗口减少，当a <= diff <=b时，拥塞窗口不变，当diff < a时，拥塞窗口增长。

Vegas算法采用RTT的改变来判断网络的可用带宽，能精确地测量网络的可用带宽，效率比较好。可是，网络中Vegas与其它算法共存的状况下，基于丢包的拥塞控制算法会尝试填满网络中的缓冲区，致使Vegas计算的RTT增大，进而下降拥塞窗口，使得传输速度愈来愈慢，所以Vegas未能在Internet上广泛采用。

适用场景：适用于网络中只存在Vegas一种拥塞控制算法，竞争公平的状况。

 

Reno

Reno^[2]将拥塞控制的过程分为四个阶段：慢启动、拥塞避免、快重传和快恢复，是现有的众多拥塞控制算法的基础，下面详细说明这几个阶段。

慢启动阶段，在没有出现丢包时每收到一个ACK就将拥塞窗口大小加一（单位是MSS，最大单个报文段长度），每轮次发送窗口增长一倍，呈指数增加，若出现丢包，则将拥塞窗口减半，进入拥塞避免阶段；当窗口达到慢启动阈值或出现丢包时，进入拥塞避免阶段，窗口每轮次加一，呈线性增加；当收到对一个报文的三个重复的ACK时，认为这个报文的下一个报文丢失了，进入快重传阶段，当即重传丢失的报文，而不是等待超时重传；快重传完成后进入快恢复阶段，将慢启动阈值修改成当前拥塞窗口值的一半，同时拥塞窗口值等于慢启动阈值，而后进入拥塞避免阶段，重复上诉过程。Reno拥塞控制过程如图1所示。

                           图一、TCP Reno 拥塞控制过程

Reno算法将收到ACK这一信号做为拥塞窗口增加的依据，在早期低带宽、低时延的网络中可以很好的发挥做用，可是随着网络带宽和延时的增长，Reno的缺点就渐渐体现出来了，发送端从发送报文到收到ACK经历一个RTT，在高带宽延时（High Bandwidth-Delay Product，BDP）网络中，RTT很大，致使拥塞窗口增加很慢，传输速度须要通过很长时间才能达到最大带宽，致使带宽利用率将低。

适用场景：适用于低延时、低带宽的网络。

 

Cubic

Cubic^[3]是Linux内核2.6以后的默认TCP拥塞控制算法，使用一个立方函数（cubic function）做为拥塞窗口的增加函数，其中，C是调节因子，t是从上一次缩小拥塞窗口通过的时间，W_max是上一次发生拥塞时的窗口大小，，β是乘法减少因子。从函数中能够看出拥塞窗口的增加再也不与RTT有关，而仅仅取决上次发生拥塞时的最大窗口和距离上次发生拥塞的时间间隔值。

Cubic拥塞窗口增加曲线以下，凸曲线部分为稳定增加阶段，凹曲线部分为最大带宽探测阶段。如图2所示，在刚开始时，拥塞窗口增加很快，在接近W_max口时，增加速度变的平缓，避免流量突增而致使丢包；在W_max附近，拥塞窗口再也不增长；以后开始缓慢地探测网络最大吞吐量，保证稳定性（在W_max附近容易出现拥塞），在远离W_max后，增大窗口增加的速度，保证了带宽的利用率。

                         图二、TCP Cubic 拥塞窗口增加函数

当出现丢包时，将拥塞窗口进行乘法减少，再继续开始上述增加过程。此方式可使得拥塞窗口一直维持在Wmax附近，从而保证了带宽的利用率。Cubic的拥塞控制过程如图3所示：

图三、TCP Cubic拥塞控制过程

Cubic算法的优势在于只要没有出现丢包，就不会主动下降本身的发送速度，能够最大程度的利用网络剩余带宽，提升吞吐量，在高带宽、低丢包率的网络中能够发挥较好的性能。

可是，Cubic同以前的拥塞控制算法同样，没法区分拥塞丢包和传输错误丢包，只要发现丢包，就会减少拥塞窗口，下降发送速率，而事实上传输错误丢包时网络不必定发生了拥塞，可是传输错误丢包的几率很低，因此对Cubic算法的性能影响不是很大。

Cubic算法的另外一个不足之处是过于激进，在没有出现丢包时会不停地增长拥塞窗口的大小，向网络注入流量，将网络设备的缓冲区填满，出现Bufferbloat（缓冲区膨胀）。因为缓冲区长期趋于饱和状态，新进入网络的的数据包会在缓冲区里排队，增长无谓的排队时延，缓冲区越大，时延就越高。另外Cubic算法在高带宽利用率的同时依然在增长拥塞窗口，间接增长了丢包率，形成网络抖动加重。

适用场景：适用于高带宽、低丢包率网络，可以有效利用带宽。

 

BBR

BBR^[4]是谷歌在2016年提出的一种新的拥塞控制算法，已经在Youtube服务器和谷歌跨数据中心广域网上部署，据Youtube官方数据称，部署BBR后，在全球范围内访问Youtube的延迟下降了53%，在时延较高的发展中国家，延迟下降了80%。目前BBR已经集成到Linux 4.9以上版本的内核中。

BBR算法不将出现丢包或时延增长做为拥塞的信号，而是认为当网络上的数据包总量大于瓶颈链路带宽和时延的乘积时才出现了拥塞，因此BBR也称为基于拥塞的拥塞控制算法（Congestion-Based Congestion Control）。BBR算法周期性地探测网络的容量，交替测量一段时间内的带宽极大值和时延极小值，将其乘积做为做为拥塞窗口大小（交替测量的缘由是极大带宽和极小时延不可能同时获得，带宽极大时网络被填满形成排队，时延必然极大，时延极小时须要数据包不被排队直接转发，带宽必然极小），使得拥塞窗口始的值始终与网络的容量保持一致。

因为BBR的拥塞窗口是精确测量出来的，不会无限的增长拥塞窗口，也就不会将网络设备的缓冲区填满，避免了出现Bufferbloat问题，使得时延大大下降。如图4所示，网络缓冲区被填满时时延为250ms，Cubic算法会继续增长拥塞窗口，使得时延持续增长到500ms并出现丢包，整个过程Cubic一直处于高时延状态，而BBR因为不会填满网络缓冲区，时延一直处于较低状态。

图四、Cubic和BBR RTT对比

因为BBR算法不将丢包做为拥塞信号，因此在丢包率较高的网络中，BBR依然有极高的吞吐量，如图5所示，在1%丢包率的网络环境下，Cubic的吞吐量已经下降90%以上，而BBR的吞吐量几乎没有受到影响，当丢包率大于15%时，BBR的吞吐量才大幅降低。

图五、Cubic和BBR传输速率与丢包率关系对比

BBR算法是反馈驱动的，有自主调节机制，不受TCP拥塞控制状态机的控制，经过测量网络容量来调整拥塞窗口，发送速率由本身掌控，而传统的拥塞控制算法只负责计算拥塞窗口，而无论发送速率（pacing rate），怎么发由TCP本身决定，这样会在瓶颈带宽附近因发送速率的激增致使数据包排队或出现丢包。

通过测试，在高延时、高丢包率的环境下，BBR相对于Cubic算法在传输速度上有较大的提高，具体的测试结果表1所示：

表1 200ms延时下Cubic与BBR传输速度对比

BBR算法的不足之处在于设备队列缓存较大时，BBR可能会竞争不过Cubic等比较激进算法，缘由是BBR不主动去占据队列缓存，若是Cubic的流量长期占据队列缓存，会使得BBR在多个周期内测量的极小RTT增大，进而使BBR的带宽减少。

适用场景：适用于高带宽、高时延、有必定丢包率的长肥网络，能够有效下降传输时延，并保证较高的吞吐量。

 

Remy

Remy^[5]也称为计算机生成的拥塞控制算法（computer-generated congestion-control algorithm），采用机器学习的方式生成拥塞控制算法模型。经过输入各类参数模型（如瓶颈链路速率、时延、瓶颈链路上的发送者数量等），使用一个目标函数定量判断算法的优劣程度，在生成算法的过程当中，针对不一样的网络状态采用不一样的方式调整拥塞窗口，反复修改调节方式，直到目标函数最优，最终会生成一个网络状态到调节方式的映射表，在真实的网络中，根据特定的网络环境从映射表直接选取拥塞窗口的调节方式。

Remy试图屏蔽底层网络环境的差别，采用一个通用的拥塞控制算法模型来处理不一样的网络环境。这种方式比较依赖输入的训练集（历史网络模型），若是训练集可以全面覆盖全部可能出现的网络环境及拥塞调节算法，Remy算法在应用到真实的网络环境中时可以表现的很好，可是若是真实网络与训练网络差别较大，Remy算法的性能会比较差。

适用场景：网络环境为复杂的异构网络，但愿计算机可以针对不一样网络场景自动选择合适的拥塞控制方式，要求现有的网络模型可以覆盖全部可能出现状况。

 

总结

每一种拥塞控制算法都是在必定的网络环境下诞生的，适合特定的场景，没有一种一劳永逸的算法。网络环境愈来愈复杂，拥塞控制算法也在不断地演进。本文不是要去选择一个最好的算法，只是简单介绍了几种典型算法的设计思路、优缺点以及适用场景，但愿能给你们带来一些启发。

 

参考论文

[1] S.O. L. Brakmo and L. Peterson. TCP Vegas: New techniques for congestiondetection and avoidance. In SIGCOMM, 1994. Proceedings. 1994 InternationalConference on. ACM, 1994.

[2] V.Jacobson, “Congestion avoidance and control,” in ACM SIGCOMM ComputerCommunication Review, vol. 18. ACM, 1988, pp. 314–329.

[3] L. X. I. R. Sangtae Ha. Cubic: A new TCP -friendlyhigh-speed TCP variant. In SIGOPS-OSR, July 2008. ACM, 2008.

[4] C.S. G. S. H. Y. Neal Cardwell, Yuchung Cheng and V. Jacobson. BBR:congestion-based congestion control. ACM Queue, 14(5):20{53, 2016.

[5] K.Winstein and H. Balakrishnan. TCP Ex Machina: Computer-generated Congestion Control.In Proceedings of the ACM SIGCOMM 2013 Conference, 2013.