456主机测评
一、问题描述
最近一直忙得很，好久没写博客。前两天，微信收到个好友申请，说是想问问close_wait的事情。
找他问了些详细信息，大概了解到，他们后端服务是tomcat 7， jdk 7，centos，传统的spring + hibernate + spring mvc 结构。
业务不清楚，客户端主要是微信小程序。
目前的症状就是，服务器上有大量的close_wait状态的连接，在他们的服务器上执行 netstat 命令，如下图：
从上图看出，他们的服务器ip为 172.18.206.252（反正是内网ip，不用打码了吧），端口是443，那应该就是https服务了。
客户端ip没有重样的，应该都是些全国各地的ip了。
close_wait的危害在于，在一个进程上打开的文件描述符超过一定数量，（在linux上默认是1024，可修改），新来的socket连接就无法建立了，因为每个socket连接也算是一个文件描述符。
会报：Too many open files。
这里详细说一下，linux上，每个进程，都有其自身的资源限制，比如最大可以打开的文件描述符数量。
比如下面，我查看了某个java进程的资源限制。
这部分，可以查看以下链接：
https://feichashao.com/ulimit_demo/
二、问题分析
我回想了一下，之前在博客园上是写了一篇close_wait相关的，叫：tcp连接出现close_wait状态？可能是代码不够健壮
在那篇文章里，虽然我那也是服务端出现的，但是服务端其实是作为客户端，去调用大数据服务。严格来说，和今天遇到的场景不一样：
1、之前博客里的场景：服务端调用大数据，大数据关闭连接，（发起fin，服务器回ack）。此时，因为代码不严谨，服务端没有再向大数据发起close请求，
所以服务端与大数据的连接，在服务端上表现为close_wait。在大数据那边，状态应该是属于FIN_WAIT_2。参考下图：
2、这次遇到的场景：是作为小程序的客户端访问了服务器，服务器不知道为啥处于close_wait。
所以，一开始我也没有思路，网上查了下，有人说是tomcat 的https有bug，更多的直接教你怎么用运维手段解决。
后来，这个朋友提到，他们服务器的一个接口，是会去调用微信服务器，生成二维码，而且，他们的监控显示，该方法耗时较长。
这时，我想到一个问题是：如果服务端在处理过程中，耗时较长，（进入死循环、等锁、下游服务响应慢等），假设20s才返回，
但是客户端明显不可能等那么久，一般5-10s就超时了。超时了，客户端发起fin，服务器回ack，此时，
服务器端应该就是close_wait。
在网上搜索时，也发现网上其实有这方面案例了，比如：
我大概率估计，就是这个原因。但猜测只是猜测，还是要实践一下。
三、验证猜测
1、准备工作
我这边的一台开发服务器是windows的，装了wireshark，方便抓包，上面装了tomcat 8.5，一会直接把war包丢进去跑就完了。
我的打算是，修改目前工程的一个controller接口，让其睡眠30s再返回。 客户端的话，我用了httpclient，写了个测试类，直接去调用服务器的controller接口。
然后，用netstat观察该连接的状态变化，同时，wireshark辅助查看网络包的发送情况。
controller代码如下：
客户端代码：
pom.xml加上：
<dependency> <groupId>org.apache.httpcomponents</groupId> <artifactId>httpclient</artifactId> <version>4.5.3</version> </dependency>
工具类如下：
import com.alibaba.fastjson.JSON; import com.ceiec.base.common.utilities.AppConstants; import org.apache.commons.io.IOUtils; import org.apache.commons.lang3.time.StopWatch; import org.apache.http.HttpEntity; import org.apache.http.client.ClientProtocolException; import org.apache.http.client.config.RequestConfig; import org.apache.http.client.methods.CloseableHttpResponse; import org.apache.http.client.methods.HttpPost; import org.apache.http.entity.StringEntity; import org.apache.http.impl.client.CloseableHttpClient; import org.apache.http.impl.client.HttpClients; import org.apache.http.message.BasicHeader; import org.apache.http.protocol.HTTP; import org.apache.http.util.EntityUtils; import org.slf4j.Logger; import org.slf4j.LoggerFactory; import java.io.IOException; import java.util.HashMap; public final class MyHttpUtils { private static int TIMEOUT = 5000; private static final String APPLICATION_JSON = "application/json"; private static final String CONTENT_TYPE_TEXT_JSON = "text/json"; private static Logger logger = LoggerFactory.getLogger(MyHttpUtils.class); /** * POST方式提交请求 * * @param url 请求地址 * @param json JSON格式请求内容 * @throws IOException */ public static String doPost(String url, String json){ if (json == null) { HashMap<String, String> map = new HashMap<>(); json = JSON.toJSONString(map); } //计时 StopWatch timer = new StopWatch(); timer.start(); RequestConfig defaultRequestConfig = RequestConfig.custom().setSocketTimeout(TIMEOUT).setConnectTimeout(TIMEOUT).setConnectionRequestTimeout(TIMEOUT).build(); CloseableHttpClient httpClient = HttpClients.custom().setDefaultRequestConfig(defaultRequestConfig).build(); HttpPost httpPost = new HttpPost(url); httpPost.addHeader(HTTP.CONTENT_TYPE, APPLICATION_JSON); StringEntity stringEntity = new StringEntity(json, AppConstants.UTF8); stringEntity.setContentType(CONTENT_TYPE_TEXT_JSON); stringEntity.setContentEncoding(new BasicHeader(HTTP.CONTENT_TYPE, APPLICATION_JSON)); httpPost.setEntity(stringEntity); httpPost.setConfig(defaultRequestConfig); CloseableHttpResponse response = null; String responseContent = ""; try { response = httpClient.execute(httpPost); int status = response.getStatusLine().getStatusCode(); logger.debug("response status: " + status); if (status >= 200 && status < 300) { HttpEntity entity = response.getEntity(); if (entity == null) { return null; } responseContent = EntityUtils.toString(entity,"UTF-8"); return responseContent; } else { throw new ClientProtocolException("Unexpected response status: " + status); } } catch (Exception e) { logger.error("error occured.{}",e); throw new RuntimeException(e); } finally { timer.stop(); logger.info("doPost. requestUrl:{}, param:{},response:{},took {} ms", url,json,responseContent,timer.getTime()); IOUtils.closeQuietly(response); IOUtils.closeQuietly(httpClient); } } }
Test类：
public class Test { public static void main(String[] args) { MyHttpUtils.doPost("http://192.168.19.94:8080/CAD_WebService/getValue.do",null); } }
好了，在正式开始之前，说下MyHttpUtils中标红的那个方法：RequestConfig.custom().setSocketTimeout(TIMEOUT) 这个setSocketTimeout表示设置等待服务器端响应超时的时间，这里设为5000，意为5s
2.测试验证
这里，准备就绪了，马上开始，我们启动了服务端，然后客户端发起调用，下面是我这边的抓包（服务端视角）：
这个图，咱们先看抓包：
这个包，是在服务器192.168.19.94上抓的。抓的是服务器上8080端口，和我本地pc 10.15.4.46之间的网络包。
我们分析下：
序号为1/2/3的包： 三次握手，建立连接；
序号4的包：发起http请求，请求的controller方法，会睡眠30s
序号5的包：对序号4的包的ack。注意，此时时间为14:02:11
序号6的包：此时时间已经过去5s，客户端等不及了，（就你猴急？），于是不耐烦了，老子不等了，发了个fin过来，要分手。
序号7的包：服务器说：要分手？知道了。
此时服务器在干嘛，不好意思，要睡30s，这时才睡了5s，还没醒。
说完了包，我们再看看那个cmd，里面展示的是8080端口上的连接，可以看出来，此时该连接正处于close_wait状态。
。。。
25s后。。。
25s后，服务器终于醒了，睡得不错，给客户端发响应吧（序号8），但是呢，9号包可以看出来，我的开发机给服务器回了rst。
意思就是：我不认识你。（因为前面我的开发机就提了分手。。。）
3.gif图完整回放
由于是一边写一边截图的，所以有些图等写完了再想看的时候，已经没有了。
下面截个完整的，这里，把客户端超时改为20s，方便查看：
1、服务端视角，可以看到，超时前，为established，超时后，为close_wait。
2.客户端视角
四、说到底，问题怎么解决
扯了那么多，服务器出现大量close_wait，到底怎么解决？ 指标不治本的方法我就不说了，直接网上搜下，改改linux参数即可。
这篇博客主要是治本，讲了close_wait出现的一种情况：
服务端接口耗时较长，客户端主动断开了连接，此时，服务端就会出现 close_wait。
那怎么解决呢？看看代码为啥耗时长吧。
另外，如果代码不规范的话，说不定在收到对方发起的fin后，自己根本就不会给人家发fin。（比如netty自己开发的框架那种）
没啥好说的，检查自己的代码吧，反正close_wait基本就是自己这边的问题了。
如果觉得有点帮助，麻烦点个推荐哈。
ps：我这里用chrome测过，用fiddler的composer也搞过，发现有些客户端会一直等响应，过了很久才会主动去发fin，所以用了httpclient测试。
pps：tomcat在什么情况会主动发起fin？其实我也想讲讲，因为和http的connection：keep-alive这些，都有点关系，放这篇文章的话，主题就有点不集中，放下篇吧。
网络上，我也发现有些差不多场景的文章：
https://blog.csdn.net/auo67284/article/details/101102578
- 海报
