netstat查看CLOSE_WAIT过多

现象：
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的状态转移图

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

产生原因：通过图上，我们来分析，什么情况下，连接处于CLOSE_WAIT状态呢？
在被动关闭连接情况下，在已经接收到FIN，但是还没有发送自己的FIN的时刻，连接处于CLOSE_WAIT状态。
通常来讲，CLOSE_WAIT状态的持续时间应该很短，正如SYN_RCVD状态。但是在一些特殊情况下，就会出现连接长时间处于CLOSE_WAIT状态的情况。
出现大量close_wait的现象，主要原因是某种情况下对方关闭了socket链接，但是我方忙与读或者写，没有关闭连接。代码需要判断socket，一旦读到0，断开连接，read返回负，检查一下errno，如果不是AGAIN，就断开连接。

参考链接：
https://www.geek-share.com/detail/2725892180.html

https://www.cnblogs.com/DannielZhang/p/8000496.html

https://www.geek-share.com/detail/2641203143.html