姊妹篇:

服务器出现大量close_wait,我们来说说到底是怎么回事?(以tomcat为例)

  

一、问题概述

今天遇到个小问题。

我们的程序依赖了大数据那边的服务,大数据那边提供了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

tcp连接出现close_wait状态?可能是代码不够健壮的更多相关文章

  1. TCP/IP详解--TCP连接中TIME_WAIT状态过多

    TIMEWAIT状态本身和应用层的客户端或者服务器是没有关系的.仅仅是主动关闭的一方,在使用FIN|ACK|FIN|ACK四分组正常关闭TCP连接的时候会出现这个TIMEWAIT.服务器在处理客户端请 ...

  2. 服务器TCP连接中 TIME_WAIT 状态过多

    今天查看服务器的TCP连接数,发现其中 TIME_WAIT 状态的太多了: # netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a ...

  3. TCP连接中的状态

    1. 正常状态转换 我们用图 3-13 来显示在正常的 TCP 连接的建立与终止过程中,客户与服务器所经历的不同状态.读者可以对照图 3-12 来阅读,使用图 3-12 的状态图来跟踪图 3-13 的 ...

  4. close_wait状态和time_wait状态(TCP连接)

    1.CLOSE_WAIT的简单解决方案 不久前,我的Socket Client程序遇到了一个非常尴尬的错误.它本来应该在一个socket长连接上持续不断地向服务器发送数据,如果socket连接断开,那 ...

  5. TCP连接的状态与关闭方式及其对Server与Client的影响

    TCP连接的状态与关闭方式及其对Server与Client的影响 1. TCP连接的状态 首先介绍一下TCP连接建立与关闭过程中的状态.TCP连接过程是状态的转换,促使状态发生转换的因素包括用户调用. ...

  6. TCP连接(Time_Wait、Close_Wait)说明

    修改Time_Wait和CLOSE_WAIT时间 修改Time_Wait参数的方法 (在服务端修改)Windows下在HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlS ...

  7. TCP连接的状态与关闭方式,及其对Server与Client的影响

    1. TCP连接的状态 首先介绍一下TCP连接建立与关闭过程中的状态.TCP连接过程是状态的转换,促使状态发生转换的因素包括用户调用.特定数据包以及超时等,具体状态如下所示: CLOSED:初始状态, ...

  8. 转载:TCP连接的状态详解以及故障排查

    FROM:http://blog.csdn.net/hguisu/article/details/38700899 该博文的条理清晰,步骤明确,故复制到这个博文中收藏,若文章作者看到且觉得不能装载,麻 ...

  9. TCP连接问题之CLOSE_WAIT和TIME_WAIT过多

    参考博文 https://dengqsintyt.iteye.com/blog/2086485 Timeout waiting for connection异常排查:https://blog.csdn ...

随机推荐

  1. MYSQL类型与JAVA类型对应表

    MYSQL类型与JAVA类型对应表: 类型名称 显示长度 数据库类型 JAVA类型 JDBC类型索引(int) VARCHAR L+N VARCHAR java.lang.String 12 CHAR ...

  2. iOS 多线程简单使用的具体解释

    主线程 一个iOS程序执行后.默认会开启1条线程,称为"主线程"或"UI线程"(刷新UI界面最好在主线程中做.在子线程中可能会出现莫名其妙的BUG) 主线程的作 ...

  3. 深入浅出:全面理解SQL Server权限体系

    转自IT168  好文转载存档! [IT168 技术]权限两个字,一个权力,一个限制.在软件领域通俗的解释就是哪些人可以对哪些资源做哪些操作.在SQL Server中,"哪些人", ...

  4. asp.net操作cookie类,包含datatable批量存入cookie

    以下是类: public class CookieMgr { #region 快速储存Cookie /// <summary> /// 快速储存Cookie /// </summar ...

  5. crontab修改默认编辑器

    crontab默认编辑器为nano 修改crontab默认编辑器为vi或者其他的编辑器 可以用命令select-editor修改 改为3或者4 再用crontab -e 就是vim打开了

  6. mysql中json_object函数的使用?

    需求说明: 今天看了json_object函数的使用,在此记录下使用过程 操作过程: 1.使用json_object函数将一个键值对列表转换成json对象 mysql> select json_ ...

  7. python连接mysql数据库封装

    源码: import pymysql class MysqlConnect(object): # 魔术方法, 初始化, 构造函数 def __init__(self, host, user, pass ...

  8. WAMP运行分析

  9. Linux环境SVN命令行使用经验总结(转)

    在windows机器上开发得差不多了之后,打包传送到开发机编译,在开发机上解决编译错误. [缺点] 浪费时间在打包解包,机器间传输代码. 在windows机器上开发之后,check in代码进分支,在 ...

  10. PostgreSQL逻辑复制之slony篇

    Slony是PostgreSQL领域中最广泛的复制解决方案之一.它不仅是最古老的复制实现之一,它也是一个拥有最广泛的外部工具支持的工具,比如pgAdmin3.多年来,Slony是在PostgreSQL ...