CLOSE_WAIT

最近遇到的一个关于socket.close的问题,在某个应用服务器出现的状况(执行netstat -np | grep tcp): 

tcp        0      0 10.224.122.16:50158         10.224.112.58:8788          CLOSE_WAIT

tcp        0      0 10.224.122.16:37655         10.224.112.58:8788          CLOSE_WAIT

tcp        1      0 127.0.0.1:32713             127.0.0.1:8080              CLOSE_WAIT

tcp       38      0 10.224.122.16:34538         10.224.125.42:443           CLOSE_WAIT

tcp       38      0 10.224.122.16:33394         10.224.125.42:443           CLOSE_WAIT

tcp        1      0 10.224.122.16:18882         10.224.125.10:80            CLOSE_WAIT

tcp        1      0 10.224.122.16:18637         10.224.125.10:80            CLOSE_WAIT

tcp        1      0 10.224.122.16:19655         10.224.125.12:80            CLOSE_WAIT

........................................

 

总共出现了200个CLOSE_WAIT的socket.而且这些socket长时间得不到释放.下面我们来看看为什么会出现这种大量socket的CLOSE_WAIT情况

 

首先我们要搞清楚的是,这个socket是谁发起的,我们可以看到122.16这台机器开了很多端口,而且端口号都很大,125.12 或者125.10上的端口都是很常见服务器端口,所以122.16上这么多CLOSE_WAIT

的socket是由122.16开启的,换句话说这台机器是传统的客户端,它会主动的请求其他机器的服务端口.

 

要搞清楚为什么会出现CLOSE_WAIT,那么首先我们必须要清楚CLOSE_WAIT的机制和原理.

 

假设我们有一个client, 一个server.

 

当client主动发起一个socket.close()这个时候对应TCP来说,会发生什么事情呢?如下图所示.

 

 

 

client首先发送一个FIN信号给server, 这个时候client变成了FIN_WAIT_1的状态, server端收到FIN之后,返回ACK,然后server端的状态变成了CLOSE_WAIT.

接着server端需要发送一个FIN给client,然后server端的状态变成了LAST_ACK,接着client返回一个ACK,然后server端的socket就被成功的关闭了.

 

从这里可以看到,如果由客户端主动关闭一链接,那么客户端是不会出现CLOSE_WAIT状态的.客户端主动关闭链接,那么Server端将会出现CLOSE_WAIT的状态.

而我们的服务器上,是客户端socket出现了CLOSE_WAIT,由此可见这个是由于server主动关闭了server上的socket.

 

那么当server主动发起一个socket.close(),这个时候又发生了一些什么事情呢.

 

从图中我们可以看到,如果是server主动关闭链接,那么Client则有可能进入CLOSE_WAIT,如果Client不发送FIN包,那么client就一直会处在CLOSE_WAIT状态(后面我们可以看到有参数可以调整这个时间).

 

那么现在我们要搞清楚的是,在第二中场景中,为什么Client不发送FIN包给server.要搞清楚这个问题,我们首先要搞清楚server是怎么发FIN包给client的,其实server就是调用了

socket.close方法而已,也就是说如果要client发送FIN包,那么client就必须调用socket.close,否则就client就一直会处在CLOSE_WAIT(但事实上不同操作系统这点的实现还不一样,


http://ahuaxuan.iteye.com/blog/657511



### Close_WAIT 状态原因分析 `CLOSE_WAIT` 是一种 TCP 连接状态,表示被动关闭的一方已经收到对方发送的 FIN 数据包并进入 `FIN_WAIT_2` 状态,但由于本地应用程序未调用 `close()` 方法来确认关闭操作,因此该连接仍然保持打开状态[^4]。 这种状态通常表明客户端或服务器端的应用程序未能及时释放已不再使用的套接字资源。如果大量连接停留在 `CLOSE_WAIT` 状态,则可能是因为应用程序存在逻辑缺陷或者配置不当所致[^2]。 --- ### 解决 CLOSE_WAIT 的方法 #### 1. **检查应用层代码** 应用程序需要显式地调用 `close()` 或者其他类似的函数来关闭不再使用的套接字。如果没有正确处理这些关闭请求,就会导致连接滞留在 `CLOSE_WAIT` 状态。开发者应审查相关部分的源码,确保每次读写完成后都执行了必要的清理工作。 #### 2. **调整超时设置** 可以为某些长期运行的服务设定合理的闲置时间限制,在检测到某个连接超过指定时限后自动触发其终止流程。例如通过修改 Linux 内核参数实现更高效的管理策略: ```bash net.ipv4.tcp_fin_timeout = 30 # 缩短 FIN 超时时长至 30 秒 ``` 上述命令可以减少等待的时间窗口大小从而加快资源回收速度。 #### 3. **监控工具辅助诊断** 使用诸如 netstat、ss 等命令可以帮助识别哪些进程产生了过多的 `CLOSE_WAIT` 链接以及它们对应的 PID 和名称信息: ```bash # 查看当前所有 close_wait 数量及其所属程序 netstat -anp | grep CLOSE_WAIT ``` 进一步定位问题所在之后再针对性修复相应模块中的 bug。 #### 4. **增强日志记录功能** 对于难以重现的问题场景,增加详细的调试信息有助于快速找到根本原因。比如打印出每一次 socket 创建销毁的过程及相关上下文数据以便后续排查使用。 --- ### 总结 尽管 `TIME_WAIT` 主要是由于协议设计本身引起的现象,而 `CLOSE_WAIT` 则更多反映出了上层业务层面存在的隐患。针对后者采取有效的预防措施能够显著降低此类事件发生的概率,并提升整体系统的稳定性与性能表现[^3]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值