TCP--telnet为何在127s后返回？

背景

近期编写了监控业务服务器的脚本，主要原理是用shell脚本（运行shell的机器称之为监控机）调用项目组专用的接口测试工具，对指定的业务服务器进行业务操作，根据接口测试工具的返回结果判断业务服务器是否运行正常，并使用crontab设置每分钟执行一次监控脚本。

在接口测试工具启动前，先使用telnet ip port判断了业务服务器的端口是否打开。监控工作如期进行着……

然而，当新增对某个业务服务器进行监控时，发现telnet该业务服务器所花费的时间很长，已经超过了1分钟，这意味着脚本不能在预定的1分钟的监控间隔内执行完毕，于是我针对该问题进行了探索和研究。

探索和研究

从一些网页中得知可在一些特定文件中设置TMOUT变量来控制telnet的超时时间，也有网页中提到可以使用nc命令代替telnet实现同类效果并可以设置超时时间——还没来得及作深入了解，测试出telnet该业务服务器的所需时长：

time telnet 123.59.208.201 62715

Trying 123.59.208.201...

telnet: connect to address 123.59.208.201: Connection timed out

telnet 123.59.208.201 62715  0.00s user 0.00s system 0% cpu 2:07.29 total

结果显示时长为2:07.29,即127s。

常见的超时时间，应多是分钟的倍数，如60s、3600s等，又或者应是10的倍数，如30s、200s等。但反复测试了几次，均是127s。它的特殊性引起了我的好奇，因为127并非是一个普通的数字，它正是2的7次方-1。于是，我修正了搜索的方向。终于，从搜索返回的结果页中看到了一个链接，原文链接：

http://www.chengweiyang.cn/2017/02/18/linux-connect-timeout/?utm_source=tuicool&utm_medium=referral

这篇文章解决了我此时的疑惑，也开启了新的探索之旅。

127的由来

使用tcpdump进行抓包，运行如下命令：

sudo tcpdump -i eth0 -nn 'host 123.59.208.201'

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

再新打开一个终端窗口，执行telnet命令：

date +%Y%m%d-%H:%M:%S.%N;time telnet 123.59.208.201 62715;date +%Y%m%d-%H:%M:%S.%N;

20170526-18:04:23.764397558

Trying 123.59.208.201...

telnet: connect to address 123.59.208.201: Connection timed out

telnet 123.59.208.201 62715  0.00s user 0.00s system 0% cpu 2:07.22 total

20170526-18:06:30.989480391

这时，tcpdump所在的终端会同步输出telnet命令所产生的数据包信息：

18:04:23.765507 IP 10.253.4.55.34680 > 123.59.208.201.62715: Flags [S], seq 922947731, win 29200, options [mss 1460,sackOK,TS val 13801993 ecr 0,nop,wscale 7], length 0

18:04:24.768182 IP 10.253.4.55.34680 > 123.59.208.201.62715: Flags [S], seq 922947731, win 29200, options [mss 1460,sackOK,TS val 13802996 ecr 0,nop,wscale 7], length 0

18:04:26.772188 IP 10.253.4.55.34680 > 123.59.208.201.62715: Flags [S], seq 922947731, win 29200, options [mss 1460,sackOK,TS val 13805000 ecr 0,nop,wscale 7], length 0

18:04:30.780189 IP 10.253.4.55.34680 > 123.59.208.201.62715: Flags [S], seq 922947731, win 29200, options [mss 1460,sackOK,TS val 13809008 ecr 0,nop,wscale 7], length 0

18:04:38.796205 IP 10.253.4.55.34680 > 123.59.208.201.62715: Flags [S], seq 922947731, win 29200, options [mss 1460,sackOK,TS val 13817024 ecr 0,nop,wscale 7], length 0

18:04:54.828196 IP 10.253.4.55.34680 > 123.59.208.201.62715: Flags [S], seq 922947731, win 29200, options [mss 1460,sackOK,TS val 13833056 ecr 0,nop,wscale 7], length 0

18:05:26.860210 IP 10.253.4.55.34680 > 123.59.208.201.62715: Flags [S], seq 922947731, win 29200, options [mss 1460,sackOK,TS val 13865088 ecr 0,nop,wscale 7], length 0

根据telnet命令的起始时间和tcpdump输出的时间：

04:23.76

04:24.76

04:26.77

04:30.78

04:38.79

04:54.82

05:26.86

06:30.98

不难看出规律：它们的差值(单位s)是双倍递增的：1、2、4、8、16、32、64。

内部原理

tcp超时与重传

执行telnet命令，其实是尝试建立tcp连接的过程。而建立tcp连接时会涉及到两个概念：一个是RTT，一个是RTO。
RTT (Round-Trip Time) 即，往返时间
RTO (Retransmission Time Out) 即，重传超时
上面的时间间隔显然就是RTO。

