Linux下超时重传时间(RTO)的实现探究
最近出现了网络超时的问题要排查，大致按照如图思路去排查
1.排除代码逻辑问题，TCP相关可能的BUG，内核参数等问题;
2.排查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包发送
| 123456 |
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 001: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 001: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 001: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 001: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 001: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包发送
| 1234567 |
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 001: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 001: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 001: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 001: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 001: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 001: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秒起双倍递增
正常的数据包发送
| 12345678910111213141516 |
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 1101:32:20.644600 IP 172.16.3.15.2548 > 172.16.3.14.80: Flags [P.], seq 3319667389:3319667400, ack 1233846614, win 115, length 1101:32:21.046579 IP 172.16.3.15.2548 > 172.16.3.14.80: Flags [P.], seq 3319667389:3319667400, ack 1233846614, win 115, length 1101:32:21.850632 IP 172.16.3.15.2548 > 172.16.3.14.80: Flags [P.], seq 3319667389:3319667400, ack 1233846614, win 115, length 1101:32:23.458555 IP 172.16.3.15.2548 > 172.16.3.14.80: Flags [P.], seq 3319667389:3319667400, ack 1233846614, win 115, length 1101:32:26.674594 IP 172.16.3.15.2548 > 172.16.3.14.80: Flags [P.], seq 3319667389:3319667400, ack 1233846614, win 115, length 1101:32:33.106601 IP 172.16.3.15.2548 > 172.16.3.14.80: Flags [P.], seq 3319667389:3319667400, ack 1233846614, win 115, length 1101:32:45.970567 IP 172.16.3.15.2548 > 172.16.3.14.80: Flags [P.], seq 3319667389:3319667400, ack 1233846614, win 115, length 1101:33:11.698415 IP 172.16.3.15.2548 > 172.16.3.14.80: Flags [P.], seq 3319667389:3319667400, ack 1233846614, win 115, length 1101:34:03.154300 IP 172.16.3.15.2548 > 172.16.3.14.80: Flags [P.], seq 3319667389:3319667400, ack 1233846614, win 115, length 1101:35:46.065892 IP 172.16.3.15.2548 > 172.16.3.14.80: Flags [P.], seq 3319667389:3319667400, ack 1233846614, win 115, length 1101:37:46.065382 IP 172.16.3.15.2548 > 172.16.3.14.80: Flags [P.], seq 3319667389:3319667400, ack 1233846614, win 115, length 1101:39:46.064917 IP 172.16.3.15.2548 > 172.16.3.14.80: Flags [P.], seq 3319667389:3319667400, ack 1233846614, win 115, length 1101:41:46.064466 IP 172.16.3.15.2548 > 172.16.3.14.80: Flags [P.], seq 3319667389:3319667400, ack 1233846614, win 115, length 1101:43:46.064060 IP 172.16.3.15.2548 > 172.16.3.14.80: Flags [P.], seq 3319667389:3319667400, ack 1233846614, win 115, length 1101: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特性，做一个简单的测试
| 123456789101112131415161718192021222324252627282930 |
server开启iptables后，client连接server，在5次超时次数内关闭iptables23: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 023: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 023: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 023: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 023: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 023: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 023: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次超时次数内关闭iptables23:35:48.129273 IP 172.16.3.14.6071 > 172.16.10.40.12345: Flags [P.], seq 2364912155:2364912156, ack 3634006740, win 14600, length 123:35:51.129120 IP 172.16.3.14.6071 > 172.16.10.40.12345: Flags [P.], seq 2364912155:2364912156, ack 3634006740, win 14600, length 123:35:57.129070 IP 172.16.3.14.6071 > 172.16.10.40.12345: Flags [P.], seq 2364912155:2364912156, ack 3634006740, win 14600, length 123:36:09.129068 IP 172.16.3.14.6071 > 172.16.10.40.12345: Flags [P.], seq 2364912155:2364912156, ack 3634006740, win 14600, length 123: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 123: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 123:36:26.859055 IP 172.16.3.14.6071 > 172.16.10.40.12345: Flags [P.], seq 2364912157:2364912158, ack 3634006740, win 14600, length 123:36:27.261065 IP 172.16.3.14.6071 > 172.16.10.40.12345: Flags [P.], seq 2364912157:2364912158, ack 3634006740, win 14600, length 123:36:28.065106 IP 172.16.3.14.6071 > 172.16.10.40.12345: Flags [P.], seq 2364912157:2364912158, ack 3634006740, win 14600, length 123:36:29.673132 IP 172.16.3.14.6071 > 172.16.10.40.12345: Flags [P.], seq 2364912157:2364912158, ack 3634006740, win 14600, length 123:36:32.889068 IP 172.16.3.14.6071 > 172.16.10.40.12345: Flags [P.], seq 2364912157:2364912158, ack 3634006740, win 14600, length 123:36:39.321091 IP 172.16.3.14.6071 > 172.16.10.40.12345: Flags [P.], seq 2364912157:2364912158, ack 3634006740, win 14600, length 123:36:52.185135 IP 172.16.3.14.6071 > 172.16.10.40.12345: Flags [P.], seq 2364912157:2364912158, ack 3634006740, win 14600, length 123: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的支持如何
| 1234567891011121314151617 |
server开启iptables后，client连接server，在5次超时次数内关闭iptables23: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 023: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 023: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 023: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 023: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 023: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 023: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次超时次数内关闭iptables23: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 123: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 123: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 123: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 123: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 123: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 123: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来实现的
| 12345678910111213 |
[root@localhost.localdomain ~]# ping www.baidu.comPING 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 ms64 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:PortESTAB 0 0 172.16.3.14:14149 180.97.33.108:80 users:(("nc",7162,3)) ino:48057454 sk:ffff88023905adc0sack cubic wscale:7,7 rto:81 rtt:27/13.5 cwnd:10 send 4.3Mbps rcv_space:14600 |
因为RTO_MIN
如果是内网的话，RTT非常小
| 1234567 |
[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 22SSH-2.0-OpenSSH_5.3[root@localhost.localdomain ~]# ss -eipn '( dport =:22 )'State Recv-Q Send-Q Local Address:Port Peer Address:PortESTAB 0 0 172.16.3.14:57578 172.16.3.16:22 users:(("nc",7272,3)) ino:48059707 sk:ffff88023b7c7000sack 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，直接对全部连接生效，如下
| 1 |
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
http://www.bkjia.com/PHPjc/1108029.htmlwww.bkjia.comtruehttp://www.bkjia.com/PHPjc/1108029.htmlTechArticleLinux下超时重传时间(RTO)的实现探究 最近出现了网络超时的问题要排查，大致按照如图思路去排查 1.排除代码逻辑问题，TCP相关可能的BUG，...
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
