对于TCP的挥手过程的认识，我认为可以分为三个等级：
如果你能把TCP的三次握手和四次挥手的流程说出来，至少说明你上课听讲了。
如果你能完整的描述TIME_WAIT 和 CLOSE_WAIT 状态,那至少说明你对挥手过程深入了解了。
如果你在项目开发过程中遇到过TIME_WAIT 和 CLOSE_WAIT的问题并能够解决这类问题，那说明你是高手了。
今天我们来说下TCP的CLOSE_WAIT状态，搞不明白的是昨天写了一个TCP 的TIME_WAIT，竟然没有被推荐，郁闷，原因是内容太旧，写的人太多了。大隐隐于市，原来今日头条那么多网络高手。
什么是CLOSE_WAIT
说到CLOSE_WAIT 和TIME_WAIT 我们需要看看最原始的四次挥手过程
对Client而言：
TCP 的Client发出FIN结束报文以后，client 进入TIME_WAIT_1状态，从而等待server的ACK , 收到ACK以后表明从client到server的连接断开了，此时client进入TIME_WAIT_2状态。
如果client收server传来的FIN以后，client 会发送一个ACK，然后进入TIME_WAIT状态。client需要在TIME_WAIT保持2MSL的时间才会进入CLOSED状态。
对Server 而言
当server 收到client发过来的断开连接的FIN包以后，会进入CLOSE_WAIT状态，并向上层应用通告这个消息，同时返回ACK ，至此client到server的连接断开了。
上层应用处理完相关的信息以后会向client发送FIN， 进入LAST_ACK状态，等待client返回ACK ,如果收到ACK，至此server到client的连接断开，server进入CLOSED状态。
所以TIME_WAIT 表示主动关闭，是主动关闭连接时形成的，CLOSE_WAIT 表示被动关闭 ，是被动关闭连接是形成的。
深入CLOSE_WAIT
综合上面的挥手流程，我们应该知道
CLOSE_WAIT是TCP关闭连接过程中的一个正常状态
CLOSE_WAIT只会发生在被动关闭链接的那一端
CLOSE_WAIT除非你杀进程，close_wait是不会自动消失的。
另外根据挥手协议:server的上层应用处理完相关信息以后会向client发送FIN ，所以TCP状态会从CLOSE_WAIT进入LAST_ACK状态。CLOSE_WAIT 状态在服务器停留时间很短，如果你发现大量的 CLOSE_WAIT 状态，那么就意味着被动关闭的一方没有及时发出 FIN 包。
所以CLOSE_WAIT过多至少有如下几种可能：
应用程序问题：如果在应用程序中忘记了 close 相应的TCP连接，那么Y也就不会发出 FIN 包，进而导致 CLOSE_WAIT ；
应用程序响应太慢：应用程序不能及时响应client的关闭请求也会导致CLOSE_WAIT状态的堆积。
Accept backlog太大：Accept 的 backlog太大，设想突然遭遇大访问量的话，即便响应速度不慢，也可能出现来不及消费的情况，导致多余的请求还在队列里就被对方关闭了。