服务器出现大量TIME_WAIT状态怎么解决

1. TIME_WAIT产生的原因

1.1 四次挥手

0. 假设主动关闭连接的一方为A,被动关闭连接的一方为B
1. A调用close()；协议层发送FIN包
2. B收到FIN包后，回复ACK，进入CLOSE_WAIT状态，A等待对方关闭，进入FIN_WAIT_2状态，此时，A会等待B的应用程序调用close操作
3. B在完成所有数据发送后，调用close()操作；此时，协议层会发送FIN包给A，然后等待对方的ACK，进入LAST_ACK状态；
4. A收到FIN包，回复ACK，进入TIME_WAIT状态；B收到ACK后，进入CLOSED状态; 如果B没有受到ACK，那么将再次发送FIN包给A，确保连接关闭的可靠性
5. 等待2MSL时间，主动关闭的一方，结束TIME_WAIT，进入CLOSED状态；如果在此期间收到了新的FIN，那么会在回复ACK之后，重新等待2MSL

MSL(Maximum Segment Lifetime,“报文最大生存时间”)，他表示任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。
TTL(time to live,“生存时间”)，存储了一个ip数据报可以经过的最大路由数，每经过一个处理他的路由器此值就减1，当此值为0则数据报将被丢弃，同时发送ICMP报文通知源主机。
在 RFC 793中规定MSL为2分钟，linux中默认为30秒。

1.2 TIME_WAIT有什么用呢？

如果没有TIME_WAIT这个状态，主动方直接关闭连接的时候。 两种情况下，处理会出问题。

1. 如果A和B又重新建立链接，而这个时候B上次连接没有收到A的ack，导致重传的fin过来了，这将影响新的连接。
2. AB之间没有新连接，B没有收到A的ack，导致重传的fin过来了，A会给B发一个RST包，可能会影响B其它的服务连接。

2. TIME_WAIT造成的危害

2.1 消耗资源

为释放的socket会占用内存、CPU、文件描述符数量等等，还有一个时端口数量，在一个连接没有进入CLOSED状态之前，这个连接是不能被重用的！除非设置了端口重用。

3. 解决办法

3.1 修改内核参数

net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭；
net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。

net.ipv4.tcp_tw_reuse启用时，当主动关闭连接的一方，再次向对方发起连接请求的时候，可以复用TIME_WAIT状态的连接。 系统根据时间戳判断是否是延迟的数据，如果是，则丢弃。
net.ipv4.tcp_tw_recycle启用时，回收时间不再是2msl而是一个RTO（retransmission timeout，数据包重传的timeout时间），远小于2msl，约0.7s。

3.2 不主动关闭socket

不主动关闭socket，就不会产生TIME_WAIT状态

3.3 短链接改长连接

长连接从根本上减少了关闭连接的次数，减少了TIME_WAIT状态的产生数量，在高并发的系统中非常有效

参考:
[1] TCPIP详解 卷1：协议
[2] https://blog.csdn.net/weixin_39590058/article/details/105681569
[3] https://blog.csdn.net/fanren224/article/details/89849276
[4] https://www.jianshu.com/p/cd801d1b3147
[5] 《unix网络编程》