TCP慢启动阶段拥塞 丢包的处理（一）

TCP丢包的处理，在TCP/IP详解p235-236讲解的比较明确，这里进行一下扩展和细化。

原文摘录：

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

3）当拥塞发生时（超时或收到重复确认），ssthresh被设置为当前窗口大小的一半（cwnd和接收方通告窗口大小的最小值，但至少为2个报文段）。此外，如果是超时引起了拥塞，则cwnd被设置为1个报文段（这就是慢启动）。"

【笔者注：这里的ssthresh，是慢启动和拥塞避免两个阶段的分界点，超过这个值，cwnd的增长就不再是乘性增长，而是加性增长，参照AIMD策略】。

重复确认：在收到一个失序的报文段时，TCP立即产生一个重复的ACK，我们不知道一个重复的ACK是报文丢失还是几个报文段重新排序引起的，假如这只是报文段的重新排序，则在重新排序的报文段被处理并产生一个新的ACK之前，只可能产生1~2个重复的ACK，如果一连串收到3个或3个以上的重复ACK，就非常可能是一个报文段丢失了。

【笔者按：为啥报文段重新排序只可能引起1~2个重复ACK？】

另外，在快速重传算法中，对重复确认的处理是执行快速恢复算法，实现过程是：

   " 1)当收到第三个重复的ACK时，将ssthresh设置为当前拥塞窗口cwnd的一半。重传丢失的报文段。设置cwnd为ssthresh加上三倍的报文段大小。【笔者按：为啥是加上三倍的报文段大小，这个常数设置怎么来的？历史原因还是经验？】

2）每次收到另一个重复的ACK时，cwnd增加1个报文段大小并发送1个分组（如果cwnd允许发送）。

3）当下一个确认新数据的ACK到达时，设置cwnd为ssthresh（在第一步中设置的值）。这个ACK应该是在进行重传后的一个往返时间内对步骤1中重传的确认。另外，这个ACK也应该是对丢失的分组和收到的第一个重复ACK之间的所有中间报文段的确认。这一步采用的是拥塞避免。因为当分组丢失时我们将当前速率减半。"

怎么用这段话解释慢启动阶段丢包的处理呢？分两种情况：

1.连续3个ACK，也就是重复确认，ssthresh降为一半，cwnd被设置为ssthresh的值+3倍报文段大小，进入拥塞避免 

2.RTO，也就是超时，ssthresh降为一半，cwnd变为1，新一轮慢启动