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

TCP的拥塞窗⼝和快速恢复机制的⼀些备忘及⼀点想法
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时的数据都已收到，该恢复过程已经结束，可以回到恢复之前的状态了，也即再次进⼊拥塞避免状态。