再谈TCP-rto时间的计算

最新推荐文章于 2025-06-24 20:26:01 发布
最新推荐文章于 2025-06-24 20:26:01 发布
阅读量2k 收藏 2
点赞数
CC 4.0 BY-SA版权
分类专栏： TCP 文章标签： TCP RTO
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_45490038/article/details/103074151
本文详细讨论了TCP的重传超时时间(RTO)计算方法，包括首次和非首次计算过程，以及RTO的更新策略。文章指出，RTO的计算必须基于未被重传的数据包，以避免时间戳误差导致的RTT低估。内核中的算法对此进行了平滑处理，对减小敏感而对增大不敏感。此外，文章还介绍了偏差值的维护和最大偏差的更新规则，确保RTO的准确性。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

文章目录

背景

在做可靠传输的弱网测试时，常常会发现因为一个报文的丢失导致发送端无法发送新数据，比如窗口大小是10，1-9已经被收到，但是0号报文一直丢包，而重传的间隔越来越大，导致有一段时间没有任何报文的收发，直到下次0号报文的重传。这里的原因就在于rto的时间被估值太大，导致重传间隔太久，下面一段话摘自linux内核代码，

	/*	The following amusing code comes from Jacobson's
	 *	article in SIGCOMM '88.  Note that rtt and mdev
	 *	are scaled versions of rtt and mean deviation.
	 *	This is designed to be as fast as possible
	 *	m stands for "measurement".
	 *
	 *	On a 1990 paper the rto value is changed to:
	 *	RTO = rtt + 4 * mdev
	 *
	 * Funny. This algorithm seems to be very broken.
	 * These formulae increase RTO, when it should be decreased, increase
	 * too slowly, when it should be increased quickly, decrease too quickly
	 * etc. I guess in BSD RTO takes ONE value, so that it is absolutely
	 * does not matter how to _calculate_ it. Seems, it was trap
	 * that VJ failed to avoid. 8)
	 */

可以看出内核本身也认为这个算法已经有些老土了，应该减小rto的时候却在增大，应该快速增加rto的时候却很慢，但人们似乎并不在乎rto的这点偏差。

最低0.47元/天 解锁文章

