服务端大量CLOSE_WAIT问题.md
### 现象描述：
服务端使用了quartz框架之后，刚开始启动jetty容器的时候，请求正常，大概几个请求完了之后，部分Mac机子出现客户端一直在请求，但是返回给客户端的信息是异常，服务端压根没有收到请求,或者收到请求代码执行的非常慢
使用命令 lsof -i:8080查看进程数，发现大量进程存在，并且状态是CLOSE_WAIT；正常情况下是在执行客户端请求的时候进程数增加，但随之会关闭。
CLOSE_WAIT：客户端关闭了socket连接，发送了FIN报文，服务端也发送了ACK报 文，此时客户端处于FIN_WAIT_2状态，服务端处于CLOSE_WAIT状态，问题的原因是服务端没有发送第二个FIN报文导致的。
可能的原因TCP请求：
- mongo
- redis
- mq
- mysql
因为quartz引入了新的mysql连接，所以估计是连接超上限的问题
#### 解决方案
- msyql 数据库的processList表，设置全局的超时时间100ms,得到验证，问题解决
- 设置连接池，以及空闲连接释放时间
### 参考网站
[服务端大量CLOSE_WAIT问题的解决](http://www.liuhaihua.cn/archives/45802.html)
分享到：
相关推荐
在 CLOSE_WAIT 和 FIN_WAIT_2 状态中，系统可能会出现崩溃的问题。这是因为如果对方在第三次握手的时候出问题，例如发 FIN 包的时候，丢了这个包，然而这边一直处在 FIN_WAIT_2 状态，TCP/IP 并没有设置这个状态的...
理论上，服务器应该尽快发送自己的FIN标志来回应客户端的关闭请求，但如果没有及时这样做，就可能导致CLOSE_WAIT状态持续过久，从而引发问题。 **CLOSE_WAIT错误的原因** 1. **代码实现不当**：服务器端的程序逻辑...
大量CLOSE_WAIT状态可能意味着应用程序存在错误，没有及时关闭不再使用的连接，或者由于CPU过载或其他原因导致应用无法及时处理关闭操作。 总结： 系统调优时，理解和处理TIME_WAIT和CLOSE_WAIT状态是关键。TIME_...
5. FIN_WAIT1：主动关闭（active close）端应用程序调用 close，于是其 TCP发出 FIN 请求主动关闭连接，之后进入 FIN_WAIT1 状态。 6. CLOSE_WAIT：被动关闭（passive close）端 TCP 接到 FIN。 7. FIN_WAIT2：主动...
1. **客户端发起断开连接**（FIN=1, seq=a）：客户端发送连接断开请求，进入FIN_WAIT_1状态。 2. **服务端确认断开请求**（ACK=1, ACKnum=a+1）：服务端收到客户端的断开请求后，发送确认信息，进入CLOSE_WAIT状态。...
Linux服务器上的网络连接状态是监控和管理服务器性能的关键部分，特别是对于处理大量网络通信的服务而言。TCP（传输控制协议）是互联网上应用最广泛的协议之一，它为两个通信端点提供可靠的、面向连接的数据传输服务...
- **服务端**接收到该请求后，回应一个带有ACK标志的确认报文，并进入`CLOSE_WAIT`状态。 - **服务端**关闭应用层程序后，向客户端发送带有FIN标志的TCP报文。 - **客户端**接收到服务端的FIN报文后，发送一个带有...
2. 第二次挥手：服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序列号值 +1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT 状态。 3. 第三次挥手：如果服务端也想断开连接...
客户端在收到服务端发来的确认后，状态由`FIN_WAIT_1`变为`FIN_WAIT_2`，表示客户端已经完成了第一次挥手，正在等待服务端关闭连接。值得注意的是，在这个阶段，客户端仍然可以接收服务端发来的数据。 **四、服务端...
- **CLOSE_WAIT**：服务端收到 FIN 后进入此状态，等待应用层关闭连接。过多的 CLOSE_WAIT 可能表明客户端未正确关闭连接，或者 CPU 繁忙导致未及时执行 close。 三、最佳实践 在使用 HttpClient 进行 RPC 调用时...
在实际应用中，大量TIME_WAIT和CLOSE_WAIT状态的存在会导致服务器的连接资源被浪费甚至占满，可能导致服务器拒绝服务。为了解决这个问题，可以调整系统参数： 1. tcp_tw_recycle：开启快速回收TIME_WAIT状态的...
理解这些状态对于调试网络问题和优化服务端性能非常重要。 - CLOSE_WAIT：服务器接收了客户端的FIN请求，但服务器应用层还没有完成数据发送，等待确认关闭。 - FIN_WAIT2：客户端已发送FIN，等待服务器的ACK，表示...
在处理MQTT协议时，Netty的非阻塞I/O模型非常适合处理大量并发连接，因为它能有效地减少CPU资源的消耗。 MQTT协议本身具有三种质量服务级别（QoS，Quality of Service），分别是0、1、2，分别对应至少一次、至少一...
m_PortList.SetItemText(i,2,"CLOSE-WAIT"); break; case MIB_TCP_STATE_CLOSING: m_PortList.SetItemText(i,2,"CLOSING"); break; case MIB_TCP_STATE_LAST_ACK: m_PortList....
1. 客户端主动调⽤关闭连接的函数，发送 FIN 报⽂，代表客户端不会再发送数据了，进⼊ FIN_WAIT_1 状态。 2. 服务端收到了 FIN 报⽂，然后回复⼀个 ACK 确认报⽂，此时服务端进⼊ CLOSE_WAIT 状态。 3. 服务端在 ...
TCP 127.0.0.1:1159 127.0.0.1:1110 CLOSE_WAIT 2992 TCP 127.0.0.1:1297 127.0.0.1:1110 CLOSE_WAIT 2992 TCP 127.0.0.1:1324 127.0.0.1:1110 CLOSE_WAIT 2992 ``` - 这里可以看到80端口被PID为2544的进程占用...
客户端进入`FIN_WAIT_1`状态。 - **第二次挥手**：服务器接收到FIN包后，发送一个ACK包作为确认，服务器进入`CLOSE_WAIT`状态。 - **第三次挥手**：服务器完成数据发送后，向客户端发送一个FIN包，请求终止连接。...
- **CLOSE_WAIT**: 服务器收到FIN包后，确认连接关闭请求，但仍有数据需要发送，进入此状态。 - **FIN_WAIT2**: 客户端收到服务器的ACK，进入此状态，等待服务器的FIN包。 - **LAST_ACK**: 服务器发送FIN包给...
此时，它进入FIN_WAIT_1状态。 2. 第二次挥手：另一方（被动关闭方）收到FIN后，发送一个ACK报文，确认序号为收到的序列号加1，然后进入CLOSE_WAIT状态，表示接收完了所有数据，但还有数据要发送。 3. 第三次挥手...
2. **第二次挥手**：服务器收到客户端的FIN报文后，必须发出确认报文ACK(u+1)，确认序号为客户端的序列号加1，此时服务器进入CLOSE_WAIT状态，客户端进入FIN_WAIT_2状态。 ``` Server → Client: ACK(u+1) ``` ...