建立tcp连接的过程和细节这里不再赘述，如有需要可以参阅《TCPIP详解(卷1)》。

根据该监控机的内核的版本，查看了linux的相关代码：
http://elixir.free-electrons.com/linux/v3.10/source/include/net/tcp.h

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

得到：

HZ是1s。所以RTO的最小值是200ms，RTO的最大值是120s，即2分钟。
从tcpdump的结果看，监控机的RTO是1s，原因未知。
根据代码中的算法部分可知，RTO重传间隔是指数增加的，随着重传次数的增多，消耗的时间指数增长。当RTO小于TCP_RTO_MAX时，则RTO每次翻倍，当超过TCP_RTO_MAX之后，不再翻倍，而是固定用TCP_RTO_MAX，即2分钟。

而，linux内核变量net.ipv4.tcp_syn_retries用来告诉内核，当尝试新建一个TCP连接时，要重新发送多少次初始的SYN报文。可以通过 sysctl 命令查看。

查看变量`tcp_syn_retries`的值

sudo sysctl net.ipv4.tcp_syn_retries

net.ipv4.tcp_syn_retries = 6

因为tcp_syn_retries控制的是重新发送的次数，所以加上初始的那1次，所以上述tcpdump的输出中一共有7条。

设置变量`tcp_syn_retries`的值

设置net.ipv4.tcp_syn_retries并测试telnet的时长：

sudo sysctl net.ipv4.tcp_syn_retries=1

net.ipv4.tcp_syn_retries = 1

验证：

time telnet 123.59.208.201 62715

Trying 123.59.208.201...

telnet: connect to address 123.59.208.201: Connection timed out

telnet 123.59.208.201 62715  0.00s user 0.00s system 0% cpu 3.008 total

可见，net.ipv4.tcp_syn_retries = 1时，telnet的耗时约为3s。可以预知的是，如果用tcpdump抓包，应当有两条，而3s则是RTO分别取1s和2s的结果。

sudo sysctl net.ipv4.tcp_syn_retries=2

net.ipv4.tcp_syn_retries = 2

time telnet 123.59.208.201 62715

Trying 123.59.208.201...

telnet: connect to address 123.59.208.201: Connection timed out

telnet 123.59.208.201 62715  0.00s user 0.00s system 0% cpu 7.010 total

net.ipv4.tcp_syn_retries = 2时，telnet的耗时约为7s，遵守RTO指数递增规律。

sudo sysctl net.ipv4.tcp_syn_retries=5

net.ipv4.tcp_syn_retries = 5

time telnet 123.59.208.201 62715

Trying 123.59.208.201...

telnet: connect to address 123.59.208.201: Connection timed out

telnet 123.59.208.201 62715  0.00s user 0.00s system 0% cpu 1:03.14 total

net.ipv4.tcp_syn_retries = 5时，telnet的耗时约为63s，遵守RTO指数递增规律。

那么，按照RTO指数递增规律和TCP_RTO_MAX的设定，当net.ipv4.tcp_syn_retries持续增大时，RTO并不会对应地指数递增下去，把net.ipv4.tcp_syn_retries设置成10看看效果：

sudo sysctl net.ipv4.tcp_syn_retries=10

net.ipv4.tcp_syn_retries = 10

验证：

date +%Y%m%d-%H:%M:%S.%N;time telnet 123.59.208.201 62715;date +%Y%m%d-%H:%M:%S.%N;

20170526-18:47:25.899074041

Trying 123.59.208.201...

telnet: connect to address 123.59.208.201: Connection timed out

telnet 123.59.208.201 62715  0.00s user 0.00s system 0% cpu 10:08.64 total

20170526-18:57:34.541575652

查看tcpdump的结果：

18:47:25.900294 IP 10.253.4.55.36266 > 123.59.208.201.62715: Flags [S], seq 3545463057, win 29200, options [mss 1460,sackOK,TS val 16384128 ecr 0,nop,wscale 7], length 0

18:47:26.902184 IP 10.253.4.55.36266 > 123.59.208.201.62715: Flags [S], seq 3545463057, win 29200, options [mss 1460,sackOK,TS val 16385130 ecr 0,nop,wscale 7], length 0

18:47:28.908195 IP 10.253.4.55.36266 > 123.59.208.201.62715: Flags [S], seq 3545463057, win 29200, options [mss 1460,sackOK,TS val 16387136 ecr 0,nop,wscale 7], length 0

18:47:32.916178 IP 10.253.4.55.36266 > 123.59.208.201.62715: Flags [S], seq 3545463057, win 29200, options [mss 1460,sackOK,TS val 16391144 ecr 0,nop,wscale 7], length 0

