简析TCP中的TIME_WAIT与CLOSE_WAIT状态

转载自：http://blog.chinaunix.net/uid-20384806-id-1954363.html 
              http://network.chinabyte.com/87/13312087.shtml
              http://blog.csdn.net/dyzhen/article/details/5993975
              http://blog.csdn.net/jewes/article/details/52654997

       TCP协议规定，对于已经建立的连接， 网络双方要进行四次握手才能成功断开连接，如果缺少了其中某个步骤，将会使连接处于假死状态，连接本身占用的资源不会被释放。网络服务器程序要同时管理大量连接，所以很有必要保证无用连接完全断开，否则大量僵死的连接会浪费许多服务器资源。在众多TCP状态中，最值得注意的状态有两个：TIME_WAIT和CLOSE_WAIT。
       因为Linux分配给一个用户的文件句柄是有限的，而TIME_WAIT和CLOSE_WAIT两种状态如果一直被保持，那么意味着对应数目的通道就一直被占着，一旦达到句柄数上限，新的请求就无法被处理了，接着应用程序可能返回大量Too Many Open Files异常。
       TCP断开连接的时序图如下：

TIME_WAIT状态

 

 

 

       1．四次握手的最后一个ACK是由主动关闭方发送出去的，若这个ACK丢失，被动关闭方会再次发一个FIN过来。若主动关闭方能够保持一个2MSL的TIME_WAIT状态，则有更大的机会让丢失的ACK被再次发送出去。
       如果主动关闭端不维持TIME_WAIT状态，而是处于CLOSED 状态，那么当主动端ACK丢失，被动方将重发最终的FIN，而主动端将响应RST，被动端收到后将此包解释成一个错误(在java中会抛出 connection reset的SocketException)。
       因而，要实现TCP全双工连接的正常终止，必须处理终止过程中四个包任何一个包的丢失情况，主动关闭连接的SOCKET A端必须维持TIME_WAIT状态 。

       2．如果目前连接的通信双方都已经调用了close()，假定双方都到达CLOSED状态，而没有TIME_WAIT状态时，就会出现如下的情况。现在有一个新的连接被建立起来，使用的IP地址与端口与先前的完全相同，后建立的连接又称作是原先连接的一个化身。还假定原先的连接中有数据报残存于网络之中，这样新的连接收到的数据报中有可能是先前连接的数据报。
       为了防止这一点，TCP不允许从处于TIME_WAIT状态的socket建立一个连接。处于TIME_WAIT状态的socket在等待两倍的MSL时间以后，将会转变为CLOSED状态。这就意味着，一个成功建立的连接，必然使得先前网络中残余的数据报都丢失了。 
       之所以是两倍的MSL，是由于MSL是一个数据报在网络中单向发出到认定丢失的时间，一个数据报有可能在发送途中或是其响应过程中成为残余数据报，确认一个数据报及其响应的丢弃的需要两倍的MSL。
       由于TIME_WAIT状态所带来的相关问题，可以通过设置SO_ LINKGER标志来避免socket进入TIME_WAIT状态，这可以通过发送RST而取代正常的TCP四次握手的终止方式。但这并不是一个很好的主意，TIME_WAIT对于我们来说往往是有利的。
       在高并发短连接的server端，当server处理完client的请求后立刻closesocket此时会出现time_wait状态，然后如果client再并发2000个连接，此时部分连接就连接不上了,用linger强制关闭可以解决此问题，但是linger会导致数据丢失。

       系统中TIME_WAIT的连接数很多，会导致什么问题呢？这要分别针对客户端和服务器端来看：
       如果是客户端发起了连接，传输完数据然后主动关闭了连接，这时这个连接在客户端就会处于TIMEWAIT状态，同时占用了一个本地端口。如果客户端使用短连接请求服务端的资源或者服务，客户端上将有大量的连接处于TIMEWAIT状态，占用大量的本地端口。最坏的情况就是，本地端口都被用光了，这时将无法再建立新的连接。
       对于服务器而已，由于服务器是被动等待客户端建立连接的，因此即使服务器端有很多TIME_WAIT状态的连接，也不存在本地端口耗尽的问题。大量的TIME_WAIT的连接会导致如下问题： 1.内存占用：因为每一个TCP连接都会有占用一些内存。2.在某些Linux版本上可能导致性能问题，因为数据包到达服务器的时候，内核需要知道数据包是属于哪个TCP连接的，在某些Linux版本上可能会遍历所有的TCP连接，所以大量TIME_WAIT的连接将导致性能问题。
       系统中处于TIME_WAIT状态的TCP连接数的上限是通过net.ipv4.tcp_max_tw_buckets参数来控制的，默认值为180000。当超过了以后，系统就开始关闭这些连接，同时会在系统日志中打印日志。

 

 

 

CLOSE_WAIT状态

       CLOSE_WAIT是被动关闭连接是形成的。根据TCP状态机，服务器端收到客户端发送的FIN，则按照TCP实现发送ACK，因此进入 CLOSE_WAIT状态。但如果服务器端不执行close()，就不能由CLOSE_WAIT迁移到LAST_ACK，则系统中会存在很多CLOSE_WAIT状态的连接。此时，可能是系统忙于处理读、写操作，而未将已收到FIN的连接进行close。此时，recv/read已收到 FIN的连接socket，会返回0。
       Close_Wait会占用一个连接，网络可用连接小。数量过多，可能会引起网络性能下降，并占用系统非换页内存。 尤其是在有连接池的情况下(比如HttpRequest)会耗尽连接池的网络连接数，导致无法建立网络连接。


       TIME_WAIT问题可以通过修改/etc/sysctl.conf文件，优化系统内核参数很容易解决。但是应对CLOSE_WAIT的情况还是需要从程序本身出发。因为发生CLOSE_WAIT的情况是服务器自己可控的，要么就是对方连接的异常， 要么就是自己没有迅速回收资源，总之不是由于自己程序错误导致的。如果一直保持在CLOSE_WAIT状态，那么只有一种情况，就是在对方关闭连接之后服务器程序自己没有进一步发出FIN信号，一般原因都是TCP连接没有调用关闭方法。换句话说，就是在对方连接关闭之后，程序里没有检测到，或者程序压根就忘记了这个时候需要关闭连接，于是这个资源就一直被程序占着。这种情况，通过服务器内核参数也没办法解决，服务器对于程序抢占的资源没有主动回收的权利，除非终止程序运行，一定程度上，可以使用TCP的KeepAlive功能，让操作系统替我们自动清理掉CLOSE_WAIT连接。