服务器TIME_WAIT和CLOSE_WAIT区别及解决方案，TCP的三次握手四次挥手详解

川长思鸟来 2022-07-16 15:51 92阅读 0赞

# 如何查看服务的TIME\_WAIT和CLOSE\_WAIT的数量 #

linux命令

netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

得到如下结果

TIME_WAIT 297
    ESTABLISHED 53
    CLOSE_WAIT 5

这几个东西是什么意思呢？

TIME_WAIT：表示主动关闭，通过优化系统内核参数可容易解决。
    CLOSE_WAIT：表示被动关闭，需要从程序本身出发。
    ESTABLISHED：表示正在通信

还是看不懂是不是？要想看懂这些东西，需要先了解这些东西是如何产生的，而要说到如何产生的，就不得不提TCP的三次握手和四次挥手，握手挥手机制是TCP能够建立稳点连接的基础，通讯之前需要进行握手挥手步骤以确认双方网络请求能够正常传输。

# 三次握手和四次挥手的过程 #

握手挥手的过程用大白话来说就是  
**3次握手**：1、听得到吗？2、听得到，你呢？3、我也听到了。然后才开始真正对话  
**4次挥手**：1、老师，下课了。2、好，我知道了，我说完这点。3、好了，说完了，下课吧。4、谢谢老师，老师再见

专业的表示如下  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxMzI5MzM0MzI_size_16_color_FFFFFF_t_70]  
**图中的SYN，ACK，SEQ，FIN是什么意思？**  
这些叫位码，即TCP的标识位，除了图中出现的这几种，还有其他的，总共有六种。

*  URG：(urgent紧急)
 *  ACK：(acknowledgement 确认)
 *  SYN：(synchronous建立联机)
 *  PSH：(push传送)
 *  FIN：(finish结束)
 *  RST：(reset重置)

这些用以标识TCP的状态，比较重要的是SYN，ACK，FIN。

**详解三次握手的过程**

1.  客户端向服务端发送SYN=1表示请求开始，同时随机生成一个`seq=x`，客户端进入`SYN_SEND（等待确认）`状态。
2.  服务端收到请求后要确认联机信息，向客户端回复`ack_seq=x+1，syn=1，ack=1`，同时随机生成一个服务端的`seq=y`，服务端进入`SYN_RECV（收到请求等待确认）`状态。
3.  客户端收到回复后检查`ack_seq`是否正确，以及位码`ack`是否为`1`，若正确客户端会再发送`ack_seq=y+1，ack=1.seq=x+1`给服务端，客户端进入`ESTABLISHED（建立连接）`状态。
4.  服务端收到后也进入`ESTABLISHED（建立连接）`状态。
5.  开始发送正文正常通讯

**详解四次挥手过程**

1.  客户端发送`FIN=1`表示断开请求，随机产生`seq=u`给服务端，客户端进入`FIN_WAIT_1（等待确认）`状态。
2.  服务端收到断开请求后回复客户端`ACK=1，ack_seq=u+1`，随机产生`seq=v`，进入`CLOSE_WAIT`等待关闭状态，为什么是等待关闭，是因为这个时候服务器可能数据还没有传输完成。
3.  客户端收到请求后进入`FIN_WAIT_2`等待释放状态。
4.  服务端处理完最后的数据，向客户端发送`FIN=1`表示断开请求，`ACK=1`，随机产生`seq=w，ack_seq=u+1`。服务端进入`LAST_ACK（等待确认）`状态。
5.  客户端收到请求后检查ack\_seq是否正确，以及位码`ack`是否为1，若正确客户端会再发送`seq=u+1，ack_seq=w+1，ack=1`给到服务器端，客户端进入`TIME_WAIT（等待一会(2MSL（max segment lifetime）)）`状态。
6.  服务端收到之后进入`CLOSE（关闭连接）`状态。
7.  等待`2MSL（max segment lifetime）`后，客户端进入`CLOSE`（关闭连接状态)。
8.  双方断开

# 为什么会产生TIME\_WAIT和CLOSE\_WAIT以及解决方案 #

**TIME\_WAIT**  
了解完上诉挥手过程详解之后，你应该明白TIME\_WAIT是主动关闭连接的一方保持的状态，主动关闭连接的一方发送完关闭请求且收到服务端确认关闭之后，进入`TIME_WAIT`状态，然后在保持这个状态`2MSL（max segment lifetime）`时间之后，彻底关闭回收资源。为什么要这么做？明明就已经主动关闭连接了为啥还要保持资源一段时间呢？这个是TCP/IP的设计者规定的，主要出于以下两个方面的考虑：

1.  防止上一次连接中的包，迷路后重新出现，影响新连接（经过2MSL，上一次连接中所有的重复包都会消失）
2.  在主动关闭方发送的最后一个`ack(FIN)`，有可能丢失，这时被动方会重新发fin, 如果这时主动方处于 `CLOSED` 状态 ，就会响应 `rst` 而不是 `ack`。所以主动方要处于 `TIME_WAIT` 状态，而不能是`CLOSED`。另外这么设计`TIME_WAIT` 会定时的回收资源，并不会占用很大资源的，除非短时间内接受大量请求或者受到攻击。

**TIME\_WAIT解决方案**  
解决方案很简单，通过修改`/etc/sysctl.conf`文件，服务器能够快速回收和重用那些TIME\_WAIT的资源

#表示开启SYN Cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击，默认为0，表示关闭 
    net.ipv4.tcp_syncookies = 1  
    #表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭 
    net.ipv4.tcp_tw_reuse = 1  
    #表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭 
    net.ipv4.tcp_tw_recycle = 1
    #表示如果套接字由本端要求关闭，这个参数决定了它保持在FIN-WAIT-2状态的时间 
    net.ipv4.tcp_fin_timeout=30

执行如下命令来立即生效

/sbin/sysctl -p

**CLOSE\_WAIT**  
通过挥手过程详解，我们知道`CLOSE_WAIT`是被动关闭的一方的状态，这个状态理论上应该很快消失，如果一直保持在`CLOSE_WAIT`状态，那么只有一种情况，就是在对方关闭连接之后服务器程序自己没有进一步发出`ack`信号。换句话说，就是在对方连接关闭之后，程序里没有检测到，或者程序压根就忘记了这个时候需要关闭连接。

**CLOSE\_WAIT解决方案**  
出现大量`CLOSE_WAIT`的现象，主要原因是某种情况下对方关闭了`socket`链接，但是我方忙与读或者写，没有关闭连接。那么为什么会没有关闭连接呢？可能有以下几点原因

*  例如I/O线程被意外阻塞，或者I/O线程执行的用户自定义Task比例过高，导致I/O操作处理不及时，链路不能被及时释放。
 *  使用了某些资源却忘记close释放。比如`HttpClient4`请求中忘记调用`InputStream.close()`来确认连接关闭，或者数据库连接池使用完了忘记释放都有可能导致。
 *  其他原因

总而言之，`close_wait`的出现一般是程序代码的问题而非服务器的问题，具体问题还需具体排查

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxMzI5MzM0MzI_size_16_color_FFFFFF_t_70]: /images/20220709/c0583eae007c47b9b4dbfe25f7c42aab.png