CLOSE_WAIT 状态的连接很多

• 代码问题：短连接模式，忘记 close 连接，就不会发出 FIN 包，导致连接处于 CLOSE_WAIT状态；或者程序在close 连接之前陷入死循环或者执行时间过长；
• backlog太大：backlog太大这里指的accept 的连接队列设置的太大，这个参数是在服务端创建ServerSocket作为参数传入的，默认为50，支持自定义，设置的太少容易出现连接reset或者拒绝，太大如果服务端处理连接不及时会放到accept队列等待太长时间。accept队列以及socket 连接建立流程如下图：

上图所示，这里有两个队列：syns queue(半连接队列）；accept queue（全连接队列）。我们很多时候排查网络问题时也需要考虑到accept queue，很多场景需要对accept queue 大小做些调整

如何判断是否需要调整 accept queue（全连接队列）大小？

答：例如我们机器并发量很高，accept queue（全连接队列） 可能会出现不够用的情况，会出现类似connection reset 和 connection timeout 异常，这个取决于机器上tcp_abort_on_overflow 的设置，不同值服务端不同处理机制：

tcp_abort_on_overflow为0：连接建立过程中三次握手第三步时，发生全连接队列满了，server扔掉client 发过来的ack，那么client 会重新发送ack，直到超时，所以客户端会出现连接超时（connection timeout ）；

tcp_abort_on_overflow为1：遇到全连接队列满了，server会发一个reset包给client，表示废掉这个这个连接，这个握手过程无效，客户端会看到很多connection reset by peer的错误；

查看服务器处理accept queue 队列满时的处理机制：

netstat -s | grep "listen"