深入分析服务端大量close_wait的根源

最新推荐文章于 2023-08-30 11:44:38 发布

路上的追梦人

最新推荐文章于 2023-08-30 11:44:38 发布

阅读量1.7k

点赞数 4

分类专栏：计算机网络文章标签： socket 网络

原文链接：https://www.jianshu.com/p/42918db85f19

版权

计算机网络专栏收录该内容

12 篇文章

订阅专栏

选自于：https://www.jianshu.com/p/42918db85f19

在开发网络服务器应用系统的时候，有时会碰到服务器有大量的socket处于CLOSE_WAIT状态，也无法关闭，导致服务器无法接受新的用户请求，最终导致服务器奔溃，系统重启才能解决。

为什么会出现大量的CLOSE_WAIT状态呢？

要解决这个问题，我们得先介绍一下socket断开过程中的四次挥手。

终止TCP连接的四次挥手

由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。
假设终止命令由client端发起。

CLOSED表示socket连接没被使用。
LISTENING表示正在监听进入的连接。
SYN-SENT表示正在试着建立连接。
SYN_RECEIVED进行连接初始同步。
ESTABLISHED表示连接已被建立。
CLOSEWAIT表示远程计算器关闭连接,正在等待socket连接的关闭。
FIN_WAIT1表示socket连接关闭,正在关闭连接。
CLOSING先关闭本地socket旌接,然后关闭远程socket连接,最后等待确认信息。
LASTACK远程计算器关闭后,等待确认信号。
FINWAIT2 socket连接关闭后,等待来自远程计算器的关闭信号。
TIMEWAIT连接关闭后,等待远程计算器关闭重发。

当clien端传输完成数据，或者需要断开连接时：

Client端发送一个FIN报文给Server端。(序号为M)
1.1. 表示要终止Client到Server这个方向的连接。
1.1. 通过调用close(socket) API。
1.3 表示Client不再会发送数据到Server端。(但Server还能继续发给Client端)
1.4 Client状态变为FIN_WAIT_1
Server端收到FIN后，发送一个ACK报文给Client端。(序号为M+1)
2.1 Server状态变为CLOSE_WAIT
2.2 Client收到序号为(M+1)的ACK后状态变为FIN_WAIT_2

Server端也发送一个FIN报文给Client端。(序号为N)
3.1 表示Server也要终止到Client端这个方向的连接。
3.2. 通过调用close(socket) API。
3.3 Server端状态变为LAST_ACK
Client端收到报文FIN后，也发送一个ACK报文给服务器。(序号N+1)
4.1 Client状态变为TIME_WAIT
Server端收到序号为(N+1)的ACK
5.1 Server的状态变为CLOSED.
等带2MSL之后
6.1 Client的状态也变为CLOSE.
至此，一个完整的TCP连接就关闭了。

两个基本问题：

Q: 我们看到CLOSE_WAIT出现在什么时候呢？
A: 在Sever端收到Client的FIN消息之后。
Q: 状态CLOSE_WAIT在什么时候转换成下一个状态呢？
A: 在Server端向Client发送FIN消息之后。

至此似乎明白了为什么会出现CLOSE_WAIT的状态：如果Server端一直没有向client端发送FIN消息(调用close() API)，那么这个CLOSE_WAIT会一直存在下去。

原因分析

从上面我们看到出现CLOSE_WAIT，说明Server端没有发起close()操作，这基本上是用户server端程序的问题了；通常情况下，Server都是等待Client访问，如果Client退出请求关闭连接，server端自觉close()对应的连接。

当然这也可能是业务实现上的需要，暂时不发送FIN，因为服务器可能还有数据要发往客户端，等发送完所有应用数据最后再发送FIN消息了；这个场景并不是这里我们讨论的大量COLSE_WAIT的问题了，因为这个还是可控的。

我们要讨论的场景是什么？我们先介绍两个系统调用，前面也提到并且用到的close(socket)和shutdown(socket,HOW)接着往下分析。

我们知道一个进程打开一个socket，然后此进程fork出子进程的时候，父进程已打开的socket是会被继承的，即子进程能够继续访问这个socket。其结果就是，一个socket被两个进程打开，一个父进程和一个子进程，此时socket的引用计数会变成2。

调用close(socket)时，内核先检查socket上的引用计数器：如果引用计数大于1，那么将这个引用计数减1，然后直接返回。如果引用计数等于1，那么内核才会真正关闭此socket。(通过发送FIN到对端来关闭TCP连接)
调用shutdown(socket，HOW)时，内核不会检查此socket对应的引用计数器，直接向对端发送FIN来关闭TCP连接。

据此分析，很大可能性是用户服务器的程序实现有问题导致的大量CLOSE_WAIT的socket，比如父进程打开了socket，然后通过fork出子进程来处理业务，父进程继续对网络请求进行监听，永远不会终止；当客户端发FIN过来的时候，处理业务的子进程处理此FIN消息，调用close()对本端进行关闭，然而这个close()调用只是把socket的引用计数器减1，因为父进程还在运行，socket并没关闭，这样就导致系统中又多了一个CLOSE_WAIT的socket，长此以往，就这样了。