• 欢迎访问Ppabc博客网站,专注于Linux、CentOS、Apache、Nginx、MySQL、PHP等开源工具安装优化的技术博客,推荐使用最新版火狐浏览器和Chrome浏览器访问本网站,欢迎加入Ppabc博客
  • 如果您觉得本站非常有看点,那么赶紧使用Ctrl+D 收藏Ppabc博客吧

net.ipv4.tcp_tw_recycle值引发的网站卡顿问题分析

Linux学习 ppabc 1年前 (2016-12-29) 1403次浏览

某同事反馈访问测试站很慢,会一卡一卡的,其他地方网络访问就正常。
经过反复测试,不仅仅是 HTTP 慢,HTTPS 也会慢,但只局限在他的网络下,换其他网络就正常。
抓包来分析:
会出现 TCP Retransmission,可能是 timestamps 的影响

20161229171828

看了下服务器的内核参数 net.ipv4.tcp_tw_recycle = 1
可能是内核参数导致的,果断修改下
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
改为
net.ipv4.tcp_tw_reuse = 0
net.ipv4.tcp_tw_recycle = 0
一些高并发的 WebServer 上,为了端口能够快速回收,打开了 tcp_tw_reccycle,而在关闭 tcp_tw_reccycle 的时候,kernal 是不会检查对端机器的包的时间戳的;打开了 tcp_tw_reccycle 了,就会检查时间戳,可能是他那网络发来的包的时间戳是乱跳的,所以服务器就把带了“倒退”的时间戳的包当作是“recycle 的 tw 连接的重传数据,不是新的请求”,于是丢掉不回包,造成大量丢包。
经过分析试验,最终确认和 proc 参数 tcp_tw_recycle/tcp_timestamps 相关。

关于内核参数的详细介绍,可以参考官方文档(https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt)。我们这里简要说明一下 tcp_tw_recycle 参数。它用来快速回收 TIME_WAIT 连接,不过如果在 NAT 环境下会引发问题。

RFC1323 中有如下一段描述:

An additional mechanism could be added to the TCP, a per-hostcache of the last timestamp received from any connection.This value could then be used in the PAWS mechanism to rejectold duplicate segments from earlier incarnations of theconnection, if the timestamp clock can be guaranteed to haveticked at least once since the old connection was open. Thiswould require that the TIME-WAIT delay plus the RTT togethermust be at least one tick of the sender’s timestamp clock.Such an extension is not part of the proposal of this RFC.

大概意思是说 TCP 有一种行为,可以缓存每个连接最新的时间戳,后续请求中如果时间戳小于缓存的时间戳,即视为无效,相应的数据包会被丢弃。

Linux 是否启用这种行为取决于 tcp_timestamps 和 tcp_tw_recycle,因为 tcp_timestamps 缺省就是开启的,所以当 tcp_tw_recycle 被开启后,实际上这种行为就被激活了。

现在很多公司都用 LVS 做负载均衡,通常是前面一台 LVS,后面多台后端服务器,这其实就是 NAT,当请求到达 LVS 后,它修改地址数据后便转发给后端服务器,但不会修改时间戳数据,对于后端服务器来说,请求的源地址就是 LVS 的地址,加上端口会复用,所以从后端服务器的角度看,原本不同客户端的请求经过 LVS 的转发,就可能会被认为是同一个连接,加之不同客户端的时间可能不一致,所以就会出现时间戳错乱的现象,于是后面的数据包就被丢弃了,具体的表现通常是是客户端明明发送的 SYN,但服务端就是不响应 ACK,还可以通过下面命令来确认数据包不断被丢弃的现象:

shell> netstat -s | grep timestamp … packets rejects in established connections because of timestamp
如果服务器身处 NAT 环境,安全起见,通常要禁止 tcp_tw_recycle,至于 TIME_WAIT 连接过多的问题,可以通过激活 tcp_tw_reuse 来缓解。

进一步思考,既然必须同时激活 tcp_timestamps 和 tcp_tw_recycle 才会触发这种现象,那只要禁止 tcp_timestamps,同时激活 tcp_tw_recycle,就可以既避免 NAT 丢包问题,又降低 TIME_WAIT 连接数量。如果服务器并不依赖于 RFC1323,那么这种方法应该也是可行的,不过最好多做测试,以防有其他的副作用。

总结:
timestamps 建议开启(默认打开)
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 0


Selinux 中国 , 版权所有丨如未注明 , 均为原创丨本网站采用BY-NC-SA协议进行授权
转载请注明原文链接:net.ipv4.tcp_tw_recycle 值引发的网站卡顿问题分析
喜欢 (0)