关于TIME_WAIT可能引发的网络问题

关于TIME_WAIT可能引发的网络问题

统计？

shell> netstat -nt | awk '/^tcp/ {++state[$NF]} END {for(key in state) print key,"\t",state[key]}'

如何减少？

网络上已经有不少相关的介绍，大多是建议：

shell> sysctl net.ipv4.tcp_tw_reuse=1

shell> sysctl net.ipv4.tcp_tw_recycle=1

这两个选项在降低TIME_WAIT数量方面可以说是立竿见影，不过如果你觉得问题已经完美搞定那就错了，实际上这样可能会引入一个更复杂的网络故障。

大概意思是说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。说到这里，大家可能会想到另一种解决方案：把tcp_timestamps设置为0，tcp_tw_recycle设置为1，这样不就可以鱼与熊掌兼得了么，实际并不是这么简单，因为一旦关闭了tcp_timestamps，那么即便打开了tcp_tw_recycle，也没有效果。

好在我们还有另一个内核参数tcp_max_tw_buckets（一般缺省是180000）可用：

shell> sysctl net.ipv4.tcp_max_tw_buckets=10000

通过设置它，系统会将多余的TIME_WAIT删除掉，此时系统日志里可能会显示：『TCP: time wait bucket table overflow』，多数情况下不用在意这些信息。完全禁止TIME_WAIT是不可取的，毕竟它是TCP的一部分。

原文

http://huoding.com/2012/01/19/142