TCP的拥塞窗口和快速恢复机制的一些备忘及一点想法

Posted 2022-06-28 dongzhiquan

rwnd（窗口，代表接收端的处理能力）、cwnd（拥塞窗口，从发送端看当前网络整体承载能力）、ssthresh（快速增长切换成慢速增长的界限值）

1.慢启动，是指数增长（对面确认多少个包，就增加多少），并不慢，只是它的起点低，所以慢启动阶段仍需要时间。实际是起点低（1），快增长阶段，每一轮将当前拥塞窗口翻倍。
2.拥塞避免，引入了ssthresh（这个是个变量，初始往往是最大值65536，随后续拥塞发生不断调整），控制慢启动阶段区间是在窗口超过ssthresh之后，就开始线性增长（是让cwnd缓慢的增加而不是如慢启动时加倍的增长，每经历过一次往返时间就使cwnd增加1，而不是加倍，这样使cwnd缓慢的增长，比慢启动要慢的多。 一种通用的方法是对于TCP发送方无论何时到达一个新的确认，就将cwnd增加一个MSS(MSS/cwnd)）。 实际是慢速逼近最大值。

3.拥塞状态，RTO超时且还没有得到数据确认，TCP就会对该报文段进行重传。 超时重传的发生就是拥塞状态进入标志。
拥塞状态发生后，1.把ssthresh降低为cwnd值的一半 2.把cwnd重新设置为1 3.重新进入慢启动过程。

4.仅存在慢启动和拥塞避免实际TCP也可以工作，不断在慢启动和拥塞避免之间循环：
慢启动出现拥塞（ssthresh初始值65536，不会达到），重新进入慢启动。
慢启动cwnd超过ssthresh（ssthresh此时是上次丢包是cwnd的一般，可以超过），进入拥塞避免。
拥塞避免出现拥塞，重新进入慢启动。
......

5.虽然慢启动和拥塞避免 配合拥塞状态也能工作，但发生拥塞后慢启动的起点低，耗时仍比较长，所以有必要叠加快速重传机制。

6.TCP利用3个相同的ACK来判定数据包丢失，这个可以认为是拥塞状态2，这个拥塞状态由接收端判定触发，此时RTO并未超时，只是接收端认为收到了很多大于某个序号seqx的包，但是seqx本身却没收到。 此时进行快速重传操作（每收到一个后面的包就会发一个未收到包的ack），快速重传机制实际就是拥塞状态2发生时的一个处理机制，或者说，拥塞状态2直接命名为快速重传2也可以。
拥塞状态2发生后，1.把ssthresh设置为cwnd的一半 2.把cwnd再设置为ssthresh的值(具体实现有些为ssthresh+3) 3.重新进入拥塞避免阶段。

8.有了拥塞状态2和快速重传机制后，拥塞避免就可以再次进入拥塞避免，这种情况下避免慢启动再次经历耗费时间，对网络的短暂波动适应能力强：
出现拥塞1（超时），则进入慢启动。
出现拥塞2（3ACK），则进入拥塞避免。
可以猜想：
在报文发送较少，低速状态时，发送了一个包，后面又没有什么后续报文。倘若该报文被丢了，此时接收端并不会感知到啥，只能依靠拥塞1来检测进入慢启动了。实际此时慢启动也关系不大，因为本身速率较低。
在报文发送较多，高速状态时，发送了一个包，后续还有很多后续报文。倘若该报文丢了，此时接收端可以更快感知到某个报文被丢弃，因为他会发现后续大部分甚至所有报文都到了，唯独缺了这个报文，就正常分析看，那个报文被丢弃可能性很大。 由于接收端此时对于丢包感知更快，主要会依靠拥塞2来检测，调整ssthresh和cwnd之后再次快速重传进入拥塞避免阶段。 这样避免了重新经历慢启动，节约了部分时间，避免了对速率造成更大影响。

9.通过拥塞2进入拥塞避免会经历快速恢复阶段(也有一种提法根本就没有快速恢复阶段，所谓快速恢复只是指出现拥塞2时直接转入拥塞避免的一个处理机制)。
快速恢复的流程：
1.当收到3个重复ACK时，把ssthresh设置为cwnd的一半，把cwnd设置为当前ssthresh的值加3，然后重传丢失的报文段，加3的原因是因为收到3个重复的ACK，表明有3个“老”的数据包离开了网络到达对岸。
2.再收到重复的ACK时，拥塞窗口增加1。
3.当收到新的数据包的ACK时，把cwnd设置为第一步中保存的ssthresh的值。原因是因为该ACK确认了新的数据，说明从重复ACK时的数据都已收到，该恢复过程已经结束，可以回到恢复之前的状态了，也即再次进入拥塞避免状态。