tcp的重传

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

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

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

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

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

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

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

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

一般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错误恢复特性有：TCP重传、TCP重复确认和快速重传。

重传数据包是TCP最基本的错误恢复特性之一，用来对付数据包的丢失。

数据包丢失可能原因有很多，如：出故障的应用程序、流量负载沉重的路由器或临时性的服务中断。

数据包层次上的移动速度非常快，而且数据包丢失通常都是暂时的，因此TCP能否检测到数据包丢失并恢复至关重要。

如何决定是否重传：

决定是否重传数据包的主要机制叫做：重传计时器，这个计时器负责维护一个重传超时（RTO--Retransmission timeout）的值。

当使用TCP传输一个数据包时，就启动重传计时器，当收到这个数据包的ACK应答时，计时器就停止。从发送数据包到接收ACK确认之间的时间被称为往返时间（Round-Trip time，RTT），若干个这样的时间平均下来，可计算出最终的RTO值。

一旦RTO值确定下来，重传计时器就被用于每个传输的数据包，以确定数据包是否丢失。

当报文发送之后，但接收方尚未发送TCP ACK报文，发送方假设源报文丢失并将其重传。重传之后，RTO值加倍；如果在2倍RTO值到达之前还是没有收到ACK报文，就再次重传。如果仍然没有收到ACK，那么RTO值再次加倍。如此持续下去，每次重传RTO都翻倍，直到收到ACK报文或发送方达到配置的最大重传次数。

最大重传次数取决于发送 *** 作系统的配置值。

默认情况下，Windows主机默认重传5次。大多数Linux系统默认最大15次，两种 *** 作系统都可配置。

TCP重传率是网络质量的体现，网络这块我们主要看 TCP重传率 ，这个基本在大点的公司都有这块监控。

TCP重传率=单位时间内TCP重传包数量/TCP发包总数

我们可以把 TCP重传率 视为 网络质量和服务器稳定性 的一个只要衡量指标。

还是根据我们的经验，这个TCP重传率越低越好，越低代表我们的网络越好，如果TCP重传率保持在0.02%（以自己的实际情况为准）以上，或者突增，就可以怀疑是不是 网络问题 了。

比如这张图一样，要是和心电图一样，基本上网络问题就没跑了。

一分钟理解TCP重传

https://mp.weixin.qq.com/s/f-lxycgqwZyHCZcPIpb_tg

谈谈Linux中的TCP重传抓包分析

https://cloud.tencent.com/developer/article/1464243

关于TCP重传问题的排查思路与实践

https://blog.csdn.net/wufaliang003/article/details/90664256

TCP重传率高的监控

https://blog.csdn.net/weixin_30648963/article/details/99459391

用zabbix 监控TCP重传率

https://mp.weixin.qq.com/s/iNvCU40qHyVJrku5K1cP-Q

TCP协议的深入学习和利用wireshark排查TCP通信的故障视频教程

https://edu.51cto.com/course/8385.html

网络协议 TCP/IP 视频教程全集

https://www.bilibili.com/video/BV1Pt41137w6?p=1

使用Wireshark抓包排查网络故障和分析TCP/IP协议

https://edu.51cto.com/course/15139.html

https://edu.51cto.com/courselist/index.html?q=wireshark

使用ss命令对tcp连接数和状态的监控性能优化

https://www.bbsmax.com/A/obzb2gL0zE

关于TCP重传的监控

https://blog.csdn.net/beeworkshop/article/details/103841211

https://github.com/alibaba/tsar

---