- 综合排序
- 最热优先
- 最新优先
- 来自专栏火丁笔记
SYN和RTO
不过在 SYN 握手阶段，网络连接还没有建立起来，如果此时发生丢包，那么因为系统没有可以参照的 RTT（Round-Trip Time），所以此时只能给出系统缺省设置的 RTO： #define TCP_RTO_MAX ); mod_timer(&req->rsk_timer, jiffies + timeo); return; 可见 RTO 的最大值是 120 秒，最小值是 200 毫秒，在连接建立前的初始值是 1 秒，如果经过多次重传，每次 RTO 的值翻倍，但最大不得超过 120 秒： 第 1 次重传：超时时间是 2 的 0 次方，也就是 1 秒。 还有一点需要说明的是，在建立连接后，因为目前网络都很快，所以大部分连接的 RTO 都会接近 TCP_RTO_MIN，也就是 200ms，可以通过「ss -int」命令来确认。 关于超时重传还有很多细节需要考虑，下面列出一些资料： TCP/IP重传超时–RTO RTO对tcp超时的影响 linux下超时重传时间(RTO)的实现探究 RTO的计算方法(基于RFC6298和Linux
1.1K40编辑于 2021-12-14 - 来自专栏阿牛的牙
RTT & RTO
RTO（Retransmission TimeOut） 为了防止数据报丢失,当TCP发送一个报文时,就启动重传计时器,有2种情况: 1.若在计时器超时之前收到了特定报文的确认,则撤消这个计时器
2.2K20编辑于 2022-09-07 - 来自专栏bisal的个人杂货铺
RPO和RTO是什么？
在衡量系统高可用的时候，我们经常能看到几个专业词汇，例如RPO和RTO，像OceanBase号称可以做到RPO=0，RTO<30s，RPO和RTO代表了什么？ RTO，Recovery Time Objective，他是指灾难发生后，从IT系统当机导致业务停顿之时开始，到IT系统恢复至可以支持各部门运作、恢复运营之时，此两点之间的时间段称为RTO。 可以看出来，RTO和RPO服务于不同的目标，RTO涉及应用程序和系统，但主要描述应用程序停机时间的限制。RPO主要与失败事件后丢失的数据量有关。 因此，从客户的角度，如果某个服务节点发生了故障，肯定希望数据不丢(RPO=0)，而且能尽快恢复(RTO 越小越好)。 因此，这种技术不仅能保证RPO=0，而且大大减小了RTO，相比传统“主从复制”技术来说可以提供更强大的高可用能力。
18.4K20发布于 2021-09-06 - 来自专栏金融级分布式数据库TDSQL
十年验证,腾讯数据库RTO
为帮助开发者更好地了解和学习分布式数据库技术，2020年3月，腾讯云数据库、云加社区联合腾讯TEG数据库工作组特推出为期3个月的国产数据库专题线上技术沙龙《你想了解的国产数据库秘密，都在这！》，邀请数十位鹅厂资深数据库专家每周二和周四晚上在线深入解读TDSQL、CynosDB/CDB、TBase三款鹅厂自研数据库的核心架构、技术实现原理和最佳实践等。三月为TDSQL专题月，本文将带来直播回顾第二篇《破解分布式数据库的高可用难题：TDSQL高可用方案实现》。
2.8K42发布于 2020-03-25 - 来自专栏架构专题
RTO, RPO是啥？是割韭菜的意思么？
RTO = Recovery Time Objective = 恢复时间目标 RPO = Recovery Point Object = 恢复点目标 其差别，一个是Time、一个是Point。 如果你的业务能够忍受30分钟之内启动起来，那么RTO就等于30分钟。 再比如，你的数据库当机了，30分钟后恢复了。如果你的业务能够忍受丢失最后2分钟的数据，那么你的RPO就是2分钟。 值得注意的是，任何宣称RTO=0和RPO=0的厂商，都是在吹牛皮。 单机服务 对于单机服务来说，从故障到恢复正常服务，它的间隔时间不可能是0。 所以RTO不会等于0。 但RPO倒是可以做到逼近0损失的。因为目前的数据库服务，大多数都会写一份预写日志来防止异常发生。 故障处理的间隔时间就是RTO的值。 在这种情况下，同样有丢失数据的风险。5个节点，根据NWR策略，需要写入3个才算成功。
2.1K40编辑于 2021-12-21 《打破固有认知：RTO对RTT说“不”的底层逻辑》
RTO（重传超时时间）与RTT（往返时间）的关系，看似只是简单的数值关联，实则藏着网络通信最深刻的生存逻辑——RTO从不甘心成为RTT的固定倍数。 若简单将RTO设为RTT的固定倍数，相当于用静态的尺子去丈量动态的河流。假设某条链路的平均RTT是100ms，固定3倍的RTO便是300ms。 当RTT出现小幅波动时，RTO会微调自身数值；若遇到剧烈波动，它会快速放大安全边际。这种动态调整机制，让RTO既能在网络平稳时缩短等待时间以提升效率，又能在网络动荡时延长等待时间以减少误判。 而适度延长RTO导致的延迟，往往可以通过后续的快速重传机制弥补。TCP的设计者深谙这种成本差异。他们让RTO在计算时，始终偏向“保守容错”而非“激进效率”。 固定倍数的RTO，会打破这种精妙的平衡——在网络波动较大的场景中，要么因过于激进而引发重传风暴，要么因过于僵化而错失及时重传的时机，随着网络技术的发展，RTO的计算逻辑也在与时俱进。
19100编辑于 2025-07-13技术干货｜一行配置让你的 Apache Kafka RTO 缩短一半
前言：高可用不是选项，而是底线什么是RTO？在深入讨论技术细节之前，我们需要先对齐一个核心指标：RTO(RecoveryTimeObjective，恢复时间目标)。 对于运维团队来说，RTO就是从“系统报警”到“业务止损”之间的生死时速。为什么Kafka的RTO至关重要？在当今的架构中，ApacheKafka已经成为了基础设施的“中枢神经”。 RTO瓶颈分析：服务端与客户端的时间差在满足上述可用性前提的情况下，当一台Broker宕机时，RTO的长短取决于服务端恢复与客户端感知之间的时间差。 这一设计彻底解耦了RTO与故障规模的关联，通过重构容灾恢复流程，带来两个根本性优势：任意存活节点均可接管任意Partition；RTO与故障节点数量解耦，趋于恒定。 结论：RTO与集群规模解耦综合上述流程，AutoMQ在单点或多点故障场景下，端到端RTO始终稳定在小于30秒区间。更重要的是，这一RTO表现不随集群规模扩大而恶化。
19910编辑于 2026-02-25- 来自专栏TopSemic嵌入式
太赫兹领域重大突破，我国成功研制1THz频率RTO辐射源
突破封锁，我国在太赫兹领域实现重大突破 就在上周，中电科旗下的网络通信研究院，发布了一个重大的消息：经过两年刻苦攻关，在国内首批实现了太赫兹RTO辐射源1THz频率突破。 太赫兹振荡器（RTO），是一种新型、可在室温下工作、超小型的太赫兹波源，也是目前频率最高的固态电子学太赫兹波源。 据报道，国际上RTO的最高震荡频率可以做到1.98THz,网络通信研究院的这一成果大大地缩小了我们和世界领先水平地差距。 ? RTO加载透镜实物 太赫兹，被认为是未来改变世界的十大技术之一，欧美各国都在太赫兹领域，做出重要的战略部署。它的应用前景非常广泛，比如在无损成像，通讯等领域，都会带来革命性的变化。 2.
1.2K30发布于 2021-05-31 中科热备万能备份一体机分级数据保护，低成本实现不同 RPO&RTO
核心系统（如医疗HIS、制造业MES）往往要求RPO（恢复点目标）趋近于零、RTO（恢复时间目标）分钟级，以确保业务连续性；而辅助系统（如OA、邮件）则可容忍小时级的数据恢复。 医疗行业：生命数据零丢失的守护者某三甲医院部署万能备份一体机后，构建了分级保护体系：HIS系统：通过实时复制+双活容灾，RPO=0、RTO<2分钟，保障挂号、处方核心业务连续性。
30310编辑于 2025-09-18- 来自专栏7DGroup
混沌工程之ChaosMesh使用之四模拟网络Duplicate包
如果未收到ACK，发送方认为报文丢失并重传，同时RTO加倍；如果2倍RTO之后还没收到ACK，则再次重传。 但也不排除有些人想看明白RTO的计算逻辑。那就接着看。 也许你会问RTO是多长时间？ static inline void tcp_bound_rto(const struct sock *sk) { if (inet_csk(sk)->icsk_rto > TCP_RTO_MAX) inet_csk(sk)->icsk_rto = TCP_RTO_MAX; } 以上就是RTO的计算逻辑。 有没有设置最小RTO的函数？
87240发布于 2021-07-14 - 来自专栏解Bug之路
解Bug之路-记一次对端机器宕机后的tcp行为
icsk->icsk_rto = min(icsk->icsk_rto << 1, TCP_RTO_MAX); inet_csk_reset_xmit_timer(sk, ICSK_TIME_RETRANS +(boundary - linear_backoff_thresh) * TCP_RTO_MAX; 即(TCP_RTO_MIN=200ms,TCP_RTO_MAX=120s) timeout = 那么，重传最终超时的上界就是1044.6s 最终结论: 重传最终超时的上下界是: [924.6,1044.6] 用不同的rto计算下最终超时 由上面代码可知，重传rto是不停的*2,一直到TCP_RTO_MAX = rto; if (sum > 924.6) { break; } rto = rto * 2; rto = rto < 120 ?
3K30发布于 2018-09-28 中科热备万能备份一体机分级数据保护，低成本实现不同 RPO&RTO
核心系统（如医疗HIS、制造业MES）往往要求RPO（恢复点目标）趋近于零、RTO（恢复时间目标）分钟级，以确保业务连续性；而辅助系统（如OA、邮件）则可容忍小时级的数据恢复。 医疗行业：生命数据零丢失的守护者某三甲医院部署万能备份一体机后，构建了分级保护体系：HIS系统：通过实时复制+双活容灾，RPO=0、RTO<2分钟，保障挂号、处方核心业务连续性。
45810编辑于 2025-07-03- 来自专栏centosDai
解Bug之路-记一次对端机器宕机后的tcp行为
+(boundary - linear_backoff_thresh) * TCP_RTO_MAX; 即(TCP_RTO_MIN=200ms,TCP_RTO_MAX=120s) timeout = ( 计算下最终超时 由上面代码可知，重传rto是不停的*2,一直到TCP_RTO_MAX(120s)为止,阅读linux代码可知,在笔者的线上情况下,初始rto=srtt>>3 + rttvar(TCP_RTO_MIN break; } rto = rto * 2; rto = rto < 120000 ? rto=215.01999999998634,timeout=939965.459999986 rto=215.02999999998633,timeout=939975.689999986 rto =940026.839999986 这样，基本就能基本确定在宕机的时候，用的rto是215了 题外话: 之前博客里面笔者想当然的将rto认为成rtt，导致之前的模拟程序在rto的初始值没有加上200ms
1.2K20发布于 2021-05-21 - 来自专栏centosDai
从linux源码看socket(tcp)的timeout
(sk)->icsk_rto, TCP_RTO_MAX); return 0; } 又上面代码可知，在tcp_connect设置了重传定时器之后return回了tcp_v4_connect再return (sk, ICSK_TIME_RETRANS, inet_csk(sk)->icsk_rto, TCP_RTO_MAX); 其重传定时器的回掉函数为tcp_retransmit_timer: void = icsk_rto * 2,由于syn阶段，所以isck_rto不会由于网络传输而改变 // 重传的时候会以1,2,4,8指数递增 icsk->icsk_rto = min(icsk->icsk_rto << 1, TCP_RTO_MAX); // 重设timer inet_csk_reset_xmit_timer(sk, ICSK_TIME_RETRANS, icsk->icsk_rto, TCP_RTO_MAX unsigned int rto_base = syn_set ? TCP_TIMEOUT_INIT : TCP_RTO_MIN; ......
2.3K20发布于 2021-05-20 - 来自专栏centosDai
解Bug之路-记一次对端机器宕机后的tcp行为
+(boundary - linear_backoff_thresh) * TCP_RTO_MAX; 即(TCP_RTO_MIN=200ms,TCP_RTO_MAX=120s) timeout = ( 计算下最终超时 由上面代码可知，重传rto是不停的*2,一直到TCP_RTO_MAX(120s)为止,阅读linux代码可知,在笔者的线上情况下,初始rto=srtt>>3 + rttvar(TCP_RTO_MIN break; } rto = rto * 2; rto = rto < 120000 ? rto=215.01999999998634,timeout=939965.459999986 rto=215.02999999998633,timeout=939975.689999986 rto =940026.839999986 这样，基本就能基本确定在宕机的时候，用的rto是215了 题外话: 之前博客里面笔者想当然的将rto认为成rtt，导致之前的模拟程序在rto的初始值没有加上200ms
1.2K00发布于 2021-05-23 - 来自专栏Vamei实验室
协议森林11 涅槃 (TCP重新发送)
这个计时等待的时间叫做重新发送超时时间(RTO, retransmission timeout)。 RTO：沙漏中沙子的多少 发送方应该在等待多长时间之后重新发送呢？这是重新发送的核心问题。 另一方面，如果RTO时间过长，那么当TCP片段已经实际丢失的情况下，发送方不能及时重新发送，会造成网络资源的闲置。所以，RTO必须符合当前网络的使用状况。 网络状况越好，RTO应该越短；网络状况越差，RTO应该越长。 RTT: 往返时间 TCP协议通过统计RTT，来决定合理的RTO。 RTO = mean + 4 std (上述算法有多个变种，根据平台不同有所变化) 平均值反映了平均意义上的RTT，平均往返时间越大，RTO越大。另一方面，标准差越大也会影响RTO。 因此要设置更长的RTO，以应对不稳定的网络状况。
1K60发布于 2018-01-18 - 来自专栏速入大数据
别再说“多活一份数据就安全了”：云上灾备的真相，是你根本没想清楚 RTO RPO
别再说“多活一份数据就安全了”：云上灾备的真相，是你根本没想清楚RTO/RPO说句大实话——绝大多数团队做灾备，其实是在“心理安慰”，而不是在做“真正可用的系统设计”。 很多人一上来就说：“我们做了跨区复制，很安全”“我们有备份，没问题”但你要真问一句：RTO是多少？RPO是多少？极端情况下怎么恢复？十有八九，答不上来。 今天这篇，我们就把“云上灾备+跨区复制+RTO/RPO设计”这件事，一次聊透。 →就近访问→多区域同时服务特点：RTO≈0RPO≈0架构极复杂一句话总结：灾备不是技术问题，是“你愿意花多少钱”的问题。 四、RTO/RPO如何落地？不是喊口号很多人PPT写得很好，但系统一挂，全线崩。为什么？
18310编辑于 2026-03-25 - 来自专栏小狼的世界
【云+社区年度征文】RTO/RPO驱动的系统可靠性架构设计
[image-20201201182841360.png] RTO RTO(Recovery Time Objective)是恢复时间目标，是业务发展可容许的服务中断时间目标。 如果故障恢复的时间超过了RTO目标，业务会受到很严重的冲击。 制定RTO目标，是指导我们在日常运维中，无论遇到什么样的故障，所有的运维工作和应急措施都以在小于RTO的时间内恢复业务为目标。 RTO数值越小，代表系统的业务恢复能力越强，同时也意味着投入大量资金。提升RTO的技术也随着时代的发展有过一些变化，个人印象中在互联网兴起之前常用技术主要是主备切换，各厂商之间拼的还是服务的稳定性。 这种模式能够提供最好的RTO和RPO指标，同时实现起来代价也是最高的。
2.3K10发布于 2020-12-03 - 来自专栏解Bug之路
从linux源码看socket(tcp)的timeout
(sk)->icsk_rto, TCP_RTO_MAX); return 0; } 又上面代码可知，在tcp_connect设置了重传定时器之后return回了tcp_v4_connect再return (sk, ICSK_TIME_RETRANS, inet_csk(sk)->icsk_rto, TCP_RTO_MAX); 其重传定时器的回掉函数为tcp_retransmit_timer: void = icsk_rto * 2,由于syn阶段，所以isck_rto不会由于网络传输而改变 // 重传的时候会以1,2,4,8指数递增 icsk->icsk_rto = min(icsk->icsk_rto << 1, TCP_RTO_MAX); // 重设timer inet_csk_reset_xmit_timer(sk, ICSK_TIME_RETRANS, icsk->icsk_rto, TCP_RTO_MAX unsigned int rto_base = syn_set ? TCP_TIMEOUT_INIT : TCP_RTO_MIN; ......
5.6K20发布于 2020-01-15 - 来自专栏cwl_Java
速读原著-TCP/IP(往返时间测量)
该算法在给定这个随RT T的变化而变化的平滑因子的条件下， RFC 793推荐的重传超时时间RTO（Retransmission Ti m e O u t）的值应该设置为 RTO = R 这里的 是一个推荐值为 在往返时间变化起伏很大时，基于均值和方差来计算 RTO，将比作为均值的常数倍数来计算 RTO能提供更好的响应。 在[Jacobson 1988]中的图5和图6中显示了根据RFC 793计算的某些实际往返时间的 RTO和下面考虑了往返时间的方差所计算的 RTO的比较结果。 A和D均被用于计算下一个重传时间（ RTO）。增量g起平均作用，取为1 / 8（0 . 1 2 5）。偏差的增益是h，取值为0 . 2 5。当RT T变化时，较大的偏差增益将使 RTO快速上升。 并且，由于数据被重传， RTO已经得到了一个指数退避，我们在下一次传输时使用这个退避后的 RTO。对一个没有被重传的报文段而言，除非收到了一个确认，否则不要计算新的RTO。
1.3K30发布于 2020-03-13
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号