tcp_tw_recycle参数引发的系统问题

前一段时间在做全站HTTPS的部署时，遇到了一个很有趣的与Linux内核相关的问题，本人对内核没有研究，记录下来作为学习笔记。

1. 问题背景

前段时间为了应对苹果的ATS策略，完成了全站服务端的HTTPS部署。为了减少负载均衡设备的开销，我们开启的是F5的四层模式Perfomance(Layer4)，即只处理四层TCP连接，过来后直接做NAT转发到后端Web Server。
然而诡异的问题发生了，完成这次升级后，部分用户直接无法打开网页，我们立刻组织分析。

从客户端来看，TCP建连失败

在负载均衡上抓包分析，syn包已经发到Web Server，但没返回syn ack

Web Server上抓包，确定有收到syn包，但被拒绝。同时，发现只有客户端带时间戳的包才会被拒绝。


我们发现，只要为客户端的TCP带上时间戳，就会导致问题发生，关闭客户端时间戳，问题恢复。这就解释了为什么只有部分用户有问题，其他用户正常。

2. 问题定位

通过参考网上的资料，我们定位到问题发生的原因：我们的Web Server的Linux内做过调整，开启了net.ipv4.tcp_tw_recycle，在负载均衡只做NAT的情况下，触发了大量的TCP建连失败。

tcp_tw_recycle
Enable fast recycling of TIME-WAIT sockets. Enabling this option is not recommended since this causes
problems when working with NAT (Network Address Translation).

启用TIME-WAIT状态sockets的快速回收，这个选项不推荐启用。在NAT(Network Address Translation)网络下，会导致大量的TCP连接建立错误。

下面我们来具体说下，首先解释下TCP的TIME_WAIT状态：

• 通信双方建立TCP连接后，主动关闭连接的一方就会进入TIME_WAIT状态。
• 比如，客户端主动关闭连接时，会发送最后一个ack后，然后会进入TIME_WAIT状态，再停留2个MSL时间(后有MSL的解释)，进入CLOSED状态。
• TIME_WAIT状态的作用是为了保证连接正常关闭，且不影响其他新建的链接。
  

开启net.ipv4.tcp_tw_recycle的目的，就是希望能够加快TIME_WAIT状态的回收，当然这个选项的生效也依赖于net.ipv4.tcp_timestamps的开启（缺省就是开启的）。

当开启了tcp_tw_recycle选项后，当连接进入TIME_WAIT状态后，会记录对应远端主机最后到达分节的时间戳。如果同样的主机有新的分节到达，且时间戳小于之前记录的时间戳，即视为无效，相应的数据包会被丢弃

当负载均衡启用NAT模式时，客户端TCP请求到达负载均衡，修改目的地址（IP+端口号）后便转发给后端服务器，而客户端时间戳数据没有变化。对于后端Web Server，请求的源地址是负载均衡，所以从后端服务器的角度看，原本不同客户端的请求经过LVS的转发，就可能会被认为是同一个连接，加之不同客户端的时间可能不一致，所以就会出现时间戳错乱的现象，于是后面的数据包就被丢弃了。

3. 问题解决

解决办法是Linux内核引入 tcp_tw_timeout 开关，该开关可以动态设置TIME_WAIT 时间，加速回收TIME_WAIT 状态，从而可以关闭tcp_tw_recycle ，避免上述问题。

参考文献

http://blog.csdn.net/jueshengtianya/article/details/52130667 TCP服务端收到syn但是不回复syn ack问题分析

http://elf8848.iteye.com/blog/1739571 TCP/IP TIME_WAIT状态原理

http://dngood.blog.51cto.com/446195/988968/ 转:记一次TIME_WAIT网络故障

http://blog.csdn.net/wireless_tech/article/details/6405755 【经验总结】tcp_tw_recycle参数引发的故障