网络连接存在大量time_wait和close_wait的原因以及解决方法

Posted 2021-06-17 一口Linux

原文：https://www.toutiao.com/i6968678609267720717/

 

如果对tcp中的握手挥手不了解的同学，请先看这篇博客：《关于三次握手与四次挥手你要知道这些》。

 

四次挥手过程：

第一次挥手：主机A（可以是客户端，也可以是服务器端），设置Sequence Number和Acknowledgment Number，向主机B发送一个FIN报文段；此时，主机A进入FIN_WAIT_1状态；这表示主机A没有数据要发送给主机B了。

第二次挥手：主机B收到了主机A发送的FIN报文段，向主机A回一个ACK报文段，Acknowledgment Number为Sequence Number加1，主机A进入FIN_WAIT_2状态；主机B告诉主机A，我也没有数据要发送了，可以进行关闭连接了。

第三次挥手：主机B向主机A发送FIN报文段，请求关闭连接，同时主机B进入CLOSE_WAIT状态。

第四次挥手：主机A收到主机B发送的FIN报文段，向主机B发送ACK报文段，然后主机A进入TIME_WAIT状态；主机B收到主机A的ACK报文段以后，就关闭连接；此时，主机A等待2MSL后依然没有收到回复，则证明主机B已正常关闭，那好，主机A也可以关闭连接了。

大量time_wait

问题原因

《关于三次握手与四次挥手你要知道这些》中有关于“四次挥手释放连接时，等待2MSL的意义”的解释。正因为有2ML的存在，所以可能会发生大量time_wait存在的现象，从而影响服务器性能，甚至导致套接字数量达到服务器上限。

实际上，TIME_WAIT对于系统资源的消耗影响比较小，而真正需要考虑因为TIME_WAIT多而触碰到限制的是如下几个方面：

源端口数量 (
net.ipv4.ip_local_port_range)TIME_WAIT bucket 数量 (net.ipv4.tcp_max_tw_buckets)文件描述符数量 (max open files)

解决方法

只需要优化服务器系统的网络配置，连接配置，使用socket重用或及时释放资源即可。（由于系统不断迭代，所以这里不给出具体参数修改）

大量close_wait

问题原因

主机B一直没有进行第三次挥手，会导致主机B存在大量close_wait状态的连接。大量这种情况发生会影响服务器性能，同样可能导致套接字数量达到服务器上限。

网络连接未及时释放，通常是服务端发生异常后未关闭连接或者close_wait的配置时间过长。如果是mysql数据库也可能存在事务开启后没有正确rollback或commit的可能。

总之，都是大概率是服务端代码或配置的问题。

解决方法

以下方法并不存在顺序，定位问题时也并不是一定同时需要。

• top查看cpu利用率和load情况（大量close_wait属于io密集型，会导致load相比cpu利用率高出很多）
• netstat观察close_wait的数量变化。
• wireshark辅助查看网络包的发送情况。
• perf或者火焰图定位热点函数。
• java可以将服务器线程堆栈dump，查看大量线程在哪里blocked。