背景

近期编写了监控业务服务器的脚本，主要原理是用 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 的由来，但却带来了许多新的疑问和不解，作为下一次踩坑的引子。

参考链接

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

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

背景