TCP/IP详解--学习笔记(12)-TCP的超时与重传

超时重传是TCP协议保证数据可靠性的另一个重要机制，其原理是在发送某一个数据以后就开启一个计时器，在一定时间内如果没有得到发送的数据报的ACK报文，那么就重新发送数据，直到发送成功为止。

1.超时

超时时间的计算是超时的核心部分，TCP要求这个算法能大致估计出当前的网络状况，虽然这确实很困难。要求精确的原因有两个：(1)定时长久会造成网络利用率不高。(2)定时太短会造成多次重传，使得网络阻塞。所以，书中给出了一套经验公式，和其他的保证计时器准确的措施。

1.1.递推公式概说

最早的TCP曾经用了一个非常简单的公式来估计当前网络的状况，如下

R<-aR+(1-a)M RTP=Rb

其中a是一个经验系数为0.1，b通常为2。注意，这是经验，没有推导过程，这个数值是可以被修改的。这个公式是说用旧的RTT(R)和新的RTT(M)综合到一起来考虑新的RTT(R)的大小。但是，我们又看到，这种估计在网络变化很大的情况下完全不能做出“灵敏的反应”（Jacoboson说的，不是偶说的，呵呵），于是就有下面的修正公式：

Err=M-A A<-A+gErr D<-D+h(|Err|-D) RTO=A+4D

具体的解释请看书的228页，这个递推公式甚至把方差这种统计概念也使用了进来，使得偏差更加的小。而且，必须要指出的是，这两组公式更新，都是在数据成功传输的情况下才进行，在发生数据重新传输的情况下，并不使用上面的公式进行网络估计，理由很简单，因为程序已经不在正常状态下了，估计出来的数据也是没有意义的。

1.2.RTO的初始化

RTO的初始化是由公式决定的，例如最初的公式，初始的值应该是1。而修正公式，初始RTO应该是A+4D。

1.3.RTO的更新

当数据正常传输的情况下，我们就会用上面的公式来更新各个数据，并重开定时器，来保证下一个数据被顺利传输。要注意的是：重传的情况下，RTO不用上面的公式计算，而采用一种叫做“指数退避”的方式。例如：当RTO为1S的情况下，发生了数据重传，我们就用RTO=2S的定时器来重新传输数据，下一次用4S。一直增加到64S为止。

1.4.估计器的初始化

在这里，SYN用的估计器初始化似乎和传输用的估计器不一样（我也没有把握）造我的理解，在修正公式中，SYN的情况下，A初始化为0,D初始化为3S。

而在得到传输第一个数据的ACK的时候，应该按照下面的公式进行初始化：

A=M+0.5 D=A/2

1.5.估计器的更新

和上面的讨论差不多，就是在正常情况下，用上面的公式计算，在重传的情况下，不更新估计器的各种参数。原因还是因为估计不准确。

1.6.Karn算法

这不算是一个算法，这应该是一个策略，说的就是更新RTO和估计器的值的时机选择问题，1.3.和1.5.所说得更新时机就是Karn算法。

1.7.计时器的使用

两句话:

一个连接中，有且仅有一个测量定时器被使用。也就是说，如果TCP连续发出3组数据，只有一组数据会被测量。
ACK数据报不会被测量，原因很简单，没有ACK的ACK回应可以供结束定时器测量。

2.重传

有了超时就要有重传，但是就算是重传也是有策略的，而不是将数据简单的发送。

2.1.重传时发送数据的大小

前面曾经提到过，数据在传输的时候不能只使用一个窗口协议，我们还需要有一个拥塞窗口来控制数据的流量，使得数据不会一下子都跑到网路中引起“拥塞”。也曾经提到过，拥塞窗口最初使用指数增长的速度来增加自身的窗口，直到发生超时重传，再进行一次微调。但是没有提到，如何进行微调，拥塞避免算法和慢启动门限就是为此而生。

所谓的慢启动门限就是说，当拥塞窗口超过这个门限的时候，就使用拥塞避免算法，而在门限以内就采用慢启动算法。所以这个标准才叫做门限，通常，拥塞窗口记做cwnd，慢启动门限记做ssthresh。下面我们来看看拥塞避免和慢启动是怎么一起工作的

算法概要(直接从书中拷贝)

对一个给定的连接，初始化cwnd为1个报文段，ssthresh为65535个字节。
TCP输出例程的输出不能超过cwnd和接收方通告窗口的大小。拥塞避免是发送方使用的流量控制，而通告窗口则是接收方进行的流量控制。前者是发送方感受到的网络拥塞的估计，而后者则与接收方在该连接上的可用缓存大小有关。
当拥塞发生时（超时或收到重复确认），ssthresh被设置为当前窗口大小的一半（cwnd 和接收方通告窗口大小的最小值，但最少为2个报文段）。此外，如果是超时引起了拥塞，则 cwnd被设置为1个报文段（这就是慢启动）。
当新的数据被对方确认时，就增加cwnd，但增加的方法依赖于我们是否正在进行慢启动或拥塞避免。如果cwnd小于或等于ssthresh，则正在进行慢启动，否则正在进行拥塞避免。慢启动一直持续到我们回到当拥塞发生时所处位置的半时候才停止（因为我们记录了在步骤2 中给我们制造麻烦的窗口大小的一半），然后转为执行拥塞避免。

补充上面的拥塞避免公式在P238页。这整个的流程让我联想到开车换档的过程。

2.2.快速重传和快速恢复算法

这是数据丢包的情况下给出的一种修补机制。一般来说，重传发生在超时之后，但是如果发送端接受到3个以上的重复ACK的情况下，就应该意识到，数据丢了，需要重新传递。这个机制是不需要等到重传定时器溢出的，所以叫做快速重传，而重新传递以后，因为走的不是慢启动而是拥塞避免算法，所以这又叫做快速恢复算法。流程如下：

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

2.3.ICMP会引起重新传递么？

答案是：不会，TCP会坚持用自己的定时器，但是TCP会保留下ICMP的错误并且通知用户。

2.4.重新分组

TCP为了提高自己的效率，允许再重新传输的时候，只要传输包含重传数据报文的报文就可以，而不用只重传需要传输的报文。