18:47:40.940213 IP 10.253.4.55.36266 > 123.59.208.201.62715: Flags [S], seq 3545463057, win 29200, options [mss 1460,sackOK,TS val 16399168 ecr 0,nop,wscale 7], length 0

18:47:56.972221 IP 10.253.4.55.36266 > 123.59.208.201.62715: Flags [S], seq 3545463057, win 29200, options [mss 1460,sackOK,TS val 16415200 ecr 0,nop,wscale 7], length 0

18:48:29.004213 IP 10.253.4.55.36266 > 123.59.208.201.62715: Flags [S], seq 3545463057, win 29200, options [mss 1460,sackOK,TS val 16447232 ecr 0,nop,wscale 7], length 0

18:49:33.132192 IP 10.253.4.55.36266 > 123.59.208.201.62715: Flags [S], seq 3545463057, win 29200, options [mss 1460,sackOK,TS val 16511360 ecr 0,nop,wscale 7], length 0

18:51:33.580213 IP 10.253.4.55.36266 > 123.59.208.201.62715: Flags [S], seq 3545463057, win 29200, options [mss 1460,sackOK,TS val 16631808 ecr 0,nop,wscale 7], length 0

18:53:33.900217 IP 10.253.4.55.36266 > 123.59.208.201.62715: Flags [S], seq 3545463057, win 29200, options [mss 1460,sackOK,TS val 16752128 ecr 0,nop,wscale 7], length 0

18:55:34.220216 IP 10.253.4.55.36266 > 123.59.208.201.62715: Flags [S], seq 3545463057, win 29200, options [mss 1460,sackOK,TS val 16872448 ecr 0,nop,wscale 7], length 0

当RTO18:48:29.00 -> 18:49:33.13到达64s后，下一次按照递增规则应当变为128s，而实际上，18:49:33.13 -> 18:51:33.58 -> 18:53:33.90 -> 18:55:34.22，RTO变为恒定的120s（TCP_RTO_MAX）。

取值范围

设置成0次会报错：

sudo sysctl net.ipv4.tcp_syn_retries=0

sysctl: setting key "net.ipv4.tcp_syn_retries": Invalid argument

net.ipv4.tcp_syn_retries = 0

不少网页上提到net.ipv4.tcp_syn_retries的最大值可设置为255、默认值是5，在这台监控机上实测发现最大只能设置为127：

sudo sysctl net.ipv4.tcp_syn_retries=127

net.ipv4.tcp_syn_retries = 127

尝试设置成128时保错：

sudo sysctl net.ipv4.tcp_syn_retries=128

sysctl: setting key "net.ipv4.tcp_syn_retries": Invalid argument

net.ipv4.tcp_syn_retries = 128

在linux内核的相关网页上有明确记录——最大不超过127、默认值为6：
https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt

tcp_syn_retries - INTEGER
Number of times initial SYNs for an active TCP connection attempt
will be retransmitted. Should not be higher than 127. Default value
is 6, which corresponds to 63seconds till the last retransmission
with the current initial RTO of 1second. With this the final timeout
for an active TCP connection attempt will happen after 127seconds.

但，指出net.ipv4.tcp_syn_retries的最大值可设置为255的网页中，有不少网页看起来也具有一定的可信度，比如：

https://www.frozentux.net/ipsysctl-tutorial/chunkyhtml/tcpvariables.html

3.3.24. tcp_syn_retries
The tcp_syn_retries variable tells the kernel how many times to try to retransmit the initial SYN packet for an active TCP connection attempt.
This variable takes an integer value, but should not be set higher than 255 since each retransmission will consume huge amounts of time as well as some amounts of bandwidth. Each connection retransmission takes aproximately 30-40 seconds. The default setting is 5, which would lead to an aproximate of 180 seconds delay before the connection times out.

随着根据实测结果和网站的权威性，我更信赖最大不超过127、默认值为6，但同时也很好奇，这些网页的内容依据出自何处？

永久修改

上述提到的修改net.ipv4.tcp_syn_retries的方式均是临时修改，重启系统后便失效。若想永久生效，则需要修改相应的配置文件，请自行搜索。

另外，因为变量net.ipv4.tcp_syn_retries是系统范围的，而它影响tcp建立连接的重传次数，所以修改前建议与系统管理员确认。

总结

美其名曰探索和研究，实际就是在踩自己因为基础知识欠缺而埋下的坑。

虽然搞清楚了127的由来，但却带来了许多新的疑问和不解，作为下一次踩坑的引子。

参考链接

踩坑的过程，总能发现一些不错的资源网站，如：

我想，这算得上对困而学之者的最好奖励了。大概也是为了让我能够成为学而知之者吧。