RTO

linux下超时重传时间(RTO)的实现探究

原创内容,转载请注明出处

Posted by Weakyon Blog on December 1, 2015

最近出现了网络超时的问题要排查,大致按照如图思路去排查

分层图

排除了代码逻辑问题,TCP相关可能的BUG,内核参数等问题后

在排查KVM问题时,在同一个宿主机的不同KVM上,复现了超时问题。

发现大部分异常连接时长都在1s左右,通过抓包分析,可以看到这部分的包被重传了,重传的时间固定为1秒。

这里重传时间为什么是1秒呢,相关的标准和实际实现是怎样的呢?

本文主要讨论的就是这部分内容(基于centos的2.6.32-358)


RFC标准

超时重传时间(RTO)是由当前网络状况(RTT),然后根据一个算法来决定。这部分相关内容《TCP/IP详解卷1》中有提到,但是已经过时了。

去RFC查了下,重传超时相关最新的是RFC6298,他更新了RFC1122并且废弃了RFC2988

稍微介绍一下其中内容,有兴趣的可以点进去看

RFC6298

1 重申了RTO的基本计算方法:

首先有个通过时钟得到的时间参数RTO_MIN

初始化:

第一次计算:

以后的计算:

RTO的最小值建议是1秒,最大值必须大于60秒

2 对于同一个包的多次重传,必须使用Karn算法,也就是刚才看到的双倍增长

另外RTT采样不能使用重传的包,除非开启了timestamps参数(利用该参数可以准确计算出RTT)

3 当4*RTTVAR趋向于0时,得到的值必须向RTO_MIN时间靠近

经验上时钟越准确越好,最好误差在100ms内

4 RTO计时器的管理

(1)发送数据(包括重传时),检查计时器是否启动,若没有则启动。当收到该数据的ACK时删除计时器

(2)使用RTO = RTO * 2的方式进行退避

(3)新的FALLBACK特性:当计时器在等待SYN报文时过期,且当前TCP实现使用了小于3秒的RTO,那么该连接对的RTO必须被重设为3秒,重设的RTO将用在正式数据的传输上(就是三次握手结束以后)


对linux的实际实现进行抓包分析

三次握手的syn包发送

01:00:00.129688 IP 172.16.3.14.1868 > 172.16.10.40.80: Flags [S], seq 3774079837, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
01:00:01.129065 IP 172.16.3.14.1868 > 172.16.10.40.80: Flags [S], seq 3774079837, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
01:00:03.129063 IP 172.16.3.14.1868 > 172.16.10.40.80: Flags [S], seq 3774079837, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
01:00:07.129074 IP 172.16.3.14.1868 > 172.16.10.40.80: Flags [S], seq 3774079837, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
01:00:15.129072 IP 172.16.3.14.1868 > 172.16.10.40.80: Flags [S], seq 3774079837, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
01:00:31.129128 IP 172.16.3.14.1868 > 172.16.10.40.80: Flags [S], seq 3774079837, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0

从1秒起双倍递增

值得注意是实质上第五次超时以后等到第六次,才会通知上层连接超时,那一共是63秒

三次握手的syncak包发送

01:17:20.084839 IP 172.16.3.15.2535 > 172.16.3.14.80: Flags [S], seq 1297135388, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
01:17:20.084908 IP 172.16.3.14.80 > 172.16.3.15.2535: Flags [S.], seq 1194120443, ack 1297135389, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
01:17:21.284093 IP 172.16.3.14.80 > 172.16.3.15.2535: Flags [S.], seq 1194120443, ack 1297135389, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
01:17:23.284088 IP 172.16.3.14.80 > 172.16.3.15.2535: Flags [S.], seq 1194120443, ack 1297135389, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
01:17:27.284095 IP 172.16.3.14.80 > 172.16.3.15.2535: Flags [S.], seq 1194120443, ack 1297135389, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
01:17:35.284097 IP 172.16.3.14.80 > 172.16.3.15.2535: Flags [S.], seq 1194120443, ack 1297135389, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
01:17:51.284093 IP 172.16.3.14.80 > 172.16.3.15.2535: Flags [S.], seq 1194120443, ack 1297135389, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0

