Linux服务器有大量的TIME_WAIT状态

我们经常会遇到在服务器上看到大量的TIME_WAIT，它们占用进程不释放，最后会导致所有进程数被耗完，服务器负载增高等生产事故，具体是什么原因导致的呢？我们先来看看TCP的三次握手四次挥手都是怎样的一个过程。

TCP三次握手

三次握手的过程如下图：

具体的过程如下：
（1）、客户端主动发起连接，向服务端监听的端口发送SYN包和一个随机的序列seq到服务端；
（2）、服务端收到SYN包后，回复客户端，发送ACK包（收到的seq加1）和一个随机序列到客户端；
（3）、客户端收到ACK包后，回复服务端，发送一个ACK包（收到的seq加1）；

由上图可以看到具体的状态变化，值得注意的是SYN_RECV状态，有时候我们会发现服务器上有大量的SYN_RECV状态，看到这个一般就可以确定是著名的SYN泛洪攻击，它就是用大量的伪终端来连接服务端，服务端回复ACK（也就是步骤2），由于这些终端都不存在，所以就会在第二部卡住了，造成服务端有大量的SYN_RECV状态，不断的消耗TCP进程数，导致正常业务无法建立正常连接。详细过程请移步至百度百科。

TCP四次挥手

四次挥手的过程如下图：

具体过程如下：
（1）、客户端主动发起断开连接，发送FIN包到服务端；
（2）、服务端收到FIN包后回复ACK包给客户端；
（3）、服务端发起断开连接，发送FIN包到客户端；
（4）、客户端收到FIN包后回复ACK给服务端；

具体过程还是比较简单，详情可以由上图可知。这里要注意三个状态：CLOSE_WAIT、TIME_WAIT和FIN_WAIT2。
其中CLOSE_WAIT是出现在被动断开方，如上图就是服务端。如果服务端出现大量的CLOSE_WAIT状态，一般情况下是由于程序中没有正常调用close()关闭连接，所以出现这个问题一般是会结合开发一起找原因。

FIN_WAIT2状态会等待服务端发送SYN断开连接，如果服务端一直没有发送断开，客户端会等待tcp_fin_timeout时间断开socket连接，如果有大量的FIN_WAIT2状态，就要检查服务端的应用程序是否调用close()关闭连接，如果一时查不出原因，可以修改内核参数tcp_fin_timeout的时间，比如：net.ipv4.tcp_fin_timeout=30。

而对于TIME_WAIT，它只会出现在主动断开方，也就是上图中的客户端。之所以有TIME_WAIT这个状态而不是直接编程CLOSED状态主要有以下两个原因：
（1）、保证服务端能够正常收到最后一个ACK包，确保是正常断开，可靠释放；
（2）、防止数据错乱。假如没有这个TIME_WAIT状态，假设当前有一条连接，因某些原因先关闭，紧接着又以相同的四元组建立一条新的连接，由于TCP无法区分这两条连接有什么不同，就可能会发生这样的情况：发送数据可能会发送到上一条连接中，这就会出现一些数据混乱的问题。

TIME_WAIT状态有一个默认过期时间，默认是2MSL（最大生存时间），不同的操作系统默认的MSL是不一样的。如果有大量的TIME_WAIT，就会造成本地端口不释放，无法通过这个端口建立新的连接，如果本地端口都用完了，就会出现无法建立TCP连接来访问服务端了。

解决方法一般有两种（具体需要根据自身情况来定）:
1、调节内核参数，以CentOS为例，主要的参数有tcp_max_tw_buckets、tcp_tw_recycle、tcp_tw_reuse这三个配置项。
（1）、tcp_max_tw_buckets：该配置项用来防范简单的DoS攻击?，在某些情况下，可以适当调大，但绝对不应调小。
（2）、tcp_tw_recycle：该配置项可用于快速回收处于TIME_WAIT状态的socket以便重新分配。默认是关闭的，必要时可以开启该配置。
（3）、tcp_tw_reuse：开启该选项后，kernel会复用处于TIME_WAIT状态的socket，当然复用的前提是“从协议角度来看，复用是安全的”。
2、修改应用程序。
（1）、将TCP短连接改造为长连接。通常情况下，如果发起连接的目标也是自己可控制的服务器时，它们自己的TCP通信最好采用长连接，避免大量TCP短连接每次建立/释放产生的各种开销；如果建立连接的目标是不受自己控制的机器时，能否使用长连接就需要考虑对方机器是否支持长连接方式了。
（2）、通过getsockopt/setsockoptapi设置socket的SO_LINGER选项。