目录
超时重传是TCP协议保证数据可靠性的另一个重要机制，其原理是在发送某一个数据以后就开启一个计时器，在一定时间内如果没有得到发送的数据报的ACK报文，那么就重新发送数据，直到发送成功为止。
TCP可靠性中最重要的一个机制是处理数据超时和重传。TCP协议要求在发送端每发送一个报文段，就启动一个定时器并等待确认信息；接收端成功接收新数据后返回确认信息。若在定时器超时前数据未能被确认，TCP就认为报文段中的数据已丢失或损坏，需要对报文段中的数据重新组织和重传。尽管超时重传的概念十分简单，但是在实现中，TCP处理超时重传的机制与其他可靠性协议相比是相当复杂的。
超时重传机制是TCP中非常重要和复杂的技术之一，也是TCP协议数据传输可靠性的保证。发送端每发送一个报文段，TCP便为其保留一个副本、设定一个计时器并等待确认信息。如果计时器超时，而发送的报文段中的数据仍未得到确认，则重传这一报文段，直到发送成功为止。由此可见，重传超时时间（Retransmission time-Out，RTO）的计算是超时重传的关键部分，TCP要求能大致估计出当前的网络状况。
基础概念
重传超时时间RTO
影响超时重传机制协议效率的一个关键参数是重传超时时间（RTO，Retransmission TimeOut）。RTO的值被设置过大过小都会对协议造成不利影响。如果RTO设置过大将会使发送端经过较长时间的等待才能发现报文段丢失，降低了连接数据传输的吞吐量；另一方面，若RTO过小，发送端尽管可以很快地检测出报文段的丢失，但也可能将一些延迟大的报文段误认为是丢失，造成不必要的重传，浪费了网络资源。
RTO的设定
如果底层网络的传输特性是可预知的，那么重传机制的设计相对简单得多，可根据底层网络的传输时延的特性选择一个合适的RTO，使协议的性能得到优化。但是TCP的底层网络环境是一个完全异构的互联结构。在实现端到端的通信时，不同端点之间传输通路的性能可能存在着巨大的差异，而且同一个TCP连接在不同的时间段上，也会由于不同的网络状态具有不同的传输时延。
因次，TCP协议必须适应两个方面的时延差异：一个是达到不同目的端的时延的差异，另一个是统一连接上的传输时延随业务量负载的变化而出现的差异。为了处理这种底层网络传输特性的差异性和变化性，TCP的重传机制相对于其他协议显然也将更为复杂，其复杂性主要表现在对超时时间间隔的处理上。为此，TCP协议使用自适应算法（Adaptive Retransmission Algorithm）以适应互联网分组传输时延的变化。这种算法的基本要点是TCP监视每个连接的性能（即传输时延），由此每一个TCP连接推算出合适的RTO值，当连接时延性能变化时，TCP也能够相应地自动修改RTO的设定，以适应这种网络的变化。
TCP协议采用自适应算法记录数据包的往返时延，并根据往返时延设定RTO的取值。一般来说，RTO的取值会略大于RTT以保证数据包的正常传输。RFC 2988中建议RTO的计算方式为：
其中RTTs为加权平均往返时间，RTTd是偏差的加权平均值。后续针对重传数据包确认和原来数据包确认区分问题，对该取值进行了修正：取旧重传时间的2倍作为新的重传时间。当不再发生数据包重传时，才重新根据上图所示式子计算超时重传时间。
连接往返时间RTT
判断超时采取的比较简单的方法就是指定一个固定的超时值，启动一个时间间隔为该值的计时器，计时器超时后就进行重发。这个固定值的指定可以选择传输往返时间（Round Trip Time，RTT），即所有网络上报文段的数据传输加上确认传输的时间。这个时间一过就可以确定报文段已经丢失了。
RTT的计算
针对网络环境的复杂性，TCP协议以传输往返时间RTT为基础，采用了一种自适应算法确定重传时间。由于RTT对应不同报文段的往返有不同的时延，而且其起伏比较大，导致其不能作为重传超时的标准。因此，这里将各个报文段的往返时间样本进行加权平均，就得出报文段的平均往返时间，可以记为SRTT，又称为平滑往返时间（Smoothed RTT）。第一次测量往返时间时，SRTT值就取所测量到的RTT样本值，但以后每测量到一个新的往返时间样本，就按下面的式子重新计算一次平滑往返时间SRTT：
新的SRTT=α×（旧的SRTT）+（1-α）×（新的RTT样本）式中α——平滑因子，范围是0≤α<1。若α值很接近于1，表示新计算出的SRTT和原来的值相比变化不大，新的往返时间RTT样本对SRTT的影响不大。若选择的α值接近于零，则表示加权计算的SRTT受新的往返时间样本的影响较大，典型的α为7/8。
Karn算法
如果在一个报文段中的数据被一次性地成功传输和确认，那么发送端可以准确得到该报文段传输的RTT样本。但若出现了重传，情况就会变得很复杂。例如，一个报文段发送后出现超时，TCP将在另一个报文段中重传。由于这两个报文段包含了同样的数据，发送方接收到确认信息时将无法分辨出确认信息到底是针对哪个报文段的，因为这两个报文段产生的确认信息可能是完全相同的，确认信息既可能是针对原始报文段的（这种情况可能是由于原报文段或确认在传输中被延迟造成的），也可能是对重传报文段的确认。这种现象称为确认二义性（Acknowledgement Ambiguiity）。确认的二义性将导致TCP无法准确地估算RTT。
解决上述问题可以考虑Karn算法，简单的说，在计算新的RTT时，不考虑重传报文段的RTT，即对于发送重传的数据段，在收到确认信息后，不要更新RTT，除非发送了一个报文段并在不需要重传的情况下收到了确认信息。
Karn算法能够防止由于数据段重传造成的不正确的往返时间（RTT）的测量。该算法最初被用在分组无线电网络中，对分组丢失的问题是一种较好的解决办法。但Karn算法也有一个主要缺点，就是不能适应网络中延迟的高速变化。
往返时间测量
往返时间的测量比较复杂。由于路由器和网络流量均会变化，因此TCP应该跟踪这些变化并相应的改变超时时间。TCP必须首先测量在发送一个带有特别序号的字节和接收到包含该字节的确认之间的RTT。对往返时间的测量有很多方法：
- ICMP时间戳请求和应答；
- 日期服务程序和时间服务程序；
- 网络时间协议（NTP）；
- 开放软件基金会（OSF）的分布式计算环境（DCE）定义的分布式时间服务（DTS）；
- 伯克利大学的UNIX系统提供的守护程序timed（8）来同步局域网上的系统时钟。
重传
有了超时就要有重传，但是就算是重传也是有策略的，而不是将数据简单的发送。
TCP报文重传的次数也根据系统设置的不同而有区分，有些系统，一个报文只会被重传3次，如果重传3次后还未收到该报文的确认，那么就不再尝试重传，直接reset重置该TCP连接，但有些要求很高的业务应用系统，则会不断地重传被丢弃的报文，以尽最大可能保证业务数据的正常交互。
TCP的重传存在原因就是为了保障TCP的可靠性，正是由于TCP存在重传的机制，那些基于TCP的业务应用在网络交互的过程中，不再担心由于丢包、包损坏等导致的一系列应用问题了。
由于IP协议的不可靠性和网络系统的复杂性，少量的报文丢失和TCP重传是正常的，但是如果业务交互过程中，存在大量的TCP重传，会严重影响业务系统交互的效率，导致业务系统岀现缓慢甚至无响应的情况发生。一般而言，出现大量TCP重传说明网络通信的状况非常糟糕，需要站在网络层的角度分析丢包和重传的原因。
拥塞避免算法
该算法假定由于分组收到损坏引起的丢失是非常少的，因此分组丢失就意味着在源主机和目的主机之间的某处网络上发生了阻塞。有两种分组丢失的指示：发生超时和收到重复的确认。拥塞避免算法需要对每个连接维持两个变量：一个拥塞窗口cwnd和一个慢启动门限ssthresh。
对一个给定的连接，初始化cwnd为1个报文段，ssthresh为65535个字节。TCP输出例程的输出不能超过cwnd和接收方通告窗口的大小。拥塞避免是发送方使用的流量控制，而通告窗口则是接收方进行的流量控制。前者是发送方感受到的网络拥塞的估计，而后者则与接收方在该连接上的可用缓存大小有关。当拥塞发生时（超时或收到重复确认），ssthresh被设置为当前窗口大小的一半（cwnd 和接收方通告窗口大小的最小值，但最少为2个报文段）。此外，如果是超时引起了拥塞，则cwnd被设置为1个报文段（这就是慢启动）。当新的数据被对方确认时，就增加cwnd，但增加的方法依赖于是否正在进行慢启动或拥塞避免。如果cwnd小于或等于ssthresh，则正在进行慢启动，否则正在进行拥塞避免。
快速重传和快速恢复算法
如果一连串收到3个或以上的重复ACK,就非常可能是一个报文段丢失了。于是就重传丢失的数据报文段,而无需等待超时定时器溢出。
- 当收到第3个重复的ACK时，将ssthresh设置为当前拥塞窗口cwnd的一半，重传丢失的报文段，设置cwnd为ssthresh加上3倍的报文段大小。
- 每次收到另一个重复的ACK时，如果允许的话，cwnd增加1个报文段大小并发送一个1个分组。
- 当下一个确认新数据的ACK到达时，设置cwnd为ssthresh。这个 ACK应该是在进行重传后的一个往返时间内对步骤1中重传的确认。另外，这个ACK也应该是对丢失的分组和收到的第1个重复的ACK之间的所有中间报文段的确认。
重新分组
当TCP超时并重传时，并不一定要重传同样的报文段。TCP允许进行重新分组而发送一个较大的报文段，这样有助于提高性能。在协议中这是允许的，因为TCP是使用字节序号而不是报文段序号来识别它所要发送的数据和确认的。
网络数据包丢失，重传和重复确认
https://accedian.com/blog/network-packet-loss-retransmissions-and-duplicate-acknowledgements/#:~:text=The%20TCP%20retransmission%20mechanism%20ensures%20that%20data%20is,on%20the%20network%20somewhere%20between%20client%20and%20server.
这是我们有关TCP的系列文章的第三篇，涵盖了解决影响关键业务应用程序的性能问题所需的全部知识。经过考虑 TCP如何打开 并关闭连接，我们现在将检查正在进行的连接可能发生的问题，特别是网络数据包丢失。
是什么导致网络数据包丢失？
网络数据包丢失的两个最常见的原因是：
- 第二层（L2）错误
- 和网络拥塞
如果由于电缆问题，双工问题或其他第1层事件导致帧在连接上从点到点出错，则接收器将确定数据已损坏并将其丢弃。在大多数情况下，错误计数器将在接口上增加，这在查找丢失发生位置时会有所帮助。
流量拥塞会导致接口链路上的输入/输出丢弃，尤其是在链路速度之间转换时（例如10Gbps到1Gbps）。在这些连接上，出口链接可能无法跟上入口流量的数量，这可能导致数据包丢失。流量的发送者将确定发生的丢失并重新传输。这些通常在接口上标记为“丢弃”。
正如我们在本系列文章中所看到的，TCP是一种面向连接的协议。建立连接的部分功能是创建一种机制来跟踪已发送的数据并确认接收到的数据。这样，TCP可以检测数据包是否丢失并相应地重新发送它，从而确保数据的可靠传输。
网络数据包丢失：我们今天仍在应对吗？
是。 尽管网络链接的成熟度达到10Gbps或更高，但丢包仍然是影响当今应用程序的潜在网络事件。要解决这些问题，我们首先需要了解如何丢弃数据包，如何检测这些事件以及如何解决它们。
TCP重传
TCP重传意味着通过网络重新发送丢失或损坏的数据包。在此，重传是诸如TCP之类的协议用来提供可靠通信的机制。在这里，可靠的通信意味着即使数据包丢失或损坏，该协议也可以保证包的传递。
网络不可靠，不能保证丢失或损坏的数据包的延迟或重新传输。结合使用确认和重新传输已损坏或丢失的数据包的网络可提供可靠性。
在此，重传意味着数据包已丢失，这导致缺乏确认。缺少确认会触发计时器超时，从而导致数据包的重新传输。在此，计时器表示如果在计时器到期之前未收到确认，则重新发送数据包。
TCP连接中发送的每个数据字节都有一个关联的序列号。这在TCP标头的序列号字段中指示。
当接收套接字检测到传入的数据段时，它将使用TCP报头中的确认号来指示接收。发送数据包后，发送方将启动可变长度的重传计时器。如果在计时器到期之前未收到确认，则发送方将假定该段已丢失，并将重新发送该段。
TCP头
TCP重传机制可确保从一端到另一端可靠地发送数据。如果在TCP连接中检测到重传，则可以合理地假设客户端和服务器之间某处的网络上发生了数据包丢失。
https://www.javatpoint.com/tcp-retransmission
让我们考虑以下重传场景。
场景1：数据包丢失或错误。
在这种情况下，该数据包被发送到接收器，但在该超时期限内未收到确认。超时时间到期后，将重新发送数据包。重发数据包后，将收到确认。一旦收到确认，就不会再次发生重传。
方案2：当接收到数据包但确认丢失。
在这种情况下，在另一侧接收到该数据包，但是丢失了确认，即，在发送方未接收到ACK。超时期限到期后，将重新发送数据包。另一侧有两个数据包副本。尽管正确接收了数据包，但未收到确认，因此发送方重新发送了数据包。在这种情况下，本可以避免重传，但是由于ACK丢失，因此将重传该数据包。
方案3：发生早期超时时。
在这种情况下，将发送数据包，但是由于在实际超时之前已发生确认延迟或超时，因此将重新传输数据包。在这种情况下，由于确认延迟或已将超时设置为比实际超时更早，因此不必要地再次发送了数据包。
在上述场景中，无法避免第一种情况，但是可以避免其他两种情况。让我们看看如何避免这些情况。
发件人应等待多长时间？
发送方设置ACK的超时时间。超时时间可以有两种类型：
- 太短：如果超时时间太短，那么重新传输将被浪费。
- 太长：如果超时时间太长，则丢失数据包时会存在过多的延迟。
为了克服以上两种情况，TCP将超时设置为RTT（往返时间）的函数，其中往返时间是数据包从源传输到目的地然后再次返回的时间。
我们如何获得RTT？
RTT可以根据网络的特性而变化，即，如果网络拥塞，则意味着RTT很高。我们可以通过简单地观察ACK来估计RTT。
让我们看看如何测量RTT。
我们将使用原始算法来衡量RTT。
- 步骤1：首先，我们测量每个段或ACK对的SampleRTT。当发送方发送数据包时，我们知道发送数据包的计时器，也知道收到确认的计时器。计算这两者之间的时间，即成为SampleRTT。
- 步骤2：我们将不只抽取一个样本。我们将继续获取不同的样本并计算这些样本的加权平均值，这就是EstRTT（估算的RTT）。其中，α+β= 1，α在0.8到0.9之间，β在0.1到0.2之间
- 步骤3：根据EstRTT设置超时时间。超时= 2 * EstRTT。超时设置为估计的RTT的两倍。这是实际超时因子的计算方式。
这种方法的缺陷
原始算法存在缺陷。让我们考虑两种情况。
场景1
上图显示发送方发送数据，该数据被称为原始传输。在超时期限内，未收到确认。因此，发送方重新传输数据。重新发送数据后，将收到确认。假设接收到的确认是针对原始传输的，而不是针对重传的。由于我们得到了原始传输的确认，因此在原始传输时间与接收到确认时间之间计算SampleRTT。但是实际上，SampleRTT应该在重传时间与确认时间之间。
场景2。
上图显示了发送方发送了原始数据包，对此我们也得到了确认。但是，在重新发送数据之后，将收到确认。如果我们假设确认属于重传，则在重传时间和确认时间之间计算SampleRTT。
在以上两种情况下，都有一个模棱两可的含义：不知道确认是针对原始传输还是针对重传。
以上算法的结论。
- 此处，ACK并不意味着确认传输，而是实际上确认了数据的接收。
- 如果考虑第一种情况，则对丢失的数据包进行重传。在这种情况下，我们假设ACK属于原始传输，因此SampleRTT会非常大。
- 如果考虑第二种情况，则会发送两个相同的数据包，因此在这种情况下会发生重复。在这种情况下，我们假设ACK属于重传，因此SampleRTT会变得非常小。
为了克服上述问题，通过卡恩/帕特里奇算法给出了一种简单的解决方案。该算法给出了一种简单的解决方案，该解决方案可以一次收集发送的样本，并且不考虑重传时的样本来计算估计的RTT。
Karn/ Part算法
在以上两种情况下，都会发生重传，并且我们已经考虑了RTT示例。但是此算法在重传时不考虑Sample RTT。由于发生了重传，这意味着在此往返时间内发生了某些情况，或者在网络中可能发生了一些拥塞。为克服此问题，此算法在每次重传后将超时时间加倍。该算法在TCP网络中实现。
局限性
它不考虑RTT中的差异。
- 如果方差很小，EstimatedRTT就会很准确。如果方差大，则估计RTT不准确。
为了克服以上限制，开发了Jacobson / Karels算法，该算法在RTT中引入了方差因子。
Jacobson / Karels算法
开发该算法是为了克服Karn / Partridge算法的局限性。它计算SampleRTT和EstimatedRTT之间的差异，并基于该差异提高RTT。
计算平均RTT
- 首先，我们计算差异因子。
差异= SampleRTT-估算的RTT
- 现在，我们计算EstimatedRTT，其计算方法与上述相同。
EstRTT = EstRTT +（δ* Diff）
- 现在，我们计算差异因子的平均值。
Dev = Dev +δ（| Diff |-Dev）
这里，开发是一个偏差因子，δ是一个因素0和1之间的开发是从所述方差的估计EstRTT。
- 在计算超时值时，我们将考虑方差。
超时= µ * EstRTT +ɸ* Dev
其中，μ= 1且ɸ= 4
快速重传
基于超时的重传策略效率低下。TCP是一种滑动窗口协议，因此无论何时发生重传，它都会从丢失的数据包开始发送。
假设我发送数据包0、1、2和3。由于在另一侧接收到数据包0和数据包1，因此网络中丢失了数据包2。我已经收到了数据包0和数据包1的确认，因此我又发送了两个数据包，即数据包4和数据包5。当发送数据包3、4和5时，我将获得数据包1的确认为TCP确认。是累积的，因此它最多确认已按顺序收到的数据包。我没有在超时时间内收到数据包2、3、4和5的确认，因此我重传了数据包2、3、4和5。由于数据包2丢失了，但是其他数据包（即3、4）丢失了，5在另一侧被接收，由于这种超时机制，它们仍然被重新发送。
如何消除超时无效？
滑动窗口下的更好解决方案：
假设丢失了n个数据包，但仍然接收到n + 1，n + 2等数据包。接收器正在连续接收数据包并发送ACK数据包，表明接收器仍在等待第n个数据包。接收方正在发送重复或重复的确认。在上述情况下，由于丢失了数据包2，因此发送了3次数据包1的ACK。此重复的ACK数据包指示第n个数据包丢失，但后来的数据包被接收。
以上情况可以通过以下方式解决：
- 发送方可以将“重复的ACK”作为第n个数据包已丢失的早期提示，以便发送方可以尽早进行重传，即，发送方不应该等到发生超时为止。
- 发送方可以在TCP中实现快速传输策略。在快速传输策略中，发送方应将三重重复ACK视为触发并重新传输。
TCP使用三个重复的ACK作为触发，然后执行重传。在上述情况下，当接收到数据包1的三个ACK时，发送方应发送丢失的数据包（即数据包2），而无需等待超时周期的发生。
TCP复制/选择性确认
当检测到两个具有相同ACK编号的ACK数据包时，大多数数据包分析器将指示重复的确认条件。
TCP复制/选择性确认
这些如何发生？
发送TCP套接字通常以一系列方式传输数据。发送站将连续发送几个数据包，而不是一次发送一个数据段并等待确认。如果流中的这些数据包之一丢失，则接收套接字可以使用选择性确认来指示丢失了哪个数据包。
这些允许接收方继续确认传入的数据，同时通知发送方流中丢失的数据包。
如上所示，选择性确认将使用TCP报头中的ACK号来指示丢失了哪个数据包。同时，在这些ACK数据包中，接收器可以使用TCP头中的SACK选项显示丢失点之后已成功接收到哪些数据包。
SACK选项是每个站在TCP连接开始时通告的功能。大多数网络分析仪会将这些数据包标记为重复确认，因为ACK编号将保持不变，直到重新传输丢失的数据包为止，从而填补了序列中的空白。
通常，重复确认意味着流中丢失了一个或多个数据包，并且连接正尝试恢复。它们是丢包的常见症状。在大多数情况下，一旦发送方收到三个重复的确认，它将立即重新发送丢失的数据包，而不是等待计时器到期。这些称为快速重传。
当段丢失时，客户端与服务器之间的连接具有更高的延迟，通常会有更多的重复确认数据包。在高延迟的连接中，有可能观察到单个丢失数据包的数百个重复确认。
结论
如果在连接上检测到TCP重传和重复的确认，则不要以为天空正在下降并且性能已经停顿下来。根据端点之间的网络，少量端点可能是正常的。
例如，如果服务提供商正在将最终用户连接到数据中心中的应用程序，或者如果该应用程序托管在云环境中，则存在超出网络团队控制和可视范围的多个连接。最终用户可能会感觉性能正常，但是可能存在少量的重传。
但是，在通过抱怨增加用户的重传次数来解决应用程序性能问题时，根本原因可能是数据包丢失。至少，丢包将成为难题的重要组成部分。
丢失的数据包需要重新传输，这需要时间，这将使应用程序变慢。根据发生的次数以及端点恢复丢失的数据包的速度，它们会严重影响应用程序的性能。
在这些情况下，请在客户端和服务器之间建立链接，分析您控制的所有基础结构设备的链接级错误。可能是您发现故障电缆，帧检查序列计数器（FCS）或丢弃指示器，这是造成数据包丢失的原因。
参考资料
- 1. 刘素芹，曹绍华．TCP/IP协议分析：中国石油大学出版社，2012.05：146-147
- 2. 龚向阳等．宽带通信网原理：北京邮电出版社，2006年：290-295
- 3. 席振元，田立勤．数据通信与计算机网络：煤炭工业出版社，2010.12：152-153
- 4. 王田媛. LTE网络下TCP协议重传算法优化[D].北京邮电大学 ．中国知网．2018[引用日期2020-04-09]
- 5. 徐劲松．计算机网络应用技术：北京邮电大学出版社，2015.01：76
- 6. 武奇生．计算机网络及工程实践：西安电子科技大学出版社，2013.10：224-225
参考链接
719
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
