【tcp】TCP CLOSE_WAIT问题分析与定位

一、问题背景

某日，运维突然在群里突然丢出告警信息：

对象类型：主机
检测规则：NET.TCP.CLOSE.WAIT
告警内容：CLOSE_WAIT状态的TCP连接数大于500
....

image.png

上面告警信息已经说的很明白，CLOSE_WAIT状态的TCP连接数过多。
如果没有网络编程经验或对网络协议也不了解的人，看着这提示可能还是一脸懵逼不知所：

CLOSE_WAIT是什么鬼？
应用上很多连接第三方服务，到底是哪个服务有问题？
如何定位哪里的代码有问题？

二、问题分析

CLOSE_WAIT是什么？

image.png

image.png

CLOSE_WAIT是TCP的一个状态，它在ESTABLISHED（连接建立）基础上，收到对方的FIN且我方已回ACK，说白了就是对方已关闭我方尚未关闭。

如果有长时间和大量的TCP处于CLOSE_WAIT状态时，代码可能是问题的，原因是连接未正确关闭。

三、如何定位代码问题

如果系统代码简单，直接去看对应的代码有没可能导致连接未关闭即可。

如果系统代码量大且对接的第三方比较多，Linux平台可以通过netstat –nap | grep CLOSE_WAIT | grep ${pid} 看看哪个IP的连接出现了问题，再针对性的查找代码。

image.png

如果IP不够直观，可以通过IP反解析成域名，如：

image.png

IP地址反查域名在线工具
http://ip.yqie.com/iptodomain.aspx

当然如果本地环境可以复现最好不过了，可以在java.net.Socket或java.net.InetSocketAddress$InetSocketAddressHolder类的构造函数设置断点进行DEBUG

image.png

如果是生产环境，可以使用arthas(https://alibaba.github.io/arthas/)的stack命令，再加入IP过滤参数：

stack java.net.InetSocketAddress$InetSocketAddressHolder <init>

然后静静地等等Socket连接的建立即可知道产生连接代码的位置：

image.png

紧急的生产问题一般都会heap dump然后重启应用的，理论上可以通过MAT查找分析属性released状态为false的org.apache.http.impl.execchain.ConnectionHolder对象，再找到关联的incoming references对象CloseableHttpResponse（限于HttpClient）。

四、CLOSE_WAIT有什么影响？

如果代码有问题导致出现大量的CLOSE_WAIT会有什么影响呢，会影响业务吗？

Socket网络连接是一种资源，资源泄露肯定会有影响的。

首先对于系统的影响，每个Socket连接都需要一个随机端口号（作为Client），而系统理论上最大支持65535；
另外，在Linux中，网络连接是一个文件描述符，受限于系统ulimit –n参数，如果达到最大会导致“Too many open files”。

对于应用来说，应用一般是使用连接池，连接池是有最大数量限制的，如果没有及时释放导致连接泄露耗尽，线程就无法获取新的连接而影响业务。如果连接池的maxWait设置过大会造成线程阻塞时间过长，对于流量大的系统极容易造成大量请求阻塞甚至雪崩。

五、问题总结

1. 任何与资源相关的必须要确保关闭。Java有Closeable接口，可以通过try ... 语法糖自动关闭释放。

2. 了解基本的网络编程知识和相应的定位工具。

3. 开发阶段加强代码审查，压力测试也是发现资源问题的必要手段，同时生产环境配备必要的基础监控能力。

六、参考

CLOSE_WAIT问题分析与定位
https://mp.weixin.qq.com/s/_YmYVxwMOzZjETYlnbToZw

我是如何确认线上CLOSE_WAIT产生的原因及如何解决的
https://www.cnblogs.com/dukuan/p/8178728.html#4334700

简单的 HTTP 调用，为什么时延这么大？
https://mp.weixin.qq.com/s/lvs-3VXfrScdOQVRkkLyRw

作者：Bogon
链接：https://www.jianshu.com/p/7f7c5d30721f
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。