网络做事器程序要同时管理大量连接，以是很有必要担保无用连接完备断开，否则大量僵去世的连接会摧残浪费蹂躏许多做事器资源。在浩瀚TCP状态中，最值得把稳的状态有两个：CLOSE_WAIT和TIME_WAIT。
如果做事器涌现非常，百分之八九十都是下面两种情形：
由于linux分配给一个用户的文件句柄是有限的，而TIME_WAIT和CLOSE_WAIT两种状态如果一贯被保持，那么意味着对应数目的通道就一贯被占着，而且是“占着茅坑不使劲”，一旦达到句柄数上限，新的要求就无法被处理了，接着便是大量Too Many Open Files非常，tomcat崩溃。
在做事器的日常掩护过程中，会常常用到下面的命令：
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
它会显示例如下面的信息：
TIME_WAIT 814
CLOSE_WAIT 1
FIN_WAIT1 1
ESTABLISHED 634
SYN_RECV 2
LAST_ACK 1
常用的三个状态是：ESTABLISHED 表示正在通信，TIME_WAIT 表示主动关闭，CLOSE_WAIT 表示被动关闭。
二、TCP连接状态详解
详细每种状态什么意思，可以看看下面的先容。
1、LISTENING状态
FTP做事启动后首先处于侦听（LISTENING）状态。
2、ESTABLISHED状态
ESTABLISHED的意思是建立连接。表示两台机器正在通信。
3、CLOSE_WAIT
对方主动关闭连接或者网络非常导致连接中断，这时我方的状态会变成CLOSE_WAIT，此时我方要调用close()来使得连接精确关闭。
4、TIME_WAIT
我方主动调用close()断开连接，收到对方确认后状态变为TIME_WAIT。TCP协议规定TIME_WAIT状态会一贯持续2MSL(即两倍的分段最大生存期)，以此来确保旧的连接状态不会对新连接产生影响。处于TIME_WAIT状态的连接占用的资源不会被内核开释，以是作为做事器，在可能的情形下，只管即便不要主动断开连接，以减少TIME_WAIT状态造成的资源摧残浪费蹂躏。
目前有一种避免TIME_WAIT资源摧残浪费蹂躏的方法，便是关闭socket的LINGER选项。但这种做法是TCP协议不推举利用的，在某些情形下这个操作可能会带来缺点。
5、SYN_SENT状态
SYN_SENT状态表示要求连接，当你要访问其它的打算机的做事时首先要发个同步旗子暗记给该端口，此时状态为SYN_SENT，如果连接成功了就变为 ESTABLISHED，此时SYN_SENT状态非常短暂。但如果创造SYN_SENT非常多且在向不同的机器发出，那你的机器可能中了冲击波或震荡波 之类的病毒了。这类病毒为了传染别的打算机，它就要扫描别的打算机，在扫描的过程中对每个要扫描的打算机都要发出了同步要求，这也是涌现许多 SYN_SENT的缘故原由。
三、TCP连接的开释（四次挥手）
数据传输完毕后，双方都可开释连接。最开始的时候，客户端和做事器都是处于ESTABLISHED状态，然后客户端主动关闭，做事器被动关闭。
1. 客户端进程发出连接开释报文，并且停滞发送数据。开释数据报文首部，FIN=1，其序列号为seq=u（即是前面已经传送过来的数据的末了一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段纵然不携带数据，也要花费一个序号。
2. 做事器收到连接开释报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，做事端就进入了CLOSE-WAIT（关闭等待）状态。TCP做事器关照高层的运用进程，客户端向做事器的方向就开释了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是做事器若发送数据，客户端依然要接管。这个状态还要持续一段韶光，也便是全体CLOSE-WAIT状态持续的韶光。
3. 客户端收到做事器的确认要求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待做事器发送连接开释报文（在这之前还须要接管做事器发送的末了的数据）。
4. 做事器将末了的数据发送完毕后，就向客户端发送连接开释报文，FIN=1，ack=u+1，由于在半关闭状态，做事器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，做事器就进入了LAST-ACK（末了确认）状态，等待客户端的确认。
5. 客户端收到做事器的连接开释报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（韶光等待）状态。把稳此时TCP连接还没有开释，必须经由2MSL（最长报文段寿命，max segment lifetime）的韶光后，当客户端撤销相应的TCB后，才进入CLOSED状态。
6. 做事器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，做事器结束TCP连接的韶光要比客户端早一些。
四、做事器保持了大量TIME_WAIT状态
这种情形比较常见，一些爬虫做事器或者WEB做事器（如果网管在安装的时候没有做内核参数优化的话）上常常会碰着这个问题，这个问题是怎么产生的呢？
从上面的示意图可以看得出来，TIME_WAIT是主动关闭连接的一方保持的状态，对付爬虫做事器来说它本身便是客户端，在完成一个爬取任务之后，它就会发起主动关闭连接，从而进入TIME_WAIT的状态。然后在保持这个状态2MSL（max segment lifetime）韶光之后，彻底关闭回收资源。
为什么要这么做？明明就已经主动关闭连接了为啥还要保持资源一段韶光呢？
这个是TCP/IP的设计者规定的，紧张出于以下两个方面的考虑：
1. 防止上一次连接中的包，迷路后重新涌现，影响新连接（经由2MSL，上一次连接中所有的重复包都会消逝）。
2. 可靠的关闭TCP连接。在主动关闭方发送的末了一个 ack(fin) ，有可能丢失，这时被动方会重新发fin，如果这时主动方处于 CLOSED 状态 ，就会相应 rst 而不是 ack。以是主动方要处于 TIME_WAIT 状态，而不能是 CLOSED 。其余这么设计TIME_WAIT 会定时的回收资源，并不会占用很大资源的，除非短韶光内接管大量要求或者受到攻击。
五、做事器保持了大量CLOSE_WAIT状态
TIME_WAIT状态可以通过优化做事器参数得到办理，由于发生TIME_WAIT的情形是做事器自己可控的，要么便是对方连接的非常，要么便是自己没有迅速回收资源，总之不是由于自己程序缺点导致的。
但是CLOSE_WAIT就不一样了，从上面的图可以看出来，如果一贯保持在CLOSE_WAIT状态，那么只有一种情形，便是在对方关闭连接之后做事器程序自己没有进一步发出ack旗子暗记。换句话说，便是在对方连接关闭之后，程序里没有检测到，或者程序压根就忘却了这个时候须要关闭连接，于是这个资源就一贯被程序占着。
实行如下命令：
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
创造CLOSE_WAIT的数量始终在400以上，一贯没降过。
个人以为这种情形，通过做事器内核参数也没办法办理，做事器对付程序抢占的资源没有主动回收的权利，除非终止程序运行。
如果你利用的是HttpClient并且你碰着了大量CLOSE_WAIT的情形，那么这篇日志大概对你有用：
HttpClient连接池抛出大量ConnectionPoolTimeoutException: Timeout waiting for connection非常排查
http://blog.csdn.net/shootyou/article/details/6615051
在那边日志里头我举了个场景，来解释CLOSE_WAIT和TIME_WAIT的差异，这里重新描述一下：
服 务器A是一台爬虫做事器，它利用大略的HttpClient去要求资源做事器B上面的apache获取文件资源，正常情形下，如果要求成功，那么在抓取完资源后，做事器A会主动发出关闭连接的要求，这个时候便是主动关闭连接，做事器A的连接状态我们可以看到是TIME_WAIT。
如果一旦发生非常呢？假设要求的资源做事器B上并不存在，那么这个时候就会由做事器B发出关闭连接的要求，做事器A便是被动的关闭了连接，如果做事器A被动关闭连接之后程序员忘了让HttpClient开释连接，那就会造成CLOSE_WAIT的状态了。
以是如果将大量CLOSE_WAIT的办理办法总结为一句话那便是：查代码。由于问题出在做事器程序里头。
