一、问题概述

今天遇到个小问题。

我们的程序依赖了大数据那边的服务，大数据那边提供了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实体（被动关闭的一端）没有主动关闭连接，大部分都是程序的问题。

要改的话，还是具体看看哪个程序有问题，找到具体的程序后（通过查看有大量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

原文地址：https://www.cnblogs.com/grey-wolf/p/9945637.html