从1秒起双倍递增

正常的数据包发送

01:32:20.443757 IP 172.16.3.15.2548 > 172.16.3.14.80: Flags [P.], seq 3319667389:3319667400, ack 1233846614, win 115, length 11
01:32:20.644600 IP 172.16.3.15.2548 > 172.16.3.14.80: Flags [P.], seq 3319667389:3319667400, ack 1233846614, win 115, length 11
01:32:21.046579 IP 172.16.3.15.2548 > 172.16.3.14.80: Flags [P.], seq 3319667389:3319667400, ack 1233846614, win 115, length 11
01:32:21.850632 IP 172.16.3.15.2548 > 172.16.3.14.80: Flags [P.], seq 3319667389:3319667400, ack 1233846614, win 115, length 11
01:32:23.458555 IP 172.16.3.15.2548 > 172.16.3.14.80: Flags [P.], seq 3319667389:3319667400, ack 1233846614, win 115, length 11
01:32:26.674594 IP 172.16.3.15.2548 > 172.16.3.14.80: Flags [P.], seq 3319667389:3319667400, ack 1233846614, win 115, length 11
01:32:33.106601 IP 172.16.3.15.2548 > 172.16.3.14.80: Flags [P.], seq 3319667389:3319667400, ack 1233846614, win 115, length 11
01:32:45.970567 IP 172.16.3.15.2548 > 172.16.3.14.80: Flags [P.], seq 3319667389:3319667400, ack 1233846614, win 115, length 11
01:33:11.698415 IP 172.16.3.15.2548 > 172.16.3.14.80: Flags [P.], seq 3319667389:3319667400, ack 1233846614, win 115, length 11
01:34:03.154300 IP 172.16.3.15.2548 > 172.16.3.14.80: Flags [P.], seq 3319667389:3319667400, ack 1233846614, win 115, length 11
01:35:46.065892 IP 172.16.3.15.2548 > 172.16.3.14.80: Flags [P.], seq 3319667389:3319667400, ack 1233846614, win 115, length 11
01:37:46.065382 IP 172.16.3.15.2548 > 172.16.3.14.80: Flags [P.], seq 3319667389:3319667400, ack 1233846614, win 115, length 11
01:39:46.064917 IP 172.16.3.15.2548 > 172.16.3.14.80: Flags [P.], seq 3319667389:3319667400, ack 1233846614, win 115, length 11
01:41:46.064466 IP 172.16.3.15.2548 > 172.16.3.14.80: Flags [P.], seq 3319667389:3319667400, ack 1233846614, win 115, length 11
01:43:46.064060 IP 172.16.3.15.2548 > 172.16.3.14.80: Flags [P.], seq 3319667389:3319667400, ack 1233846614, win 115, length 11
01:45:46.063675 IP 172.16.3.15.2548 > 172.16.3.14.80: Flags [P.], seq 3319667389:3319667400, ack 1233846614, win 115, length 11

从0.2秒起双倍递增,最大到120秒,一共15次

值得注意的是从32分开始,47分才结束,也就是15分钟25秒左右

linux是否支持了FALLBACK特性,做一个简单的测试

server开启iptables后,client连接server,在5次超时次数内关闭iptables
23:35:01.036565 IP 172.16.3.14.6071 > 172.16.10.40.12345: Flags [S], seq 2364912154, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
23:35:02.036152 IP 172.16.3.14.6071 > 172.16.10.40.12345: Flags [S], seq 2364912154, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
23:35:04.036126 IP 172.16.3.14.6071 > 172.16.10.40.12345: Flags [S], seq 2364912154, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
23:35:08.036127 IP 172.16.3.14.6071 > 172.16.10.40.12345: Flags [S], seq 2364912154, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
23:35:16.036131 IP 172.16.3.14.6071 > 172.16.10.40.12345: Flags [S], seq 2364912154, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
23:35:16.036842 IP 172.16.10.40.12345 > 172.16.3.14.6071: Flags [S.], seq 3634006739, ack 2364912155, win 14600, options [mss 1460], length 0
23:35:16.036896 IP 172.16.3.14.6071 > 172.16.10.40.12345: Flags [.], ack 3634006740, win 14600, length 0

