【tcp】关于tcp 超时重传次数

一般TCP报文的重传超时时间TCP重传时间间隔有着多种不同的算法，最常见的就是《TCP/IP详解卷1》中关于超时重传的算法。 具体算法不再赘述，请大家参考《TCP/IP详解卷1》第21章《TCP的超时与重传》。SYN报文重传间隔时间在实际情况下，由于SYN报文是TCP连接的第一个报文，如果该报文在传输的过程中丢弃了，那么发送方则无法测量RTT，也就无法根据RTT来计算RTO。 因此，SYN重传的算法就要简单一些，SYN重传时间间隔一般根据系统实现的不同稍有差别，Windows系统一般将第一次重传超时设为3秒，以后每次超时重传时间为上一次的2倍，如下图所示：报文重传的次数TCP报文重传的次数也根据系统设置的不同而有区分，有些系统，一个报文只会被重传3次，如果重传三次后还未收到该报文的确认，那么就不再尝试重传，直接reset重置该TCP连接，但有些要求很高的业务应用系统，则会不断的重传被丢弃的报文，以尽最大可能保证业务数据的正常交互。数据被重发以后若还是收不到应答，则进行再次发送。此时等待确认应答时间会以2倍、4倍的指数函数延长。此外，数据也不会被无限、反复的重发。达到一定的重发次数之后，如果仍然没有任何确认应答返回，就会判断为网络或者对端主机发生了异常，强制关闭连接。最小重传时间是 200ms 最大重传时间是 120s 重传次数为 151 保障了业务的可靠性TCP的重传存在原因就是为了保障TCP的可靠性，正是由于TCP存在重传的机制，那些基于TCP的业务应用在网络交互的过程中，不再担心由于丢包、包损坏等导致的一系列应用问题了。2 反映网络通讯的状况由于IP协议的不可靠性和网络系统的复杂性，少量的报文丢失和TCP重传是正常的，但是如果业务交互过程中，存在大量的TCP重传，会严重影响业务系统交互的效率，导致业务系统出现缓慢甚至无响应的情况发生。 一般而言，出现大量TCP重传说明网络通讯的状况非常糟糕，需要站在网络层的角度分析丢包和重传的原因。在实际的数据交互过程中，重传报文一般具有以下两个特征：一是TCP交互序列号突然下降； 二是其在TCP报头中的序列号、数据长度、应用数据等参数跟前面某TCP报文一致。 1 序列号突然下降（一般是TCP重传） 在TCP报文传输的过程中，因为其需要不断的交互应用数据，因此，TCP报文的序列号会不断的变大。 正常情况下，TCP序列号不会出现下降的情况，出现序列号下降，一般都是TCP的重传报文导致的。 如下图所示：在上图中，服务器端交互的TCP报文序列号从24481开始一直处于不断上升的趋势，但是服务器的第六个TCP报文序列号却突然下降为20161，这个情形，基本上可以肯定这第六个TCP报文是前面某个报文的重传报文。2 根据序列号、长度甚至应用数据等确认是哪一个报文的重传。 在数据交互过程中，一般情况下，TCP重传的报文跟传输中被丢弃的报文在序列号、数据长度、应用字段值上都是一样的，我们可以利用这个特征来确定某个具体的TCP报文是否是前面某个报文的重传。 下图是一个客户端存在重传的数据流图： 在上图中，我们看到客户端第三个报文和第四个报文的序列号（Seq）、下一个序列号（Next Seq）以及载荷长度都是一样的，那么我们可以肯定客户端的第四个报文是客户端第三个报文的重传。 现在很多的网络分析工具的专家诊断系统基本上都可以针对TCP重传直接告警，我们不需要在去深入分析这个过程了，为我们节省了大量的分析时间。为什么TCP存在重传 https://blog.51cto.com/woniu421/900010基础篇 | TCP连接的建立和断开受哪些系统配置影响？ https://time.geekbang.org/column/article/284912?utm_source=related_read&utm_medium=article&utm_term=related_readLinux TCP_RTO_MIN, TCP_RTO_MAX and the tcp_retries2 sysctl https://pracucci.com/linux-tcp-rto-min-max-and-tcp-retries2.html聊一聊重传次数https://perthcharles.github.io/2015/09/07/wiki-tcp-retriesTCP重传机制https://www.dazhuanlan.com/mofeia/topics/1357902TCP网络关闭的状态变换时序图https://coolshell.cn/articles/1484.htmlTCP 的那些事儿（上）https://coolshell.cn/articles/11564.htmlTCP 的那些事儿（下）https://coolshell.cn/articles/11609.html

TCP重传机制主要是为了防止网路包丢弃，重传的工作方式主要借助TCP头部中的序列号和确认号来决定是否重传，重传的触发方式主要由以下几种：

