TCP拥塞控制

一、慢启动和拥塞避免

拥塞避免和慢启动需要对每个连接维持两个变量：拥塞窗口cwnd和慢启动门限ssthresh。

发送方维持一个拥塞窗口cwnd，拥塞窗口大小取决于网络的拥塞程度，动态地在变化。拥塞避免是发送方使用的流量控制，通告窗口则是接收方进行的流量控制。前者是发送方感受到网络拥塞的估计，后者则与接收方在该连接上的可用缓存大小有关。

慢启动算法：

         每次传输，拥塞窗口cwnd从一开始加倍的指数增长，增到慢启动门限ssthresh后，开启拥塞控制避免。

拥塞避免：

        让拥塞窗口缓慢的线性增大。

 

无论在慢启动阶段还是拥塞避免阶段，发送方判断网络出现拥塞（根据就是有无收到确认和有无超时），就把慢启动门限ssthresh设置为出现拥塞时的发送方窗口值的一半（但不能小于2)。把拥塞窗口cwnd重新设置为1（当然后面会说到改进后的并不是把cwnd设为1），执行慢启动。

 

二、快重传和快恢复

快重传：发送方只要收到三个重复确认就应该马上重传对方没收到的报文段，而不必等到设置的重传计时器到期。

快恢复：

• 当发送方连续收到三个重复确认，把慢开始门限ssthresh减半。

• 不执行慢启动算法（即拥塞窗口cwnd现在不设置为1），而是把cwnd值设置为慢启动门限ssthresh减半后的数值，然后开始执行拥塞避免算法（“加法增大”），使拥塞窗口缓慢地线性增大。

 

补充：

为何通过三个重复确认来判断是否丢包？因为我们不知道一个重复的ACK是由一个丢失的报文段引起的，还是由于出现了几个报文段的重新排序，所以就设定用三个重复确认来判别。

但其实这种基于丢包的拥塞控制是有缺陷的：

1.不能区分是拥塞导致的丢包还是错误丢包。丢包并不一定是网络发生了拥塞，也有可能是链路错误造成分组丢失。

2.引起缓冲区膨胀。基于丢包的拥塞控制方法倾向于填满缓冲区，但缓冲区很大时，需要很长时间才可以将里面的数据排空，就造成很大的网络延时。而且缓冲区被填满时，还会出现丢包。

这缺点就是Google的TCP BBR拥塞控制算法的动机。BBR的基本观点是不考虑丢包，而通过即时宽带探测来控制。

具体可参考博文：https://www.cnblogs.com/jiulonghudefeizhai/p/9991842.html