TCP/IP重传超时--RTO

标签: tcp ip rto | 发表时间:2011-10-28 16:39 | 作者:(author unknown) dennis
出处:http://www.orczhou.com
Shared by 子非鱼 安知余(褚霸)
可以用stap修改

概述:本文讨论主机在发送一个TCP数据包后,如果迟迟没有收到ACK,主机多久后会重传这个数据包。主机从发出数据包到第一次TCP重传开始,RFC中这段时间间隔称为retransmission timeout,缩写做RTO。本文会先看看RFC中如何定义RTO,然后看看Linux中如何实现。本文旨在分享:当遇到了TCP层问题改如何去查找、阅读文档,该如何去在Linux源码中寻求答案。

1. 起源

在分析MySQL Semi-sync故障时,我们用Tcpdump+Wireshark(感谢淘宝雕梁)抓住当时的网络包传送细节,观察到了一次TCP重传最终导致了Semi-sync超时:

第一次传输 13:55:11.893291 master => slave Binlog pos:319890197 重传: 13:55:12.094596 master => slave Binlog pos:319890197

看到两次传送间隔约201毫秒,即第一次传输201毫秒后,还没有收到ACK响应,TCP认为传输超时,开始重传。

疑问:host和host之间的RTT大约是0.5毫秒,为什么第一次重传需要等200毫秒?(我希望是<20ms)socket程序可以配置吗RTO吗?TCP有参数可配置RTO吗?

2. Google/书籍/RFC

翻开TCP/IP详解找到关于TCP Retransmission章节,较详细的介绍TCP的超时机制,书中是个概述,于是又找到RFC1122。

RFC1122的4.2.2.15和4.2.3.1都介绍了Retransmission Timeout的处理(说来惭愧,这是第一次阅读TCP相关RFC)。

RFC中搜索Retransmission发现RFC 793 1122 2988 6298都有对重传算法、和初次重传超时的描述。于是开始阅读这个四个RFC,耗时约2小时,了解了大致的重传超时算法。

3. RFC中如何计算RTO(Retransmission Timeout)
3.1 RFC-793如何计算RTO

概述:先根据该socket的RTT计算出SRTT(Smoothed Round Trip Time),然后根据一个最大、最小超时时间确定当前RTO。说明:srtt可以理解为“平滑化”的RTT,即在保持计算简单的情况尽量考虑历史RTT。

详细计算:SRTT = ( ALPHA * SRTT ) + ((1-ALPHA) * RTT)

基于SRTT,我们再来计算RTO:RTO = min[UBOUND,max[LBOUND,(BETA*SRTT)]]

UBOUND是RTO上线,ALPHA是平滑因子(smoothing factor, e.g., .8 to .9),BETA是一个延迟方差因子(BETA is a delay variance factor (e.g., 1.3 to 2.0))。

仔细看这两个公式大概就能理解了RTO的计算了。

这里对上面两个公式做一个简单的注释:公式1中计算SRTT,ALPHA越接近于0,则表示SRTT越相信这一次的RTT;越接近于1,则表示SRTT越相信上次统计的RTT。公式二给RTO分别设置了一个上限和下限。

3.2 RTO重传间隔是指数增加的

上面我们介绍的是初次重传时的RTO,如果重传后还没收到另一端的响应,下一次重传RTO则会指数增加,例如第一次重传RTO是1,之后分别2,4,8,16...。

3.3 RFC-2988和RFC-6298中的RTO计算

在RFC-2988和RFC-6298中又重新改进了RTO的计算方法,Linux中的实现即使参考RFC-2988。算法核心公式:

初始: SRTT <- R RTTVAR <- R/2 RTO <- SRTT + max (G, K*RTTVAR) where K = 4. 根据RTT计算SRTT: RTTVAR <- (1 - beta) * RTTVAR + beta * |SRTT - R'| SRTT <- (1 - alpha) * SRTT + alpha * R' 最后RTO: RTO <- SRTT + max (G, K*RTTVAR)
4. Linux中的RTO(Retransmission Timeout)

这里说的是RHEL5.4的2.6.18内核,RFC-2988实现参考net/ipv4/tcp_input.c中的tcp_rtt_estimator和tcp_set_rto。可以看到,在Linux中alpha=1/8,RTO最小为TCP_RTO_MIN。因为我们的系统中RTT总是很小,所以RTO取值总是能够取到TCP_RTO_MIN。

在看看TCP_RTO_MIN在Linux中的定义:

123#define TCP_RTO_MAX ((unsigned)(120*HZ)) 124#define TCP_RTO_MIN ((unsigned)(HZ/5))

(这里简单的介绍介绍一下HZ,HZ可以理解为1s,所以120*HZ就是120秒,HZ/5就是200ms。详细的:HZ表示CPU一秒种发出多少次时间中断--IRQ-0,Linux中通常用HZ来做时间片的计算,参考)

5. 其他:Linux中可配置重传参数

/proc/sys/net/ipv4/tcp_retries1 (integer; default: 3)

TCP尝试了3次(tcp_retries1默认3)重传后,还没有收到ACK的话,则后续每次重传都需要network layer先更新路由。

/proc/sys/net/ipv4/tcp_retries2 (integer; default: 15)

TCP默认最多做15次重传。根据RTO(retransmission timeout)不同,最后一次重传间隔大概是13到30分钟左右。如果15次重传都做完了,TCP/IP就会告诉应用层说:“搞不定了,包怎么都传不过去!”

6. 最后

回答前面的问题:即使RTT很小(0.8ms),但是因为RTO有下限,最小必须是200ms,所以这是RTT再小也白搭;RTO最小值是内核编译是决定的,socket程序中无法修改,Linux TCP也没有任何参数可以改变这个值。