接着server开启iptables后,client发送数据包,在15次超时次数内关闭iptables
23:35:48.129273 IP 172.16.3.14.6071 > 172.16.10.40.12345: Flags [P.], seq 2364912155:2364912156, ack 3634006740, win 14600, length 1
23:35:51.129120 IP 172.16.3.14.6071 > 172.16.10.40.12345: Flags [P.], seq 2364912155:2364912156, ack 3634006740, win 14600, length 1
23:35:57.129070 IP 172.16.3.14.6071 > 172.16.10.40.12345: Flags [P.], seq 2364912155:2364912156, ack 3634006740, win 14600, length 1
23:36:09.129068 IP 172.16.3.14.6071 > 172.16.10.40.12345: Flags [P.], seq 2364912155:2364912156, ack 3634006740, win 14600, length 1
23:36:09.129802 IP 172.16.10.40.12345 > 172.16.3.14.6071: Flags [.], ack 2364912156, win 14600, length 0

接着server不开iptables时,client发送数据包
23:36:15.217231 IP 172.16.3.14.6071 > 172.16.10.40.12345: Flags [P.], seq 2364912156:2364912157, ack 3634006740, win 14600, length 1
23:36:15.217766 IP 172.16.10.40.12345 > 172.16.3.14.6071: Flags [.], ack 2364912157, win 14600, length 0

接着server开启iptables,client发送数据包
23:36:26.658172 IP 172.16.3.14.6071 > 172.16.10.40.12345: Flags [P.], seq 2364912157:2364912158, ack 3634006740, win 14600, length 1
23:36:26.859055 IP 172.16.3.14.6071 > 172.16.10.40.12345: Flags [P.], seq 2364912157:2364912158, ack 3634006740, win 14600, length 1
23:36:27.261065 IP 172.16.3.14.6071 > 172.16.10.40.12345: Flags [P.], seq 2364912157:2364912158, ack 3634006740, win 14600, length 1
23:36:28.065106 IP 172.16.3.14.6071 > 172.16.10.40.12345: Flags [P.], seq 2364912157:2364912158, ack 3634006740, win 14600, length 1
23:36:29.673132 IP 172.16.3.14.6071 > 172.16.10.40.12345: Flags [P.], seq 2364912157:2364912158, ack 3634006740, win 14600, length 1
23:36:32.889068 IP 172.16.3.14.6071 > 172.16.10.40.12345: Flags [P.], seq 2364912157:2364912158, ack 3634006740, win 14600, length 1
23:36:39.321091 IP 172.16.3.14.6071 > 172.16.10.40.12345: Flags [P.], seq 2364912157:2364912158, ack 3634006740, win 14600, length 1
23:36:52.185135 IP 172.16.3.14.6071 > 172.16.10.40.12345: Flags [P.], seq 2364912157:2364912158, ack 3634006740, win 14600, length 1
23:37:17.913091 IP 172.16.3.14.6071 > 172.16.10.40.12345: Flags [P.], seq 2364912157:2364912158, ack 3634006740, win 14600, length 1

从这个测试中可以发现,当三次握手时RTT超过1秒时,数据发送阶段的RTO为3秒(服务端的SYNACK发生超时也是如此)

而后正常的一次RTT后,RTO重新收敛到200ms左右

再看看timestamps的支持如何

