服务器TIME_WAIT和CLOSE_WAIT详解和解决办法
最新回答
谱写我们的阳光。
2020-11-23 02:24:10
命令显示的信息中，有三个常用的状态：ESTABLISHED表示正在通信，TIME_WAIT表示主动关闭，CLOSE_WAIT表示被动关闭。
具体每种状态的意义不必详述，只需了解上面提到的三种状态即可。通常情况下，不会频繁查看网络状态，但如果服务器出现异常，百分之八九十的情况是以下两种：
1.服务器保持了大量TIME_WAIT状态
2.服务器保持了大量CLOSE_WAIT状态
Linux系统为每个用户分配的文件句柄是有限的。TIME_WAIT和CLOSE_WAIT两种状态如果一直被保持，意味着对应数目的通道就一直被占用，一旦达到句柄数上限，新的请求就无法处理，导致大量Too Many Open Files异常，最终导致WEB服务崩溃。
下面将讨论这两种情况的处理方法。网上有很多资料将这两种情况的处理方法混为一谈，认为优化系统内核参数就可以解决问题，但实际上并不恰当。优化系统内核参数解决TIME_WAIT可能容易，但应对CLOSE_WAIT的情况还需从程序本身出发。下面分别介绍这两种情况的处理方法：
1.服务器保持了大量TIME_WAIT状态
这种情况较为常见，一些爬虫服务器或WEB服务器（如果网管在安装时没有进行内核参数优化）可能会遇到这个问题。TIME_WAIT状态是主动关闭连接的一方保持的状态。对于爬虫服务器来说，它是“客户端”，在完成一个爬取任务后，会主动关闭连接，从而进入TIME_WAIT状态，然后在这个状态下保持2MSL（最大段生命周期）时间后，彻底关闭并回收资源。为什么要这么做？明明已经主动关闭连接了，为什么还要保持资源一段时间呢？这是TCP/IP设计者规定的，主要出于以下两个方面的考虑：
关于MSL的引用，以下是一段话：
再引用网络资源的一段话：
也就是说HTTP的交互与上述图示不同，关闭连接的不是客户端，而是服务器。因此，WEB服务器也可能出现大量TIME_WAIT的情况。
现在来说如何解决这个问题。解决思路很简单，就是让服务器能够快速回收和重用那些TIME_WAIT的资源。
下面来看一下对/etc/sysctl.conf文件的修改：
修改后执行/sbin/sysctl -p让参数生效。
这里主要注意以下几个参数：
关于keepalive的用途可以参考以下链接：
2.服务器保持了大量CLOSE_WAIT状态
休息一下，喘口气。一开始只是打算说说TIME_WAIT和CLOSE_WAIT的区别，没想到越挖越深。这也是写博客总结的好处，总会有意外的收获。
TIME_WAIT状态可以通过优化服务器参数得到解决，因为发生TIME_WAIT的情况是服务器自己可控的，要么是对方连接的异常，要么是自己没有迅速回收资源，总之不是由于自己程序错误导致的。
但是CLOSE_WAIT就不一样了。从上面的图可以看出，如果一直保持在CLOSE_WAIT状态，那么只有一种情况，即在对方关闭连接之后，服务器程序没有进一步发出ack信号。换句话说，即在对方连接关闭之后，程序中没有检测到，或者程序根本没有忘记这个时候需要关闭连接，于是这个资源就一直被程序占用。个人认为这种情况，通过服务器内核参数也无法解决，服务器对程序抢占的资源没有主动回收的权利，除非终止程序运行。
如果你使用的是HttpClient并且遇到了大量CLOSE_WAIT的情况，那么这篇日志可能对你有帮助：
作者在那篇文章的日志中举了一个场景，来说明CLOSE_WAIT和TIME_WAIT的区别。这里重新描述一下：
服务器A是一台爬虫服务器，它使用简单的HttpClient请求资源服务器B上的apache获取文件资源。正常情况下，如果请求成功，那么在抓取完资源后，服务器A会主动发出关闭连接的请求，这时就是主动关闭连接，服务器A的连接状态我们可以看到是TIME_WAIT。如果发生异常，假设请求的资源服务器B上并不存在，那么这个时候就会由服务器B发出关闭连接的请求，服务器A就是被动的关闭了连接。如果服务器A被动关闭连接后，程序员忘了让HttpClient释放连接，那就会造成CLOSE_WAIT的状态。
所以，将大量CLOSE_WAIT的解决办法总结为一句话就是：查代码。因为问题出在服务器程序里。
热门标签
