Linux服务器TIME_WAIT进程的解决与原因

linux服务器上tcp有大量time_wait状态的解决方法和原因解释

毫无疑问，TCP中有关网络编程最不容易理解的是它的TIME_WAIT状态，TIME_WAIT状态存在于主动关闭socket连接的一方。

TIME_WAIT状态存在的理由：
TCP/IP协议就是这样设计的，是不可避免的。主要有两个原因:
1）可靠地实现TCP全双工连接的终止
TCP协议在关闭连接的四次握手过程中，最终的ACK是由主动关闭连接的一端（后面统称A端）发出的，如果这个ACK丢失，对方（后面统称B端）将重发出最终的FIN，因此A端必须维护状态信息（TIME_WAIT）允许它重发最终的ACK。如果A端不维持TIME_WAIT状态，而是处于CLOSED 状态，那么A端将响应RST分节，B端收到后将此分节解释成一个错误。
因而，要实现TCP全双工连接的正常终止，必须处理终止过程中四个分节任何一个分节的丢失情况，主动关闭连接的A端必须维持TIME_WAIT状态。
2）允许老的重复分节在网络中消逝
TCP分节可能由于路由器异常而“迷途”，在迷途期间，TCP发送端可能因确认超时而重发这个分节，迷途的分节在路由器修复后也会被送到最终目的地，这个迟到的迷途分节到达时可能会引起问题。在关闭“前一个连接”之后，马上又重新建立起一个相同的IP和端口之间的“新连接”，“前一个连接”的迷途重复分组在“前一个连接”终止后到达，而被“新连接”收到了。为了避免这个情况，TCP协议不允许处于TIME_WAIT状态的连接启动一个新的可用连接，因为TIME_WAIT状态持续2MSL，就可以保证当成功建立一个新TCP连接的时候，来自旧连接重复分组已经在网络中消逝。

MSL为最长分节生命期，任何TCP实现都必须为MSL选择一个值，RFC 1122的建议值是2分钟，不过Berkeley的实现传统上改用30秒这个值，这意味着TIME_WAIT状态的持续时间在1分钟到4分钟之间。MSL是任何IP数据报能够在因特网中存活的最长时间。

在检查服务器时，发现有很多连接超时情况出现，用netstat命令查看，tcp的time_wait状态较多，需要进行优化。

1、看一下现在time_wait的数量          netstat -an | grep TIME_WAIT | wc -l
2、发现系统存在大量TIME_WAIT状态的连接，通过调整内核参数解决，在 /etc/sysctl.conf中加入
         net.ipv4.tcp_tw_recycle = 1   （表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭）
         net.ipv4.tcp_fin_timeout=30    （修改系統默认的 TIMEOUT 时间）

      然后执行 /sbin/sysctl -p 让参数生效。
 3、看看系统的tcp参数情况
         sysctl -a|grep tcp

修改生效后，time_wait数会明显下降。
TIME_WAIT状态存在的理由：
主动关闭的Socket端会进入TIME_WAIT状态，并且持续2MSL时间长度，MSL就是maximum segment lifetime(最大分节生命期），这是一个IP数据包能在互联网上生存的最长时间，超过这个时间将在网络中消失。MSL在RFC 1122上建议是2分钟，而源自berkeley的TCP实现传统上使用30秒，因而，TIME_WAIT状态一般维持在1-4分钟。
明明就已经主动关闭连接了为啥还要保持资源一段时间呢？这个是TCP/IP的设计者规定的，主要出于以下两个方面的考虑：
1、防止上一次连接中的包，迷路后重新出现，影响新连接（经过2MSL，上一次连接中所有的重复包都会消失）
2、可靠的关闭TCP连接。在主动关闭方发送的最后一个 ack(fin) ，有可能丢失，这时被动方会重新发fin, 如果这时主动方处于 CLOSED 状态，就会响应 rst 而不是 ack。所以主动方要处于 TIME_WAIT 状态，而不能是 CLOSED 。另外这么设计TIME_WAIT 会定时的回收资源，并不会占用很大资源的，除非短时间内接受大量请求或者受到攻击。

参考文章： http://blog.csdn.net/shootyou/article/details/6622226

巴特西

Linux服务器TIME_WAIT进程的解决与原因

linux服务器上tcp有大量time_wait状态的解决方法和原因解释

最新文章

热门文章