好了,不容易。

广告:我们寻找靠谱的人 | 感谢作者

参考文献

1. RFC 1122 ... (在哪儿查找RFC) TCP协议相关的RFC:
RFC 675 - Specification of Internet Transmission Control Program, December 1974 Version
RFC 793 - TCP v4
RFC 1122 - includes some error corrections for TCP
RFC 1323 - TCP-Extensions
RFC 1379 - Extending TCP for Transactions—Concepts
RFC 1948 - Defending Against Sequence Number Attacks
RFC 2018 - TCP Selective Acknowledgment Options
RFC 2988 - Computing TCP's Retransmission Timer
RFC 4614 - A Roadmap for TCP Specification Documents
RFC 5681 - TCP Congestion Control

相关 [tcp ip rto] 推荐:

TCP/IP重传超时--RTO

- dennis - 一个故事@MySQL DBA
Shared by 子非鱼 安知余(褚霸). 概述:本文讨论主机在发送一个TCP数据包后,如果迟迟没有收到ACK,主机多久后会重传这个数据包. 主机从发出数据包到第一次TCP重传开始,RFC中这段时间间隔称为retransmission timeout,缩写做RTO. 本文会先看看RFC中如何定义RTO,然后看看Linux中如何实现.

tcp/ip调优

- Lucseeker - 在路上
在TCP/IP协议中,TCP协议提供可靠的连接服务,采用三次握手建立一个连接. 第一次握手:建立连接时,客户端发送syn包(syn=x)到服务器,并进入SYN_SEND状态,等待服务器确认;. 第二次握手:服务器收到syn包,必须确认客户的SYN(ack=x+1),同时自己也发送一个SYN包(syn=y),即SYN+ACK包,此时服务器进入SYN_RECV状态;.

TCP/IP分享——链路层

- Goingmm - 弯曲评论
在张国荣自尽8周年纪念日,也就是愚人节的前几十分钟,终于把第二章弄完了. 首席似乎不是特别有空,我就斗胆在这里自己发了,从前面2期的反响来看,相当热烈,我也是摆出一副要杀要剐,悉听尊便的架势,这可能是受最近流行霸气外露的影响,批评几句又伤不了皮毛,也影响不了我的工作和正常生活,只要给大家带来快乐,我就很开心,似乎历史上很多想法都是在争吵中诞生的.

TCP/IP中的TIME_WAIT状态

- - CSDN博客推荐文章
毫无疑问,TCP中有关网络编程最不容易理解的是它的TIME_WAIT状态,TIME_WAIT状态存在于主动关闭socket连接的一方. TIME_WAIT状态存在的理由:. TCP/IP协议就是这样设计的,是不可避免的. 1)可靠地实现TCP全双工连接的终止. TCP协议在关闭连接的四次握手过程中,最终的ACK是由主动关闭连接的一端(后面统称A端)发出的,如果这个ACK丢失,对方(后面统称B端)将重发出最终的FIN,因此A端必须维护状态信息(TIME_WAIT)允许它重发最终的ACK.

tcp/ip ,http,socket的关系

- - 行业应用 - ITeye博客
  物理层、数据链路层、网络层、传输层、会话层、表示层和应用层.   通过初步的了解,我知道IP协议对应于网络层,TCP协议对应于传输层,而HTTP协议对应于应用层,.   三者从本质上来说没有可比性,.   socket则是对TCP/IP协议的封装和应用(程序员层面上).   也可以说,TPC/IP协议是传输层协议,主要解决数据如何在网络中传输,.

TCP/IP三次握手和HTTP过程

- - 互联网 - ITeye博客
TCP/IP三次握手和HTTP过程.        原文地址:http://www.cnblogs.com/tiwlin/archive/2011/12/25/2301305.html. 手机能够使用联网功能是因为手机底层实现了TCP/IP协议,可以使手机终端通过无线网络建立TCP连接. TCP协议可以对上层网络提供接口,使上层网络数据的传输建立在“无差别”的网络之上.

TCP之三:TCP/IP协议中backlog参数(队列参数) - duanxz - 博客园

- -
TCP洪水攻击(SYN Flood)的诊断和处理》. TCP/IP协议中backlog参数》. TCP建立连接是要进行三次握手,但是否完成三次握手后,服务器就处理(accept)呢.   backlog其实是一个连接队列,在Linux内核2.2之前,backlog大小包括半连接状态和全连接状态两种队列大小.

XP TCP/IP Repair v2.1 - 修復您的網路連線

- Jeshuang - 虫二電氣診所
【檔案名稱】:XP TCP/IP Repair v2.1 - 修復您的網路連線. 【檔案大小】:332 KB(解壓後). 【作業系統】:Windows All. 【官方網站】:www.xp-smoker.com/. 【正體中文編譯】:丹楓(虫二電氣診所). 此軟體可以幫助您修復您的網路連線與甚至也許可以保護您的隱私權.

Linux内核TCP/IP参数分析与调优

- - Linux - 操作系统 - ITeye博客
转载于:http://www.itxuexiwang.com/a/liunxjishu/2016/0225/167.html?1456482565. 如下图展示的是TCP的三个阶段.1,TCP三次握手. SYN:(同步序列编号,Synchronize Sequence Numbers)该标志仅在三次握手建立的时候有效.

TCP/IP 必知必会的十个问题

- - IT瘾-dev
本文整理了一些TCP/IP协议簇中需要必知必会的十大问题,既是面试高频问题,又是程序员必备基础素养. TCP/IP协议模型(Transmission Control Protocol/Internet Protocol),包含了一系列构成互联网基础的网络协议,是Internet的核心协议. 基于TCP/IP的参考模型将协议分成四个层次,它们分别是链路层、网络层、传输层和应用层.