阅读目录

• 一、问题概述
• 二、关于close_wait
• 三、close_wait过多怎么办

回到顶部

一、问题概述

今天遇到个小问题。

我们的程序依赖了大数据那边的服务，大数据那边提供了restful接口供我们调用。

测试反映接口有问题，我在本地重现了。

我这边感觉抓包可能对分析问题有用，就用wireshark抓包了。然后发给大数据的同事看了下，是他们的问题。

然后就帮忙把问题解决了。

然后我这边重新测试，自己抓包了下，结果反而发现我方程序的一个问题。

下图，是我方和大数据方的交互数据包。

前三个为tcp连接建立，中间（序号4,5,6）为http请求响应，序号7-8为大数据方在请求完毕后关闭连接。

好了，看下面的图：（下面这个tcp状态变迁图网上到处都是，一定要学会看。）

我们重点关注下面红色部分：

当一个tcp实体（以我方为例），当我方和大数据方建立连接后，一直处于下面的established状态。

请求结束后，收到对方的FIN（下图红色的recv:FIN），我方回应ACK。（下图红色的send:ACK）。

然后我方进入了CLOSE_WAIT状态。

于是我就去cmd里面查看下：

果然存在这个close_wait状态的连接。

但是过了没特别久，一两分钟吧，这个状态自己消失了。（猜测是操作系统设置了close_wait超时时间，超时后主动发起fin请求断开连接）

暂时还没找到原因，大佬知道的话，还请告知下（我的是win7 64位）。

回到顶部

二、关于close_wait

这个状态要怎么才能进入下一个状态（LAST_ACK）呢？

看最上面的变迁图可以知道，我方tcp实体只要发起一个FIN即可。这个FIN怎么才能发起呢？

那就需要程序主动去关闭连接。

我看了下代码，果然是我方的httpclient使用完了没关闭。。（右边是我改后的代码,，下面把被关闭的两个变量的完整类名也展示一下）

org.apache.http.impl.client.CloseableHttpClient.CloseableHttpClient httpClient；
org.apache.http.client.methods.CloseableHttpResponse.CloseableHttpResponse response；

再看我上面的抓包的图的最后两行：

过了一定时间后，我方可能是在close_wait状态下持续了一定时间，触发了超时，主动向对方发起了FIN。

但是呢，对方其实已经关闭连接了，所以就返回了RST。（对方已经把连接删除了）

我把程序照上面修改后，重新请求了一次：（已经恢复正常了，如下）

回到顶部

三、close_wait过多怎么办

结论先说：改代码。

我方程序上线的话，部署在服务器上，close_wait过多，会导致新建立到大数据方的tcp连接失败（因为端口未释放的原因。）

这个问题，就是本端tcp实体（被动关闭的一端）没有主动关闭连接，大部分都是程序的问题。

要改的话，还是具体看看哪个程序有问题，找到具体的程序后（通过查看有大量close_wait状态的程序的pid），

再看程序里和哪个远端host的连接处于该状态。

然后再去程序里找对应的代码，修改即可。

部分网上的文章，是运维手动清楚close_wait。或者修改close_wait的超时时间。

这个可以解决问题，但是为了程序的健壮性着想，建议还是修改程序吧。

在服务器与客户端通信过程中，因服务器发生了socket未关导致的closed_wait发生，致使监听port打开的句柄数到了1024个，且均处于close_wait的状态，最终造成配置的port被占满出现“Too many open files”，无法再进行通信。

这个可以参考：

https://blog.csdn.net/wwd0501/article/details/78674170

https://blog.csdn.net/mnasd/article/details/80496032

如果，您认为阅读这篇博客让您有些收获，不妨点击一下

如果，您希望更容易地发现我，不妨点击一下，【关注我】

文中存在的观点/描述不正确的地方，欢迎指正。