记一次诡异的网络故障排除 - tpc_tw_recycle参数引起的网络故障

一、故障现象

我们团队访问腾讯云上部署的测试环境中的Web系统A时，偶尔会出现类似于网络闪断的情况，浏览器卡很久没有反应，最终报Connection Timeout。

不过奇怪的是，当团队中的某个人无法访问A时，其他人仍然可以正常访问。而且无法访问的这个人如果利用VPN，找一台其他地方的主机为跳板，也可正常访问A。

而且该故障发生几率较低，持续时间也较短，一般稍等片刻即可自行恢复。所以，很长一段时间以来，该故障均没有引起重视，只是被我们简单的认为可能是运营商网络质量问题。

直到最近发生几率越来越高，我们终于下决心要找出根因。

二、排查思路与步骤

1、既然故障发生时，仍然有人可以正常访问系统A，首先暂时排除系统A的问题。

2、系统A在同一时间，针对不同的客户端提供了差异化的服务。第一反应是不是因为某个客户访问太频繁，触发了网络上某些中间节点的流控机制，从而导致该客户端去往A的流量被暂时截断。

为了验证这一问题，我们在系统A所在服务器上使用TCP Dump抓包，待故障重现时，查看客户端的数据包是否有发送到A所在服务器。如果没有，则说明故障是由于网络中间设备丢包所致；如果有，则说明是A所在服务器操作系统丢包所致。

抓包命令如下：

sudo tcpdump -i eth0  tcp port 

其中eth0是服务器外网网卡设备描述符，6001是系统A监听端口。

抓包结果如下所示：

IP 125.69.28.252.64793 > agent-1.6001: Flags [S], seq 4247449309, win 65535, options [mss 1416,nop,wscale 5,nop,nop,TS val 703318263 ecr 0,sackOK,eol], length 0
IP 125.69.28.252.64793 > agent-1.6001: Flags [S], seq 4247449309, win 65535, options [mss 1416,nop,wscale 5,nop,nop,TS val 703318263 ecr 0,sackOK,eol], length 0
IP 125.69.28.252.64793 > agent-1.6001: Flags [S], seq 4247449309, win 65535, options [mss 1416,nop,wscale 5,nop,nop,TS val 703318263 ecr 0,sackOK,eol], length 0
IP 125.69.28.252.64793 > agent-1.6001: Flags [S], seq 4247449309, win 65535, options [mss 1416,nop,wscale 5,nop,nop,TS val 703318263 ecr 0,sackOK,eol], length 0
IP 125.69.28.252.64793 > agent-1.6001: Flags [S], seq 4247449309, win 65535, options [mss 1416,nop,wscale 5,nop,nop,TS val 703318263 ecr 0,sackOK,eol], length 0
IP 125.69.28.252.64793 > agent-1.6001: Flags [S], seq 4247449309, win 65535, options [mss 1416,nop,wscale 5,nop,nop,TS val 703318263 ecr 0,sackOK,eol], length 0

当故障发生时，A所在服务器不断收到到客户端发生来的SYN包，但是却一直没有回应SYN+ACK，服务器不断接受到客户端重发的SYN包，但是始终无法完成TCP三次握手成功建立连接。一段时间后，客户端报Connection Timeout。

3、到此，基本可以确认不是网络运营商的问题，而是因为数据包到达A所在服务器后，因为某种原因被内核丢包了。

为什么内核会丢包了呢？搞不懂那就搜索一下吧。搜索关键字“TCP SYN包 不回复”，果然搜索结果首页中就有类似问题。

比如这篇 https://blog.csdn.net/jueshengtianya/article/details/52130667

基本都说是Linux开启了TCP快速回收功能所致。

4、将之前操作系统设置的内核参数tcp_tw_recycle=1注释并让其生效后，反复测试，故障不再重现。

三、故障原因

TCP快速回收功能开启后，操作系统会记录客户端IP发出的数据包的时间戳，如果收到的数据包的时间戳早于最近一次记录的时间戳，操作系统将认为该数据包是过期的数据包，故会丢弃此包。

当某个客户端IP的数据包是由同一主机产生时，数据包的时间戳通常都是单调递增的，故一般不会出问题。但是在NAT网络环境下，同一个客户端IP背后转发的是诸多内网主机产生的数据包，不同主机产生数据包的时间戳就不一定保证单调递增了，所以会随机出现丢包故障。

四、结论

1、在当今NAT网络环境随处可见的大背景下，Linux服务器不要开启TCP快速回收功能，即不应该设置内核参数tcp_tw_recycle=1。

2、遭遇随机小概率发生的网络故障时，要及早引起重视，排查出根因。网络故障的排查宜分段排除，当应用层的错误提示信息量不足时，抓包是最直接快速的检查手段。