大家好，关于tcp超时重传时间很多朋友都还不太明白，今天小编就来为大家分享关于TCP重传时间如何设置的知识，希望对各位有所帮助！
本文目录
一、TCP超时重传机制的重传超时时间
1、如果底层 *** 的传输特性是可预知的，那么重传机制的设计相对简单得多，可根据底层 *** 的传输时延的特性选择一个合适的RTO，使协议的性能得到优化。但是TCP的底层 *** 环境是一个完全异构的互联结构。在实现端到端的通信时，不同端点之间传输通路的性能可能存在着巨大的差异，而且同一个TCP连接在不同的时间段上，也会由于不同的 *** 状态具有不同的传输时延。
2、因次，TCP协议必须适应两个方面的时延差异：一个是达到不同目的端的时延的差异，另一个是统一连接上的传输时延随业务量负载的变化而出现的差异。为了处理这种底层 *** 传输特性的差异性和变化性，TCP的重传机制相对于其他协议显然也将更为复杂，其复杂性主要表现在对超时时间间隔的处理上。为此，TCP协议使用自适应算法（Adaptive Retran *** ission Algorithm）以适应互联网分组传输时延的变化。这种算法的基本要点是TCP监视每个连接的性能（即传输时延），由此每一个TCP连接推算出合适的RTO值，当连接时延性能变化时，TCP也能够相应地自动修改RTO的设定，以适应这种 *** 的变化。
二、TCP超时/丢失重传
1、Nagle算法要求一条TCP连接上最多只有一个未被确认的报文，发送方发送一个TCP报文，接收方确认该报文，发送方再发送下一个报文，若发送方在一定时间内未收到确认，则再重发报文。相对来说Nagle算法相对简单且不容易出错，但却降低了 *** 的吞吐量，也增加了 *** 流量。
2、在实际的TCP实现中，接收方往往一次确认一批的TCP报文，且确认报文与接收方发往发送方的报文一同回复，以减少 *** 流量，从另一方面说也就允许发送方在前一报文未确认时，可以继续发送下一个报文，虽然这种实现提高了吞吐量，但却带来了另一个问题，即发送文如何确认报文被接收方正确接收?
3、TCP有两种方式来保证报文被正确接收：
4、1：发送端在一定时期内未收到报文确认，报文重发
5、2：接收端检测到某一报文丢失，重复发送ACK报文(3个以上)，以促使发送端重发丢失报文。这就是快速重传机制。
6、 通常，发送端会重传接收方未收到的报文，但不会重传已经被接收方收到但并未确认的包，然后接收方将收到的报文排序后进行一并确认，
7、如上图，由于某种原因，发送端发给接收端的数据包序号1025，丢失了序号为1的包(250839)
8、此时接收端对序号1进行了确认，发送端重发了序号1，此时接收端已经有了2484个字节，序号1中有1024个字节，序号1025中的1460个字节，接收端这时回复一个确认2485的AC包。
三、tcp超时重传时间的选择依据
1、TCP超时重传时间的选择依据主要是根据 *** 情况和数据包往返时间（RTT）来动态调整的。
2、TCP（传输控制协议）是一种面向连接的、可靠的、基于字节流的传输层通信协议。在TCP通信过程中，如果发送方在一个特定时间内未接收到接收方的确认（ACK），则会重传数据包。这个特定时间就是超时重传时间。
3、TCP超时重传时间的选择并不是随意的，而是根据 *** 情况和数据包往返时间（RTT）来动态调整的。RTT是指从发送方发送数据包开始，到接收到接收方的确认所需要的时间。TCP会根据这个RTT来估算 *** 的拥塞程度和传输效率，从而动态调整超时重传时间。
4、具体来说，TCP会维护一个平滑的RTT（SRTT）和一个RTT的偏差（RTTVAR），并根据这两个值来计算超时重传时间。当发送一个数据包时，TCP会记录下当前的发送时间，并在接收到确认时，用当前时间减去发送时间来更新SRTT和RTTVAR。如果在一个超时重传时间内没有接收到确认，则TCP会认为数据包丢失，并重传数据包。这个超时重传时间就是根据SRTT和RTTVAR计算出来的。
5、在实际应用中，TCP超时重传时间的选择还需要考虑其他因素，如 *** 带宽、延迟、丢包率等。例如，在 *** 拥塞的情况下，可能需要增加超时重传时间以避免频繁的重传；而在 *** 状况良好的情况下，可以适当减小超时重传时间以提高传输效率。此外，不同类型的应用程序和 *** 环境也可能需要不同的超时重传时间策略。例如，实时性要求较高的应用可能需要更短的超时重传时间，以确保数据的及时传输。
四、TCP 计时器
为了顺利完成TCP的操作,大多数TCP使用了至少4种计时器
重传计时器(Retran *** ession),持久计时器(Persistance),保活计时器(keep-alive)及时间等待(time-wait)
为了防止数据报丢失,当TCP发送一个报文时,就启动重传计时器,有2种情况:
1.若在计时器超时之前收到了特定报文的确认,则撤消这个计时器;
2.特定数据报在计时器超时前没有收到确认,则重传该数据报,并把计时器复位
要计算重传超时时间(RTO),首先需要知道往返时间(RTT-round trip time),计算RTT比较复杂
测量的RTT即发送一个数据报都收到对它的确认所需时间,记为MRTT(TCP在任何时刻只能对一个RTT测量)
平滑的RTT(Smoothed RTT)因为RTT对不同的往返有不同的数值,而且其起伏比较大,以致不能为重传超时做标准,所以需要平滑的RTT,记为SRTT它对和前一个SRTT加权平均
其他任意次测试-->SRTT=(1-α)SRTT+α*MRTT
α取值与现实无关,通常为1/8,即新的SRTT是7/8的旧SRTT和1/8的新的MRTT的和
大多数现实不仅使用SRTT,还计算RTT的偏差,记为DRTT,是基于SRTT和MRTT使用如下关系计算:
其他任意次测量后-->DRTT=(1-β)DRTT+β*|SRTT-MRTT|
RTO的数值基于平滑的往返时间及其偏差,大多数使用下面的公式:
在任意次测试后-->RTO=SRTT+4*DRTT
假如一个报文在传输期间没有被确认,因而有重传
当发送端收到对这个报文的确认时,它就无法知道该确认是对原来报文的确认,还是对重传报文的确认
新的RTT值要根据发送去时的时间来计算,即对于重传报文的计算要从重传报文发出时计时
Karn算法的解决 *** 是在计算新的RTT时不考虑重传报文的RTT
在发生重传现象时,那其RTO是多少?大多数TCP使用指数退避策略
要解开死锁,TCP为每一个连接使用一个持久计时器
当发送端TCP接收到rwnd=0的确认时,就启动持久计时器,当计时器截止时间到时,发送端TCP需要发送一个特殊的报文,叫做探测报文
该报文只有1字节,有序号,但无需确认
探测报文提醒接收端TCP:确认已丢失,必须重传
持久计时器截止时间设置为重传时间的数值,但是,如果没有收到从接收端回来的响应,则需要发送另外一个探测报文,并将持久计时器的值加倍和复位
如果结果和上面一样,发送端继续发送探测报文,直到其截止时间增大到阈值(通常为60s)为止
在这以后,发送端每60s发送一个探测报文,直到窗口重新打开
在某些实现中要使用keeplive timer来防止两个TCP之间出现长时间的空闲
比如客户端打开了服务器端的连接,传送了一些数据,然后就保持静默了
也许该客户端除了故障,在这种情况下,这个连接就永远处于打开状态
保活计时器的解决 *** 为,当服务器端收到客户端的信息时,就把计时器复位,超时通常设置2小时
若服务器2小时还没有收到客户的信息,就发送探测报文
若发送10个同样的报文(每个相隔75s)还没有收到响应,就认为客户端出了故障,终止这个连接
Time-wait(2MSL)计时器在终止连接时使用,在前面的状态转换篇曾在图中出现过
1.如果最后一个ACK报文丢失了,那么服务器TCP(它为最后的FIN设置了计时器)以为它的FIN丢失了,因而重传
如果客户端进入了closed状态,并在2MSL计时器超时之前就关闭了这个连接,那么它就永远无法收到这个重传的FIN报文,因而服务器端也就无法收到ACK,服务器就不能关闭这个连接
2MSL计时器可以使客户端等待足够长的时间,使得当ACK丢失了(一个MSL),可以等到下一个FIN的到来(另一个MSL)
如果在TIME-WAIT状态时一个新的FIN到达了,客户端就发送一个ACK,并重新启动这个2MSL计时器
2.从一个连接发来的重复报文可能会在下一个连接中出现
假定客户和服务器已关闭这个连接,经过短暂时间又使用相同套接字打开一个连接
这样的新连接叫久连接的化身(incarnation)
那么前一个连接的报文可能会到达新的连接中,同时被解释为新连接的报文
为了避免这个问题,TCP规定这个化身必须经过2MSL以后才出现
关于本次tcp超时重传时间和TCP重传时间如何设置的问题分享到这里就结束了，如果解决了您的问题，我们非常高兴。