什么是超时重传？

发送方在发送数据时设置一个定时器，当超过指定时间后如果还没有收到接收方的ACK响应，就会重发数据包。

超时重传的发生场景

什么是RTT？什么是RTO？

RTT就是数据包的往返时间，RTO就是超时重传时间。

RTO的长短对数据包的重传有什么影响？

RTO如何设置？

RTO既不能过长也不能过短，略微大于RTT是最好的。但RTT会因为网络的变化而发生变化，所以在Linux系统中为了计算RTO，会对RTT进行两个采样：

RFC6289建议使用以下公式计算RTO：

上述表达式中，在linux中α = 0.125，β = 0.25，μ = 1，δ = 4，至于为啥是这些值，别问问就是前人大量的测试积累得出。

假设因为网络阻塞触发了超时，如何避免频繁重发加剧网络阻塞？

超时时间加倍，就是每当重传的时候，都会将下一次的超时时间设置为当前值的两倍，避免频繁重发导致网络更加阻塞。

超时重传的弊端是什么？

超时周期可能相对较长，重传的等待时间可能过长。

什么是快速重传？

快速重传不再以时间作为重传的标准，而是以数据作为重传的标准。

上述Seq2因为某些原因没有抵达接收方，但接收方已经收到了Seq3、4、5的数据包，并且回复了三次ACK2的数据包。发送端在收到三次ACK2的数据包以后，就会在超时定时器之前重传Seq2的数据包。

重传所有包还是重传丢失的包？

由于发送端并不知道三次ACK2的数据包是由发送方的哪几个数据包响应回来的（也就是Seq3、4、5），因此只重传Seq2还是要重传所有的数据包也是个问题。

根据TCP实现的不同，上述两种情况都可能存在。

SACK重传

SACK重传其实就是选择性重传，它是为了解决快速重传不知道需要重传哪些包的问题。

SACK是如何让发送方知道重传哪些包的？

TCP的选项字段增加一个SACK字段，接收方会将已经收到数据包序列号范围发送给发送方，这样发送方通过SACK信息就能找到丢失的数据包重传此数据包。

SACK的使用条件

SACK必须要发送方和接收方同时支持，在linux中可以通过net.ipv4.tcp_sack参数开启（Linux2.4以后默认开启）。

SACK可以让发送方准确的知道哪些数据包接收方没有收到，而D-SACK可以让发送方知道有哪些数据包被重复接收了。

D-SACK的优点是什么？

D-SACK如何让发送方知道ACK包丢失

上图中接收方收到了3000~3999的数据包，但回应的ACK发生了丢失，假设此时触发了超时重传，发送方会首先重传3000~3499的数据包，接收方在收到该包以后发现该包已经被接收过了，于是会回复一个SACK = 3000~3500告诉发送方该数据包已经被接受过了，因为ACK已经到4000了，所以这里是一个D-SACK。发送方在收到报文以后可以知道数据包没有丢，丢的只是ACK报文。

D-SACK如何判断数据包发送延时

上图中1000~1499的数据包被网络延迟，后续发送方收到了三个连续ACK 1000的报文触发了超时重传，重传以后，延时的网络包也抵达了接收方，此时接收方会回复一个SACK=1000~1500，因为ACK已经到了3000，所以这里是一个D-SACK，表示收到了重复的包。发送方收到了该ACK报文以后也可以判断出快速重传的原因是因为网络延迟。

如何开启D-SACK

在Linux下可以通过net.ipv4.tcp_dsack参数开启/关闭这个功能(Linux 2.4后默认打开)。

前面也说过，TCP的保序，可用通过ack和seq等数据确定。那么当有包在传输的过程中丢失的话，那么需要一个重传机制去保证可靠性。常见的重传机制： 超时重传 快速重传SACKD-SACK

那么超时重传的时候应该设置成多少呢？

这里就是涉及到一个概念：往返时延 RTT。

而超时重传时间RTO就必须是大于RTT的，但是也不能大太多，丢了半天才重发，性能效率就慢了。

但是RTO计算也没看起来那么简单，因为网络环境是复杂的，RTT可能随时在变，不是一个定值。

linux下需要 TCP 通过采样 RTT 的时间，然后进行加权平均，算出⼀个平滑 RTT 的值，而且这个值还是要

不断变化的，因为网络状况不不断地变化。除了采样 RTT，还要采样 RTT 的波动范围，这样就避免如果 RTT 有⼀个大的波动的话，很难被发现的情况。具体的计算公式很复杂，而且有很多经验值的地方，就不罗列了。

而且当触发到一次超时重传的时候，会将超时RTO设置翻倍，说明现在网络环境不好，需要延长下时间重传，别造成网络拥堵。但是超时时间太长，就会导致传输效率不高的问题，所以说下下一种方法，快速重传。

---