netstat查看CLOSE_WAIT过多,轴二中贴吧

原创 社长  2019-08-06 09:47:07  阅读 89 次 评论 0 条
重庆专业seo
摘要:

现象:netstat查看很多CLOSE_WAIT,造成日志提示Too many open files错误,ssh远程不上去,很多服务报错,响应不了请求。解决思路:1、首先确认CLOSE_WAIT产生的链接、IP和端口,并对其抓包。然后再对正常情况的也抓包,并对两者进行对比和分析。2、排查结果是不正常的是因为没有回复关闭的包,即没有完成四次挥手。通过原理图,我们知道了CLOSE_WAIT是被动关闭的状态。什么意思呢?比如客户端发了个请求,正常情况下是会收到服务器响应一个状态的,即Response。

现象:

netstat查看很多CLOSE_WAIT,造成日志提示Too many open files错误,ssh远程不上去,很多服务报错,响应不了请求。

解决思路:

1、首先确认CLOSE_WAIT产生的链接、IP和端口,并对其抓包。然后再对正常情况的也抓包,并对两者进行对比和分析。

2、排查结果是不正常的是因为没有回复关闭的包,即没有完成四次挥手。

通过原理图,我们知道了CLOSE_WAIT是被动关闭的状态。什么意思呢?比如客户端发了个请求,正常情况下是会收到服务器响应一个状态的,即Response。当客户端读取了这个返回后,会主动告诉服务器收到了,关闭连接。

由于是客户端发起关闭连接的请求,在TCP协议下双方需要通过四个包的互发完成双向确认工作,才能最终关闭这个连接。

客户端要求关闭,此时客户端状态为 FIN_WAIT_1,同时向服务器发送了 FIN 包,服务器状态变更为CLOSE_WAIT;

当然,服务器需要对收到FIN包向客户端确认,于是服务器向客户端发送了 ACK 包,客户端因此变更状态为FIN_WAIT_2;

服务器处理了这个确认后,再次主动向客户端发送FIN包,同时自己状态变更为LAST_ACK,收到来自服务器FIN包的客户端也将自己状态变更为TIME_WAIT;

最后一步,客户端会对来自服务器的FIN包回复确认,服务器收到该ACK包后,将自己状态置为CLOSED,如此,整个关闭过程结束。

简单说就是,客户端 -》 服务器,我要关闭,服务器回复OK,并开始处理后续;服务器后续处理好后,再告诉客户端我可以关闭了,客户端确认,服务端关闭。

所以,出现CLOSE_WAIT状态的原因是,服务器一端因故没有向客户端发出FIN包,即服务端的LAST_ACK -- FIN -->客户端这步没能执行。

附:TCP的状态转移图

netstat查看CLOSE_WAIT过多,轴二中贴吧

关闭socket分为主动关闭(Active closure)和被动关闭(Passive closure)两种情况。前者是指有本地主机主动发起的关闭;而后者则是指本地主机检测到远程主机发起关闭之后,作出回应,从而关闭整个连接。将关闭部分的状态转移摘出来,就得到了下图:.

netstat查看CLOSE_WAIT过多,轴二中贴吧

产生原因:通过图上,我们来分析,什么情况下,连接处于CLOSE_WAIT状态呢?

在被动关闭连接情况下,在已经接收到FIN,但是还没有发送自己的FIN的时刻,连接处于CLOSE_WAIT状态。

通常来讲,CLOSE_WAIT状态的持续时间应该很短,正如SYN_RCVD状态。但是在一些特殊情况下,就会出现连接长时间处于CLOSE_WAIT状态的情况。

出现大量close_wait的现象,主要原因是某种情况下对方关闭了socket链接,但是我方忙与读或者写,没有关闭连接。代码需要判断socket,一旦读到0,断开连接,read返回负,检查一下errno,如果不是AGAIN,就断开连接。


本文地址:http://dxf6.com/post/263.html
版权声明:本文为原创文章,版权归 社长 所有,欢迎分享本文,转载请保留出处!
重庆专业seo
数据湾

发表评论


表情

还没有留言,还不快点抢沙发?