200万优质内容无限畅学
Linux下超时重传时间(RTO)的实现探究
tech_meizu的博客
03-02 1万+
最近出现了网络超时的问题要排查，大致按照如图思路去排查 1.排除代码逻辑问题，TCP相关可能的BUG，内核参数等问题； 2.排查KVM问题时，在同一个宿主机的不同KVM上，复现了超时问题。 发现大部分异常连接时长都在1s左右，通过抓包分析，可以看到这部分的包被重传了，重传的时间固定为1秒。 这里重传时间为什么是1秒呢，相关的标准和实际实现是怎样的呢？ 本文主要讨论的就是这部分内容（基
什么是恢复时间目标(RTO)
10-22
恢复时间目标(recovery time objective，RTO)是指在故障或灾难发生之后，一台电脑、系统、网络或应用程序停止工作的最高可承受时间。恢复时间目标是一项职能，用于评估灾难扰乱正常运营的程度和灾难在单位时间里所造成的收入损失。这些因素又取决于受影响的设备和应用程序。恢复时间目标(RTO)是以秒、分钟、小时或天数来衡量的，它是灾难恢复规划(DRP)中的一个重要考虑因素。
TCP/IP重传超时--RTO
Hello World!
02-22 1489
转载 http://www.orczhou.com/index.php/2011/10/tcpip-protocol-start-rto/ TCP/IP重传超时--RTO 2011-10-27  |  20:19分类：Linux,技术细节  |  标签：Linux、retransmission timeout、RTO、TCP  |  1,797 views 概述：本文讨论
RTT、RTO 与超时重传机制
最新发布
陈子青的博客
06-24 389
RTT 是基础测量数据，RTO 是基于 RTT 推导出的超时判定标准。TCP 使用超时重传机制确保即使在不可靠的网络环境下也能保证数据最终传达，配合快速重传与拥塞控制提升整体性能与稳定性。😀 关注 @公众号 程序员陈子青，获取更多 C++ 技术支持。
TCP协议中RTO的计算
热门推荐
JXH_123的专栏
05-28 1万+
TCP协议中RTO的计算
计算机网络 RTO超时重传时间
weixin_63162063的博客
07-13 780
RTO在TCP的实现中非常重要，因为它直接影响到TCP在面对丢包时的重传策略。因此，RTO的选择需要考虑到网络的延迟和抖动情况，以及应用的实时性需求，RTO是TCP协议中的一个动态调整参数，通过估算网络往返时间来决定数据重传的时机，是TCP实现可靠数据传输的重要保证之一。RTO（Retransmission TimeOut，重传超时时间）是TCP协议中用于控制重传机制的重要参数。RTO应当略大于TCP报文段的平均往返时延RTT，一般可取RTO = 2RTT，也可以根据情况人为调整RTO。
超时重传时间RTO的确定
DongZhaoCheng
02-23 2751
超时重传时间的确定 超时重传时间RTO：TCP数据报文段发出后，经过RTO的时间没有收到其确认报文，就会重新发送该报文段 往返时间RTT：TCP数据报文段发出到收到该报文的确认报文所经历的时间 通常：超时重传时间RTO要略大于往返时间RTT，但由于实际网络环境的复杂性，RTT的测量并没有那么容易，RTT的测量有可能偏大或偏小。 一、实际网络中使用的往返时间RTT是由平滑往返时间RTTSRTT_SRTTS​度量的 在实际的网络中，通常不直接使用测量得到的RTT样本，而是使用加权平均往返时间RTTSRT
TCP超时时间的计算
renrenhappy的专栏
10-09 5685
转：http://blog.csdn.net/metasearch/archive/2008/03/07/2157017.aspx超时重传是TCP协议保证数据可靠性的另一个重要机制，其原理是在发送某一个数据以后就开启一个计时器，在一定时间内如果没有得到发送的数据报的ACK报文，那么就重新发送数据，直到发送成功为止。1.超时超时时间的计算是超时的核心部分，TCP要求这个算法能大致估计出当前的网络状况，虽然这确实很困难。要求精确的原因有两个：(1)定时长久会造成网络利用率不高。(2)定时太短会造成多次重传，使得
低时延环境下的TCP RTO设置
dillanzhou的博客
07-04 2911
TCP连接的可靠传输依靠的是数据确认与重传机制。当发送方发送的数据在一定时间内没有得到对方的确认时，发送方就会认为发送的数据丢失而触发重传。这个等待的时间长度就是RTO（Retransmission TimeOut）。当然在快速重传等机制的作用下，很多情况下数据重传不需要真正等待RTO时间这么久，但在很多场景特别是单报文交互式的场景下，RTO仍然是报文重传的主要触发方式。 在RFC6298中，规定了RTO的计算方法。从原理上说，RTO是和TCP连接两端的报文往返交互时延（RTT）相关的，可以认为是RTT加
TCP F-RTO浅析
TCP/IP
01-24 1万+
F-RTO为了解决一个问题，RFC5682最开头有说： It has been pointed out that the retransmission timer can expire spuriously and cause unnecessary retransmissions when no segments have been lost [LK00, GL02, LM03]. After a spurious retransmission timeout, the late acknowled
数据中心的 TCP-Delay ACK 与 RTO, RACK
TCP/IP
02-12 7871
receiver 发送了多少 Delayed ACK，sender 预判了多少 Delayed ACK，如果这两个值均足够大且比值接近 1，就直接采用上述算法，若 receiver 稀有发送 Delay ACK，同时 sender 也鲜有收到 Delay ACK，则可直接去除 MIN_RTT 限制，大不了就虚假超时，频度不高影响就不大，相比增加逻辑复杂性，直接去掉限制更划算。同时，因为捎带 ACK 的主机时延不确定，要把捎带 ACK 排除掉，如果双向传输，我这个方法会导致 RTT 样本过少。
linux php超时时间设置,Linux下超时重传时间(RTO)的实现探究_PHP教程
weixin_42303079的博客
03-16 772
Linux下超时重传时间(RTO)的实现探究最近出现了网络超时的问题要排查，大致按照如图思路去排查1.排除代码逻辑问题，TCP相关可能的BUG，内核参数等问题;2.排查KVM问题时，在同一个宿主机的不同KVM上，复现了超时问题。发现大部分异常连接时长都在1s左右，通过抓包分析，可以看到这部分的包被重传了，重传的时间固定为1秒。这里重传时间为什么是1秒呢，相关的标准和实际实现是怎样的呢？本文主要讨论...
TCP 可靠传输 超时重传时间调整 RTO 重传定时器的计算
小楼一夜听春雨，深巷明朝卖杏花
07-09 1298
每次发一个段，都有一个计时，什么时候发的，超时之后自动重传，那么这个超时时间的选择也是需要调整的，也得判断一下多长时间为超时。发送了一个tcp的段，在规定的时间内没有收到确认，那么这个段就自动的重发。重传超时的时间也需要动态的调整，也需要进行判断。TCP往返传输时间（RTT） 的测量可以采用两种方法：（1）TCP Timestamp选项（tcp首部的选项）（2）重传队列中数据包的TCP控制块（b计算机和a计算机通信，发起一个建立连接的请求，这边给你一个响应，一去一回就知道往返时间了）可以看到抓的包是有时间标
实现较低的计时器粒度以重传TCP（RTO）：时间轮算法如何减少开销
RToax
10-14 783
使用重传计时器来实现较低粒度的一种方法是使用TCP的快速计时器（200毫秒），该计时器可以默认为50毫秒而不是200毫秒。这种方法的缺点是以较高的速率处理扫描所有协议控制块（PCB）的开销。PCB是保存连接控制信息的内部结构。本文介绍了一种基于计时器轮算法实现TCP重传计时器的替代方法。
TCP RTT与TCP RTO关系详解
meihualing的专栏
03-13 4272
TCP RTT， TCP RTO
tcp中使用的定时器
weixin_38184628的博客
02-12 2138
定时器的使用场景主要有两种。（1）周期性任务这是定时器最常用的一种场景，比如 tcp 中的 keepalive 定时器，起到 tcp 连接的两端保活的作用，周期性发送数据包，如果对端回复报文，说明对端还活着；如果对端不回复数据包，就会判定对端已经不存在了；再比如分布式系统中，各个组件之间的心跳报文也是定时发送来维护组件之间的状态。（2）兜底功能一些不立即执行的任务的时间底线。
5.8.6 TCP可靠传输（二）超时重传机制
nytcjsjboss的博客
07-04 1739
从以上我们可以看出往返时延的测量实现起来还是比较复杂的，发出的一个报文段如果超时重发的时间到了还没有收到确认，于是又发出了一个报文段，但是后来收到了一个确认报文段，这个时候问题就来了，我们如何判定此报文段是对原来的报文段的确认还是对重传报文段的确认呢？为了确定合适的往返时延RTT，在传输层方面是非常困难的一件事，因为TCP的下层是一个因特网的网际互联环境，发送的报文段可能要经过一个高速以太网，但也有可能是多个低速率的广域网，并且数据报所选择的路由还可能随时发生变化，所以TCP采用了一种自适应的算法。
TCP中的RTT和RTO
yizhiniu_xuyw的专栏
11-12 9022
一、RTT和RTO的概念 TCP作为一个面向连接的、可靠的传输协议，内部实现了一个重传计时器来保证数据能传输到对方。每发送一个数据包，就给这个数据设置一个重传计时器。如果在计时器超时之前收到了针对这个数据包的ack，就取消这个计时器。如果没有收到，则开始发起重传。计时器超时的时间被称为RTO，这个时间的确定取决于RTT。 关于两者详细的解释： RTT(Round Trip Time)：一个连接的往返时间，即数据发送时刻到接收到确认的时刻的差值； RTO(Retransmission Time Out
mptcp联合拥塞控制算法 balia代码总结
weixin_40182062的博客
09-07 1406
static int rate_scale_limit = 25; static int alpha_scale = 10; static int scale_num = 5;//这里static修饰的都是全局变量，而且不允许其他文件引用 struct mptcp_balia { u64 ai; u64 md; bool forced_update; }; 这里表示一个结构体（相当于java中的类）实现了一个拥塞控制接口，里面有私有的成员变量 //static inline表示这是一个内嵌函数，不
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值