本文引用图片均来自 高军: 计算机网络
超时时间
超时重传时间RTO（Retransmission Time Out）的选择是TCP最复杂的问题之一
在两台已经建立TCP的主机之间，我们将发送方从发送报文到收到接收方的确认报文的这段时间称为报文往返时间RTT（Round Trip Time），如果超时重传时间设定的值比RTT小会导致不必要的重传增大网络负担，如果远大于RTT则会降低网络传输效率
理想情况下RTO应该略大于RTT
综上可以知道，RTO的取值很大程度上取决于RTT。然而，我们不能直接使用单次测量得到的RTT，因为每次报文经过的网络可能不一样，网络的状况在不同时间也不一样，这可能造成RTT的剧烈波动。为此，人们提出了加权平均的思路
RTT的加权平均计算公式为：
- ，第一次取值为RTT测量值
- ，旧值乘上系数加新的测量值RTT乘上系数
- ，
RFC6298推荐值为0.125
加权平均后的RTT比直接测量得到的RTT要更加平滑，此时RTO应该略大于加权平均后的RTT
RFC6298推荐RTO计算公式为：
为RTT偏差的加权平均，其计算公式如下：
- ，第一次取值为RTT测量值的一半
- ，RFC6298推荐值为0.25
到目前为止解决了计算公式的问题，但实际上RTO的设定还要更复杂一些，这其中的主要原因还是RTT的测量困难造成的，我们来看超时重传情况下的RTT测量：
场景1：发送方发送的报文丢失导致了超时重传，接收方收到了重传报文并发送确认报文，此时发送方误将该确认报文当作已丢失报文的确认报文，这会导致计算得到的和值偏大，降低了传输效率
场景2：发送方发送的报文被顺利接收，但是接收方的确认报文在网络滞留导致发送方超时重传，当确认报文终于到达发送方后被误认为是对重传报文的确认，这会导致测量得到的和值偏小，不必要的重传增大了网络负担
由上可知超时重传可能导致RTT测量值出现大的偏差，为此Karn提出如果出现了超时重传，那么RTO就不进行更新。但是，该算法会面临新的问题，假设网络环境突然变差时延剧增，那么很多报文会超时重传。根据Karn的算法，这段时间RTO是不进行更新的，那么在网络环境变差的这段时间内报文会一直超时从而反复被重传。目前比较典型的对Karn算法进行修正的方法是——只要出现超时重传就把RTO乘以2
以下面RTO的计算例子作为本小节的总结：
可靠传输
TCP基于以字节为单位的滑动窗口实现可靠传输
虽然可靠传输的具体实现很复杂，但是其思想描述起来却不难。下面以例子进行讲解，为了描述方便这里假设数据是单向传输的且仅考虑发送窗口和接收窗口
总体来看，可靠传输是靠发送方发送数据报文以及接收方接收数据后返回确认报文的这样一个循环往复的过程来实现的
如下图，落在发送窗口中的数据都可以被发送出去，已发送并收到确认的数据则被移出窗口可以删除，窗口外的数据则不允许发送。发送方将31-41号数据封装在不同的报文段中发送
发送窗口的后沿只有在收到新的确认后才能往前移动，前沿通常随着后沿的前移而向前，但如果收到新的确认的同时对方通知接收窗口变小，那么前沿可能保持不动。如果对方通知窗口缩小的幅度大其实也可能导致前沿向后缩，不过TCP协议强烈建议不要这样干
接收方可以接收落在接收窗口中的数据，已发送确认并交付主机的数据被移出窗口可以删除，窗口外的数据则不允许接收。此例中接收方收到包含数据32、33的报文段，但接收方期望收到的是31号数据因此它们是乱序报文。接收方接收了乱序报文并放入缓存中，此时返回的确认报文是对最后一个按序到达的报文的重复确认（ack=31表明31号之前的数据都已正确接收，期望收到31号数据)。待接收方收到31号数据即可向前移动窗口
如果发送方迟迟收不到已发送数据的确认报文就会触发超时重传
其实总体来看，TCP实现可靠传输的思想就是——我们协商好发送窗口和接收窗口，我发送了窗口中的数据你要给我确认以及窗口调整的通知，确认数据被收到了我再调整窗口发送新数据，如果迟迟收不到确认我就重传直到收到确认为止
参考文献
- 【1】高军: 计算机网络