server开启iptables后,client连接server,在5次超时次数内关闭iptables
23:47:47.754316 IP 172.16.3.14.8603 > 172.16.10.40.12345: Flags [S], seq 479022248, win 14600, options [mss 1460,sackOK,TS val 2336007392 ecr 0,nop,wscale 7], length 0
23:47:48.754079 IP 172.16.3.14.8603 > 172.16.10.40.12345: Flags [S], seq 479022248, win 14600, options [mss 1460,sackOK,TS val 2336008392 ecr 0,nop,wscale 7], length 0
23:47:50.754088 IP 172.16.3.14.8603 > 172.16.10.40.12345: Flags [S], seq 479022248, win 14600, options [mss 1460,sackOK,TS val 2336010392 ecr 0,nop,wscale 7], length 0
23:47:54.754083 IP 172.16.3.14.8603 > 172.16.10.40.12345: Flags [S], seq 479022248, win 14600, options [mss 1460,sackOK,TS val 2336014392 ecr 0,nop,wscale 7], length 0
23:48:02.754094 IP 172.16.3.14.8603 > 172.16.10.40.12345: Flags [S], seq 479022248, win 14600, options [mss 1460,sackOK,TS val 2336022392 ecr 0,nop,wscale 7], length 0
23:48:02.754683 IP 172.16.10.40.12345 > 172.16.3.14.8603: Flags [S.], seq 697602971, ack 479022249, win 14480, options [mss 1460,nop,nop,TS val 4044659641 ecr 2336022392], length 0
23:48:02.754742 IP 172.16.3.14.8603 > 172.16.10.40.12345: Flags [.], ack 697602972, win 14600, options [nop,nop,TS val 2336022392 ecr 4044659641], length 0

接着server开启iptables后,client发送数据包,在15次超时次数内关闭iptables
23:48:11.944170 IP 172.16.3.14.8603 > 172.16.10.40.12345: Flags [P.], seq 479022249:479022250, ack 697602972, win 14600, options [nop,nop,TS val 2336031582 ecr 4044659641], length 1
23:48:12.145036 IP 172.16.3.14.8603 > 172.16.10.40.12345: Flags [P.], seq 479022249:479022250, ack 697602972, win 14600, options [nop,nop,TS val 2336031783 ecr 4044659641], length 1
23:48:12.547084 IP 172.16.3.14.8603 > 172.16.10.40.12345: Flags [P.], seq 479022249:479022250, ack 697602972, win 14600, options [nop,nop,TS val 2336032185 ecr 4044659641], length 1
23:48:13.351106 IP 172.16.3.14.8603 > 172.16.10.40.12345: Flags [P.], seq 479022249:479022250, ack 697602972, win 14600, options [nop,nop,TS val 2336032989 ecr 4044659641], length 1
23:48:14.959080 IP 172.16.3.14.8603 > 172.16.10.40.12345: Flags [P.], seq 479022249:479022250, ack 697602972, win 14600, options [nop,nop,TS val 2336034597 ecr 4044659641], length 1
23:48:18.175092 IP 172.16.3.14.8603 > 172.16.10.40.12345: Flags [P.], seq 479022249:479022250, ack 697602972, win 14600, options [nop,nop,TS val 2336037813 ecr 4044659641], length 1
23:48:24.607088 IP 172.16.3.14.8603 > 172.16.10.40.12345: Flags [P.], seq 479022249:479022250, ack 697602972, win 14600, options [nop,nop,TS val 2336044245 ecr 4044659641], length 1

可以看到开启了timestamps后,FALLBACK机制重设RTO为3秒将不会起作用


linux的对RTO计算的微调

linux对RTO计算的实际实现和RFC文档相比还是有所出入的,如果只按照RFC文档去按图索骥,那么在实际的RTO估计上会误入歧途

1 根据上一段可以发现,他把RTO的最小值设为200ms(甚至在ubuntu上是50ms,而RFC建议1秒),最大值设置为120秒(RFC强制60秒以上)

2 根据我对linux代码的分析,在RTT剧烈抖动的情况下,linux的实现减轻了急剧改变的RTT干扰,使得RTO的趋势图更加平滑

这一点体现在两点微调上:

微调1

当满足以下条件时

说明R’的波动太大了,和平滑过的RTT值比,差值的比RTTVAR还大

于是

而RFC文档是

可以看到,和RFC文档相比平滑系数乘以了1/8,表示R’对RTTVAR的影响将减小,使得RTTVAR更平滑,RTO也会更平滑

微调2

当RTTVAR减少的时候,会对RTTVAR做一次平滑处理,使得RTO不会下降的太离谱出现陡峭的趋势图

这里RTTVAR’指的是当前根据RTT计算得到的值,这个值限制了下限(RTO_MIN)以后和上一个RTT时的RTTVAR比较,当发现减少时,使用1/4系数来做平滑处理

