TCP 状态转换与（close_wait,time_wait问题)

淡淡的烟草味﹌ 2023-06-01 11:10 5阅读 0赞

TCP 状态转换

TCP的状态转换主要分应用端状态转换以及服务端状态的转换

状态：

描述状态转换之前先需要了解有TCP相关状态

<table> 
 <tbody> 
 <tr> 
 <td> 状态 </td> 
 <td> 描述 </td> 
 </tr> 
 <tr> 
 <td> CLOSED </td> 
 <td> 初始状态 </td> 
 </tr> 
 <tr> 
 <td> LISTEN </td> 
 <td> 服务端处于监听状态，可以接受连接 </td> 
 </tr> 
 <tr> 
 <td> SYN_RCVD </td> 
 <td> 握手状态：接受了SYN报文，等待客户端ACK报文 </td> 
 </tr> 
 <tr> 
 <td> SYN_SENT </td> 
 <td> 握手状态：客户端执行连接操作，发送SYN报文，等待服务端消息 </td> 
 </tr> 
 <tr> 
 <td> ESTABLISHED </td> 
 <td> 连接已经 </td> 
 </tr> 
 <tr> 
 <td> FIN_WAIT_1 </td> 
 <td> 客户端发送了FIN报文，等待服务端回复 </td> 
 </tr> 
 <tr> 
 <td> FIN_WAIT_2 </td> 
 <td> 客户端发送了FIN报文，服务端已经回复 </td> 
 </tr> 
 <tr> 
 <td> TIME_WAIT </td> 
 <td> 收到了对方的FIN报文，并发送出了ACK报文，等2MSL后返回CLOSED可用状态 </td> 
 </tr> 
 <tr> 
 <td> CLOSE_WAIT </td> 
 <td> 收到对方的FIN报文，此次返回ACK报文给对方，然后等待数据传输完毕后进行关闭之间的状态 </td> 
 </tr> 
 <tr> 
 <td> LAST_ACK </td> 
 <td> 发送确认关闭的FIN报文，等待对方返回ACK </td> 
 </tr> 
 <tr> 
 <td> CLOSING </td> 
 <td> 如果双方尝试同时close一个Socket，同时发送FIN报文，会出现此状态 </td> 
 </tr> 
 </tbody> 
</table>

TCP的标志位

<table> 
 <tbody> 
 <tr> 
 <td> 标志位 </td> 
 <td> 描述 </td> 
 </tr> 
 <tr> 
 <td> ACK </td> 
 <td> 置1时表示确认号，为0的时候表示数据段不包含确认信息，确认号被忽略 </td> 
 </tr> 
 <tr> 
 <td> PSH </td> 
 <td> 置1时请求的数据段在接收方得到后就可直接送到应用程序，而不必等到缓冲区满时才传送。 </td> 
 </tr> 
 <tr> 
 <td> SYN </td> 
 <td> 置1时用来发起一个连接 </td> 
 </tr> 
 <tr> 
 <td> FIN </td> 
 <td> 置1时表示发端完成发送任务。用来释放连接，表明发送方已经没有数据发送了 </td> 
 </tr> 
 <tr> 
 <td> RST </td> 
 <td> 置1时重建连接 </td> 
 </tr> 
 <tr> 
 <td> URG </td> 
 <td> 紧急指针，告诉接收TCP模块紧要指针域指着紧要数据 </td> 
 </tr> 
 </tbody> 
</table>

应用端状态转换

1.  初始状态CLOSE
2.  发送SVN后，状态变更为：SYN\_SENT
3.  接收服务器返回信息后，状态变更为：ESTABLISHED
4.  发送FIN后此时服务端也在发送FIN，则状态变更为：CLOSING
5.  此时接收到ACK，但是没有接收到FIN，等待数据传输完成，则状态变更为：FIN\_WAIT\_2
6.  此时马上接收到接收:FIN ACK，则状态变更为：TIME\_WAIT
7.  等待2MSL后返回CLOSED

服务端状态转换

1.  初始状态CLOSE
2.  服务端开打监听后，状态变更为：LISTEN
3.  接收:SYN消息，状态变更为：SYN\_RCVD
4.  发送SYN,ACK并接收ACK，状态变更为：ESTABLISHED
5.  接收:FIN 发送:ACK，状态变更为：CLOSE\_WAIT
6.  完成数据传输，发送FIN，状态变更为：LAST\_ACK
7.  获得应用返回的ACK，状态变更为：CLOSE

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Fsenp3_size_16_color_FFFFFF_t_70][]

Close\_Wait引发的问题  
Close\_Wait会占用一个连接，网络可用连接小。数量过多，可能会引起网络性能下降，并占用系统非换页内存。 尤其是在有连接池的情况下(比如HttpRequest)  
会耗尽连接池的网络连接数，导致无法建立网络连接。

解决方法

下面来讨论下这两种情况的处理方法，优化系统内核参数解决TIME\_WAIT可能很容易，可以通过修改/etc/sysctl.conf文件解决；

但是应对CLOSE\_WAIT的情况还是需要从程序本身出发。因为发生TIME\_WAIT的情况是服务器自己可控的，要么就是对方连接的异常，要么就是自己没有迅速回收资源，总之不是由于自己程序错误导致的。从上面的图可以看出来，如果一直保持在CLOSE\_WAIT状态，那么只有一种情况，就是在对方关闭连接之后服务器程序自己没有进一步发出FIN信号，一般原因都是TCP连接没有调用关闭方法。换句话说，就是在对方连接关闭之后，程序里没有检测到，或者程序压根就忘记了这个时候需要关闭连接，于是这个资源就一直被程序占着。这种情况，通过服务器内核参数也没办法解决，服务器对于程序抢占的资源没有主动回收的权利，除非终止程序运行，一定程度上，可以使用TCP的KeepAlive功能，让操作系统替我们自动清理掉CLOSE\_WAIT连接。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Fsenp3_size_16_color_FFFFFF_t_70]: /images/20230601/75033db31cc44c99b13f285cfa8bbe21.png