先看以下TIME_WAIT状态是怎么产生的，最好的解释就是看TCP状态转换图咯
对与每个状态的解释如下
1、建立连接协议（三次握手）
（1）客户端发送一个TCP segment(Seq 由主机产生，假设为x, SYN=1)到服务器。这是三次握手过程中的segment 1。
（2） 服务器端回应客户端的，这是三次握手中的第2次握手，此时发送2个segment，第一个segment中SYN=1, Seq为主机产生,假设为y；第二个segment中ACK=1,Seq为客户端发送的Seq+1即x+1,这个表示它对刚才客户端SYN segment的回应；同时又标志SYN给客户端，询问客户端是否准备好进行数据通讯。
（3） 客户必须再次回应服务段一个ACK segment，此时该segment 的Seq为服务器所发的确认segment的Seq+1,即y+1。
2、连接终止协议（四次握手）
由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。
（1） TCP客户端发送一个带FIN标志的segment,假设Seq为x，用来关闭客户到服务器的数据传送。
(2) 服务器收到这个带FIN标志的segment后，它发回一个带ACK标志的segment,此时Seq为x+1,表示对客户端请求关闭连接的回应
(3） 服务器关闭客户端的连接，发送一个带FIN标志的segment,假设Seq为y给客户端
（4） 客户段发回带ACK标志segment表示确认，才是segment的Seq为y+1,表示对服务器segment的确认
下图为TCP连接与终止的序列图
CLOSED: 这个没什么好说的了，表示初始状态。
LISTEN: 这个也是非常容易理解的一个状态，表示服务器端的某个SOCKET处于监听状态，可以接受连接了。
SYN_RCVD: 这个状态表示接受到了SYN报文，在正常情况下，这个状态是服务器端的SOCKET在建立TCP连接时的三次握手会话过程中的一个中间状态，很短暂，基本上用netstat你是很难看到这种状态的，除非你特意写了一个客户端测试程序，故意将三次TCP握手过程中最后一个ACK报文不予发送。因此这种状态时，当收到客户端的ACK报文后，它会进入到ESTABLISHED状态。
SYN_SENT: 这个状态与SYN_RCVD遥想呼应，当客户端SOCKET执行CONNECT连接时，它首先发送SYN报文，因此也随即它会进入到了SYN_SENT状态，并等待服务端的发送三次握手中的第2个报文。SYN_SENT状态表示客户端已发送SYN报文。
ESTABLISHED：这个容易理解了，表示连接已经建立了。
FIN_WAIT_1: 这个状态要好好解释一下，其实FIN_WAIT_1和FIN_WAIT_2状态的真正含义都是表示等待对方的FIN报文。而这两种状态的区别是：FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时，它想主动关闭连接，向对方发送了FIN报文，此时该SOCKET即进入到FIN_WAIT_1状态。而当对方回应ACK报文后，则进入到FIN_WAIT_2状态，当然在实际的正常情况下，无论对方何种情况下，都应该马上回应ACK报文，所以FIN_WAIT_1状态一般是比较难见到的，而FIN_WAIT_2状态还有时常常可以用netstat看到。
FIN_WAIT_2：上面已经详细解释了这种状态，实际上FIN_WAIT_2状态下的SOCKET，表示半连接，也即有一方要求close连接，但另外还告诉对方，我暂时还有点数据需要传送给你，稍后再关闭连接。
TIME_WAIT: 表示收到了对方的FIN报文，并发送出了ACK报文，就等2MSL后即可回到CLOSED可用状态了。如果FIN_WAIT_1状态下，收到了对方同时带FIN标志和ACK标志的报文时，可以直接进入到TIME_WAIT状态，而无须经过FIN_WAIT_2状态。
注:MSL(最大分段生存期)指明TCP报文在Internet上最长生存时间,每个具体的TCP实现都必须选择一个确定的MSL值.RFC 1122建议是2分钟,但BSD传统实现采用了30秒.TIME_WAIT 状态最大保持时间是2 * MSL,也就是1-4分钟.
CLOSING: 这种状态比较特殊，实际情况中应该是很少见，属于一种比较罕见的例外状态。正常情况下，当你发送FIN报文后，按理来说是应该先收到（或同时收到）对方的ACK报文，再收到对方的FIN报文。但是CLOSING状态表示你发送FIN报文后，并没有收到对方的ACK报文，反而却也收到了对方的FIN报文。什么情况下会出现此种情况呢？其实细想一下，也不难得出结论：那就是如果双方几乎在同时close一个SOCKET的话，那么就出现了双方同时发送FIN报文的情况，也即会出现CLOSING状态，表示双方都正在关闭SOCKET连接。
CLOSE_WAIT: 这种状态的含义其实是表示在等待关闭。怎么理解呢？当对方close一个SOCKET后发送FIN报文给自己，你系统毫无疑问地会回应一个ACK报文给对方，此时则进入到CLOSE_WAIT状态。接下来呢，实际上你真正需要考虑的事情是察看你是否还有数据发送给对方，如果没有的话，那么你也就可以close这个SOCKET，发送FIN报文给对方，也即关闭连接。所以你在CLOSE_WAIT状态下，需要完成的事情是等待你去关闭连接。
LAST_ACK: 这个状态还是比较容易好理解的，它是被动关闭一方在发送FIN报文后，最后等待对方的ACK报文。当收到ACK报文后，也即可以进入到CLOSED可用状态了。
现在开始详细解释下TIME_WAIT状态(注意，该状态只有主动发起关闭的一方才能进入)
首先为什么需要TIME_WAIT状态。理由如下
1. 该状态可以可靠的实现TCP全双工连接的终止
2. 有了该状态，就允许了老的重复分节在网络中消逝
第一个理由的解释：假设最终的ACK丢失，服务器将重发FIN，因而客户端必须维护此信息而重发ACK。要是不维护该状态信息的话，客户端将发送带RST标志的TCP segment，而服务器将此解释成一个错误，这样就没有正确的彻底的终止T某个连接上两个方向的数据流(全双工关闭)
第二个理由的解释：首先解释下什么是迷途分组：如果某个路由其出现故障或崩溃，路由协议需化一段时间才能未定找出一条旋路通路，而在这段时间内有可能出现路由循环。假设该迷途的分组为一个TCP 分节，在它迷途期间，发端TCP会超时重传该分组，该分组最终也到达收端，而此时路由循环回复，之前迷途的分组也被送到收到，此时就出现了两个带FIN标志的segment，一个为超时重传segment，一个迷途segment，因此TCP必须正确处理这些重复的segment，而TIME_WAIT就能很好的解决该问题。如果有了TIME_WAIT状态，TCP将不会接收该迷途segment，而TIME_WAIT状态持续时间为2MSL,这就足够运行某个方向上的segment最多存活MSL秒即被丢弃，，另一个方向的应答最多存活MSL秒也被丢弃。这样就能保证老的重复的segmeng在网络中消逝
那如果当前系统，TIME_WAIT过多咋解决呢?下面为解决方法
[root@aaa1 ~]# sysctl -a|grep net.ipv4.tcp_tw
net.ipv4.tcp_tw_reuse = 0
net.ipv4.tcp_tw_recycle = 0
[root@aaa1 ~]#
vi /etc/sysctl
增加或修改net.ipv4.tcp_tw值：
net.ipv4.tcp_tw_reuse = 1 //打开SO_RESUEADDR选项
net.ipv4.tcp_tw_recycle = 1 //recyse是加速TIME-WAIT sockets回收
使内核参数生效：
[root@aaa1 ~]# sysctl -p
[root@aaa1 ~]# sysctl -a|grep net.ipv4.tcp_tw
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
用netstat再观察正常
对于SO_RESUEADDR套接字选项的解释如下
这个套接字选项通知内核，如果端口忙，但TCP状态位于 TIME_WAIT ，可以重用 端口。如果端口忙，而TCP状态位于其他状态，重用端口时依旧得到一个错误信息， 指明"地址已经使用中"。如果你的服务程序停止后想立即重启，而新套接字依旧 使用同一端口，此时 SO_REUSEADDR 选项非常有用。必须意识到，此时任何非期 望数据到达，都可能导致服务程序反应混乱，不过这只是一种可能，事实上很不 可能。
一个套接字由相关五元组构成，协议、本地地址、本地端口、远程地址、远程端 口。SO_REUSEADDR 仅仅表示可以重用本地本地地址、本地端口，整个相关五元组 还是唯一确定的。所以，重启后的服务程序有可能收到非期望数据。必须慎重使 用 SO_REUSEADDR 选项。
参考博文地址：