这里为什么不对增大的情况做处理呢?我认为是因为RTO增大的话其实没事,但是如果减少量很大的话,可能会引起spurious retransmission(关于这个名词,详细见上文提到的RFC文档)


人为介入修改RTO的方法

回到最初的问题,是否能缩短RTO的值,而且这个RTO值如何根据linux的实际实现去预估

显然RTO初始值(包括FALLBACK)是不能改变的,这部分是固死写在代码里的

而三次握手以外的RTO值是可以预估的

预估时假设网络稳定,RTT始终不变为R(否则由于微调1和2,将极其复杂)

那么SRTT将始终为R,RTTVAR将始终为0.5R

否则

因此只需要改变RTO_MIN的值,就能显著影响RTO的值

RTO_MIN的设置

RTO_MIN的设置是根据ip route来实现的

[root@localhost.localdomain ~]# ping www.baidu.com
PING www.a.shifen.com (180.97.33.107) 56(84) bytes of data.
64 bytes from 180.97.33.107: icmp_seq=1 ttl=51 time=30.8 ms
64 bytes from 180.97.33.107: icmp_seq=2 ttl=51 time=29.9 ms

获得百度的IP后

[root@localhost.localdomain ~]# ip route add 180.97.33.108/32 via 172.16.3.1 rto_min 20
[root@localhost.localdomain ~]# nc www.baidu.com 80
[root@localhost.localdomain ~]# ss -eipn '( dport = :www )'
State       Recv-Q Send-Q                                                              Local Address:Port                                                                Peer Address:Port 
ESTAB       0      0                                                                     172.16.3.14:14149                                                              180.97.33.108:80     users:(("nc",7162,3)) ino:48057454 sk:ffff88023905adc0
         sack cubic wscale:7,7 rto:81 rtt:27/13.5 cwnd:10 send 4.3Mbps rcv_space:14600

因为RTO_MIN < 2R,所以RTO = 3R = 27 * 3 = 81

如果是内网的话,RTT非常小

[root@localhost.localdomain ~]# ip route add 172.16.3.16/32 via 172.16.3.1 rto_min 20               
[root@localhost.localdomain ~]# nc 172.16.3.16 22
SSH-2.0-OpenSSH_5.3
[root@localhost.localdomain ~]# ss -eipn '( dport = :22 )'
State       Recv-Q Send-Q                                                              Local Address:Port                                                                Peer Address:Port 
ESTAB       0      0                                                                     172.16.3.14:57578                                                                172.16.3.16:22     users:(("nc",7272,3)) ino:48059707 sk:ffff88023b7c7000
         sack cubic wscale:7,7 rto:21 rtt:1/0.5 ato:40 cwnd:10 send 116.8Mbps rcv_space:14600

因为RTO_MIN > 2R,所以RTO = R + RTO_MIN = 1 + 20 = 21

如果对内网的整个网络有自信的话,也可以不设置目标IP,直接对全部连接生效,如下

ip route change dev eth0 rto_min 20ms

总结

1 linux的超时重传实现大体上参考了RFC,但是有一部分微调:

RFC只有一个RTO初始值,为1秒。而linux的实现将三次握手阶段的包的RTO设为1秒,其余包初始时间设为0.2秒

由于RFC规定的算法不够完美,linux的实际实现在RTT剧烈抖动的情况下,减轻了急剧改变的RTT干扰,使得RTO的趋势图更加平滑

2 连接的SYN重传时间,在除非重新编译内核的情况下是无法调整的,但是push包是可以调整重传时间的

3 在比较稳定的网络中,假设设置的rto最小值为RTO_MIN

4 以移动网络客户端作为服务对象的服务器端,由于平均网络质量较差,调大RTO_MIN的值或许能减轻服务器的压力,具体值需要根据实际情况调整

5 在内网环境中,在KVM出现IO性能问题时,调小RTO_MIN的值或许能减少PUSH包的超时时间,但是会显著增加重传包的数目,可能会因为加重了KVM的负载反而使得情况恶化,所以具体值也需要根据实际情况调整

01 Dec 2015