今日刷题总结16

超时重传时间

一个tcp报文从发出到接到该报文的确认所经过的时间为报文的往返时间RTT。tcp会根据RTT计算它的加权平均往返时间RTTs，又称平滑的往返时间。当第一次测量到RTT时，RTTs就会设定为RTT，而之后每次测量到一个新的RTT时，就会按下式计算新的RTTs：

新的RTTs=（1-α）x（旧的RTTs）+αx（新的RTT）

上式中0≤α<1。RFC 2988推荐α的值为0.125。用这种方法得出的平滑的往返时间RTTs比测量到的往返时间RTT更加平滑。

与此同时，tcp还会根据RTT计算偏差的加权平均往返时间RTT_D。RFC 2988建议的计算方法是，当第一次测量到RTT时，RTTD的值为RTT的一半，而后每次测量到新的RTT就用下式计算新的RTT_D：

新的RTT_D=（1-β）x（旧的RTT_D）+βx|RTTs-新的RTT|

其中β为小于1的系数，推荐值为0.25。

RFC 2988推荐使用下式计算超时重传时间RTO（RetransmissionTime-Out）：

RTO=RTTs+4xRTT_D

以上所述的RTT的测量实现起来相当复杂。如下图所示，假设发送一个报文后没有按时收到确认并导致重传，在随后的时间内收到了对该报文的确认，问题是该确认报文是对先发送报文的确认还是对重传报文的确认。因为重传报文和先发送的报文完全相同，所以源主机无法做出正确的判断。如果确认是对先发送报文的确认，但被误认为是对重传报文的确认，则计算出的RTTs和RTO要比实际的偏小，势必导致报文会不必要地重传，而且RTTs和RTO有可能会越来越小。若果确认时对重传报文的确认，但被误认为是对先发送报文的确认，计算出的RTTs和RTO要比实际的偏大。于是Karn提出一个算法，即在计算RTTs时，只要报文重传了，就不采用新测量到的RTT。但是，如果报文的时延增大了很多，在原来的RTO内不会收到确认，于是重传报文，在该情况下根据Karm的算法计算新的RTTs、RTT_D和RTO时不会考虑测量到的RTT，如此RTO就无法更新。为此提出了一个改进的算法：报文每重传一次，就把RTO增大一些，通常是将新的RTO置为旧的RTO的2倍。当不再发生超时重传时，因为可以正确判断确认报文了，就按照RFC 2988推荐的方法计算RTO。