深挖由tcp_tw_recycle引发的业务超时问题

01 引言

成哥公司的一个APP类业务发展迅速，当前机房已无法满足用户激增的需求。前段时间通过在线迁移的方式将业务全部迁移至新数据中心。

迁移完成后，发现业务经常出现用户请求超时现象。经过统计，请求超时的比例和业务量有直接关系，在业务峰值时，超时比例最大。

新数据中心为全新架构的公司级私有云， 络基础架构的示意图如下：

02 故障排查

为尽快排查问题，需要在私有云的各个节点上进行联合抓包，通过用户请求中的唯一特征码，定位该条用户请求在哪个节点处理超时。

(1).定位故障点

为定位故障点，我们在私有云的入口防火墙、负载均衡器、后台Web服务器进行了同步抓包。发现用户请求已经到达了后台Web服务器，但是Web服务器在收到SYN请求后，没有响应。服务器上存在大量TCP标识为S的请求包。

Web服务器的tcpdump情况如下图所示：

（2）查看TCP的数据情况

登录服务器查看TCP的数据情况，发现有大量的TCP SYN包被丢弃，且数值一直在增长。

$ netstat -s | grep -i listen    1825 times the listen queue of a socket overflowed    2751213 SYNs to LISTEN sockets dropped

（3）全面排查Web服务器

确认是Web服务器丢包后，我们对Web服务器的 络环境进行了全面检测。

首先使用ping、tcping、iperf等工具分别对链路丢包情况、端口连接质量和带宽进行了测试，未发现任何问题。

之后我们将故障范围缩小到Web服务器的内核参数上。经过主机运维同事回忆，参与APP开发的厂商为改善TIME_WAIT连接数过多问题曾修改过内核参数。

他们在Web服务器手动启用了net.ipv4.tcp_tw_recycle参数，即该数值设置为1。

排查问题时的对话如下：

（4）问题解决

查阅资料后发现，该问题是在存在NAT的 络环境中，同时启用了net.ipv4.tcp_tw_recycle和net.ipv4.tcp_timestamps两个参数所致的。

其中net.ipv4.tcp_timestamps默认开启，net.ipv4.tcp_tw_recycle需要手动开启。

从Linux用户手册（Linux Manual Page）中看到如下解释：

虽然最后是通过关闭net.ipv4.tcp_tw_recycle参数解决的，但是成哥的思考才刚刚开始。

为什么在NAT环境中，Linux的TCP快速回收机制会有问题？

是在所有的NAT环境中，还是在部分的NAT环境中会出问题？

带着问题，成哥决定深挖下去。

03 深挖思路

既然Linux用户手册中说这个问题和NAT以及Linux参数有关，那就需要从两个方面挖掘下去。

（1）先挖NAT

私有云有两个节点涉及到NAT，即防火墙和负载均衡器。

防火墙的NAT：防火墙上使用DNAT（目的NAT）将该业务发布到公 中，供公 访问。

负载均衡器的NAT：负载均衡器上使用SNAT（源NAT）将公 用户的源地址转换成负载均衡器上的地址，再对用户请求分发到后台Web服务器。

成哥在这里解释一下，所谓的DNAT和SNAT，都是从流量发起方向考虑的。DNAT就是把转换目标地址，SNAT就是转换源地址。

（2）再挖TCP参数

仔细阅读Linux用户手册中，看到tcp_tw_recycle和timestamps、PAWS都有关系。

什么是monotonically increasing timestamps单调递增的时间戳、什么又是PAWS？

这都是挖掘的关键信息。

04 深挖NAT

针对私有云中两个节点涉及到NAT的节点来进行具体分析。
（1）入向流量
入向流量是指公 用户发起请求，从进入私有云到抵达Web服务器的流量。流量模型如下图所示：

用户请求流量在各节点的处理过程如下：
A．用户请求进入私有云，抵达防火墙。
流量在防火墙上匹配DNAT表项，进行一次地址转换。用户源地址不变，目的地址从业务的公 地址转换成业务的私 地址（此地址为负载组VIP地址）。
转换情况如下表所示：

注：我们使用公 地址1.1.1.1进行示例。
B. 用户请求经过防火墙的目的地址转换后，抵达负载均衡器。
负载均衡器查看目的地址为负载组VIP地址，则触发负载分发策略，将目的地址转换成具体的某台Web服务器地址。

同时，为使Web服务器的应答流量能够经过负载均衡器，负载均衡器使用了SNAT功能，即将用户的源地址转换成负载均衡器上的Self IP地址。这样Web服务器看到的用户请求都是从负载均衡器上发出的，以保证回程流量经过负载均衡器。
转换情况如下表所示：

服务器响应流量在各节点的处理过程如下：
A．Web服务器响应流量，经核心交换机进行路由转发（服务器的 关在核心交换机上，同时负载的Self IP和Web服务器的IP地址不在同一 段，需要进行路由转发）后抵达负载均衡器。
负载均衡器查找负载分发记录和SNAT表项，确认是回程流量。进行反向转换。
转换情况如下表所示：

B.回程流程从负载均衡器流出，抵达防火墙。
防火墙查找DNAT表项，确认是回程流量，进行反向转换。

转换情况如下表所示：

（3）问题流量解释
我们在负载均衡器上启用了SNAT功能，是为了保证回程流量经过负载均衡器。
流量在负载均衡器上将Web服务器地址转换成负载组VIP地址，这样流量再回流至防火墙时，就会匹配DNAT的转换表项。
下面通过两幅图来做简单说明，具体过程不再赘述。
这里只提一点，就是没有了负载均衡器的SNAT转换，用户的真实地址会抵达Web服务器。Web服务器回包时，流量经过核心交换机后，根据路由表，直接回流至防火墙。但是防火墙没有DNAT的表项，因为源IP地址不对，导致数据被丢弃。

05 未完待续

本篇介绍了由tcp_tw_recycle引发的业务超时问题的临时解决方案，以及由此引发成哥的深入思考。
既然本次问题和 络设备的NAT、以及Linux内核TCP参数都有关系，成哥就要从这两方面进行深入挖掘。
限于篇幅，本篇详细挖掘了私有云中两处涉及NAT的节点业务流走向。下篇将继续挖掘，深挖TCP参数，彻底刨出问题根源。

–END–

@IT管理局专注计算机领域技术、大学生活、学习方法、求职招聘、职业规划、职场感悟等类型的 内容。期待与你相遇，和你一同成长。

相关文章推荐：

Wireshark数据包分析三板斧

还在吐槽文本字符串难以处理，Python的这个绝活你还不知道