开启掘金成长之旅！这是我参与「掘金日新计划 · 2 月更文挑战」的第 8 天，点击查看活动详情
上一篇文章讲述了拥塞算法在实际的运用中可能会出现的问题，那么针对这些问题，业界也有一些主流的解决方法，这篇文章我们就一起探讨一下。
Vegas
TCP Vegas算法[Brakmo1995; Ahn1995]试图在维持较好的吞吐量的同时避免拥塞,Vegas的基本思想是:1. 在分组丢失发生之前，在源与目的地之间检测路由器中的拥塞; 2. 当检测出快要发生的分组丢失时，线性地降低发送速率。快要发生的分组丢失是通过观察RTT来预测的，分组的RTT越长，路由器中的拥塞越严重。即，vegas不是利用丢包来判断网络可用带宽，而是利用RTT变化来判断，因而更精准的探测网络可用带宽。
但Vegas有一个缺陷：使用TCP Vegas的流的带宽竞争力不如不使用TCP Vegas的流。因为网络路由器缓冲数据会造成RTT的变大，TCP Vegas会降低自己的拥塞窗口，但没有丢包的话，标准TCP流不会降低拥塞窗口。
NewReno
Reno提出的快速恢复算法提高了包丢失后的吞吐量和健壮性，但缺陷是它只考虑了只丢失一个包的情形，只要丢失了一个包，就被认为是发生了一次拥塞。而在实际的网络中，一旦发生拥塞，会丢弃大量的包。如果采用Reno算法，它会认为网络中发生了多次拥塞，则会多次将cwnd和ssthresh减半，造成吞吐量极具下降，当发送窗口小于3时，将无法产生足够的ACK来触发快重传而导致超时重传，超时重传的影响是非常大的。
NewReno改进了Reno算法的快速恢复算法。在只丢失一个数据包的情况下，NewReno和Reno的处理方法是一致的，而在同一个时间段丢失了多个包时，Reno的发送方只要收到一个新的ACK就会退出快速恢复状态而进入拥塞避免阶段，Neweno算法中只有当所有丢失的包都重传并收到确认后才退出。
同时，在NewReno中，添加了恢复应答判断功能来区分一次拥塞丢失多个包还是发生了多次拥塞。
先了解两个概念：部分应答（PACK）、恢复应答(RACK) 记TCP发送端快速恢复阶段中接收到的ACK报文（非冗余ACK）为ACKx 记在接收到ACKx时TCP终端已发出的序列号（SN）最大的报文是PKTy
如果ACKx不是PKTy的应答报文，则称报文ACKx为部分应答（Partial ACK，简称PACK）； 如果ACKx恰好是PKTy的应答报文则称报文ACKx为恢复应答（Recovery ACK，简称RACK）。 NewReno通过以上两种确认应答来判断是否退出快速恢复阶段。 直到收到所有丢失的包都被重发且被接受方收到了才会退出。
TCP BIC/CUBIC
TCP Binary Increase Congestion control 优化高速高延迟网络的拥塞控制。使用二分搜索算法尝试查找拥塞窗口最大值。
如果发生丢包时窗口大小为W1，最大窗口Wmax<W1,此时缩小窗口到W2，W1>Wmax>W2,这时将窗口设置为（W1+W2)/2.每收到一个ACK将窗口大小设置为两个界限的中点。
CUBIC使用三次函数代替二分算法，使用函数拐点作为拥塞窗口的设置值。
BBR
TCP Bottleneck Bandwidth and Round-trip propagation time.以往拥塞算法是基于丢包作为降低传输速率的信号，BBR基于模型主动探测。使用网络最近出站数据分组当时的最大带宽和往返时间建立网络显式模型。数据包的每个累积或选择性确认用于生成记录在数据包传输过程和确认返回期间的时间内所传送数据量的采样率。该算法认为随着网络接口控制器逐渐进入千兆速度时，分组丢失不应该被认为是识别拥塞的主要决定因素，所以基于模型的拥塞控制算法能有更高的吞吐量和更低的延迟，可以用BBR来替代其他流行的拥塞算法，例如CUBIC。
小结
TCP拥塞控制的关键点是：1、探测是否出现拥塞；2、出现拥塞时如何反应。
最初的算法是基于丢包来判断是否发生了拥塞，一旦出现拥塞之后就降低发送速率来避免拥塞。
基于RTT判断拥塞的算法，但是这种算法会产生公平性问题。
基于延迟的窗口能够保证有带宽时能迅速提高来提高带宽利用率。
而BBR则直接采用主动探测的方式来判断拥塞是否发生。
参考
blog.csdn.net/lyn_00/arti…
bbkgl.github.io/2020/07/22/…
megaredfan.github.io/2019/12/29/…
blog.csdn.net/zhangskd/ar…
