前一段时间在做全站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参数引发的故障