处于CLOSE_WAIT和TIME_WAIT状态连接的原因及解决

常用的三个状态是:ESTABLISHED   TIME_WAIT   CLOSE_WAIT

ESTABLISHED 表示正在通信,TIME_WAIT 表示主动关闭,CLOSE_WAIT 表示被动关闭。

具体每种状态什么意思,其实无需多说,看看下面这种图就明白了,注意这里提到的服务器应该是业务请求接受处理的一方:

这么多状态不用都记住,只要了解到我上面提到的最常见的三种状态的意义就可以了。一般不到万不得已的情况也不会去查看网络状态,如果服务器出了异常,百分之八九十都是下面两种情况:

1.服务器保持了大量TIME_WAIT状态

2.服务器保持了大量CLOSE_WAIT状态

因为linux分配给一个用户的文件句柄是有限的,而TIME_WAIT和CLOSE_WAIT两种状态如果一直被保持,那么意味着对应数目的通道就一直被占着,而且是“占着茅坑不使劲”,一旦达到句柄数上限,新的请求就无法被处理了,接着就是大量Too Many Open Files异常,tomcat崩溃。。。

下面来讨论下这两种情况的处理方法,网上有很多资料把这两种情况的处理方法混为一谈,以为优化系统内核参数就可以解决问题,其实是不恰当的,优化系统内核参 数解决TIME_WAIT可能很容易,但是应对CLOSE_WAIT的情况还是需要从程序本身出发。现在来分别说说这两种情况的处理方法:

服务器保持大量TIME_WAIT状态

这种情况比较常见,一些爬虫服务器和WEB服务器,如果没有做内核优化的话,经常会遇到这个问题。

TIME_WAIT是主动关闭连接的一方保持的状态。

对于爬虫服务器本身就是一个客户端,完成一次爬取任务后,主动关闭连接,从而进入TIME_WAIT状态,然后保持这个状态2MSL(max segment lifetime,默认为240s)之后,彻底关闭回收资源。为什么这么做?为啥已经主动关闭连接还要保持资源一段时间?

主要TCP/IP协议设计的考虑:

  1. 防止上一次连接中的包,因为网络原因(迷路或者波动)重新出现,影响连接
  2. 可靠的关闭TCP连接,在主动关闭方发送的最后一个ack,有可能丢失,这时被动方会从新发fin,如果这时主动方处于CLOSED状态,就会影响rst而不是ack。所以主动要处于TIME_WAIT,而不能CLOSED。另外这么设计TIME_WAIT会定时回收资源,并不会占用很大资源,除非段时间接收大量请求或者受到攻击。

再引用网络资源的一段话:

1.值 得一说的是,对于基于TCP的HTTP协议,关闭TCP连接的是Server端,这样,Server端会进入TIME_WAIT状态,可 想而知,对于访 问量大的Web Server,会存在大量的TIME_WAIT状态,假如server一秒钟接收1000个请求,那么就会积压 240*1000=240,000个 TIME_WAIT的记录,维护这些状态给Server带来负担。当然现代操作系统都会用快速的查找算法来管理这些 TIME_WAIT,所以对于新的 TCP连接请求,判断是否hit中一个TIME_WAIT不会太费时间,但是有这么多状态要维护总是不好。

2.HTTP协议1.1版规定default行为是Keep-Alive,也就是会重用TCP连接传输多个 request/response,一个主要原因就是发现了这个问题。

现在来说如何来解决这个问题。

解决思路很简单,就是让服务器能够快速回收和重用那些TIME_WAIT的资源

下面来看一下我们网管对/etc/sysctl.conf文件的修改:

  1. #对于一个新建连接,内核要发送多少个 SYN 连接请求才决定放弃,不应该大于255,默认值是5,对应于180秒左右时间
  2. net.ipv4.tcp_syn_retries=2
  3. #net.ipv4.tcp_synack_retries=2
  4. #表示当keepalive起用的时候,TCP发送keepalive消息的频度。缺省是2小时,改为300秒
  5. net.ipv4.tcp_keepalive_time=1200
  6. net.ipv4.tcp_orphan_retries=3
  7. #表示如果套接字由本端要求关闭,这个参数决定了它保持在FIN-WAIT-2状态的时间
  8. net.ipv4.tcp_fin_timeout=30
  9. #表示SYN队列的长度,默认为1024,加大队列长度为8192,可以容纳更多等待连接的网络连接数。
  10. net.ipv4.tcp_max_syn_backlog = 4096
  11. #表示开启SYN Cookies。当出现SYN等待队列溢出时,启用cookies来处理,可防范少量SYN攻击,默认为0,表示关闭
  12. net.ipv4.tcp_syncookies = 1
  13. #表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接,默认为0,表示关闭
  14. net.ipv4.tcp_tw_reuse = 1
  15. #表示开启TCP连接中TIME-WAIT sockets的快速回收,默认为0,表示关闭
  16. net.ipv4.tcp_tw_recycle = 1
  17. ##减少超时前的探测次数
  18. net.ipv4.tcp_keepalive_probes=5
  19. ##优化网络设备接收队列
  20. net.core.netdev_max_backlog=3000

修改完之后执行/sbin/sysctl -p让参数生效。

或者参考:

《netstat监控大量ESTABLISHED连接数和TIME_WAIT连接数题解决》

http://jasonzhu.blog.51cto.com/5594807/1728001

服务器保持大量CLOSE_WAIT状态连接

TIME_WAIT状态可以通过优化系统内核参数/etc/sysctl.conf解决,因此发生TIME_WAIT状态是服务器可控的,要么是对方连接异常,要么就是自己没有迅速回收资源。

但是CLOSE_WAIT就不一样,如果一直保持CLOSE_WAIT状态,那么只有一种情况,就是对方主动关闭连接后,服务器自己没有进一步发出ack信号。换句话说,就是对方关闭连接之后,程序没有检测到,或者程序压根忘记这时候需要关闭连接,于是这个资源就一直被程序占着。这种情况无法通过调节内核参数解决,因为服务器对于程序抢占的资源没有主动回收的权利,除非终止程序运行。

如果使用HttpClient遇到大量CLOSE_WAIT的情况,参考日志:

《HttpClient连接池抛出大量ConnectionPoolTimeoutException: Timeout waiting for connection异常排查》

http://blog.csdn.net/shootyou/article/details/6615051

在那边日志里头我举了个场景,来说明CLOSE_WAIT和TIME_WAIT的区别,这里重新描述一下:

服务器A是一台爬虫服务器,它使用简单的HttpClient去请求资源服务器B上面的apache获取文件资源,正常情况下,如果请求成功,那么在抓取完 资源后,服务器A会主动发出关闭连接的请求,这个时候就是主动关闭连接,服务器A的连接状态我们可以看到是TIME_WAIT。如果一旦发生异常呢?假设 请求的资源服务器B上并不存在,那么这个时候就会由服务器B发出关闭连接的请求,服务器A就是被动的关闭了连接,如果服务器A被动关闭连接之后程序员忘了 让HttpClient释放连接,那就会造成CLOSE_WAIT的状态了。

所以如果将大量CLOSE_WAIT的解决办法总结为一句话那就是:查代码。因为问题出在服务器程序里头啊。

时间: 2024-10-12 17:03:41

处于CLOSE_WAIT和TIME_WAIT状态连接的原因及解决的相关文章

TCP/IP协议--TIME_WAIT状态存在的原因

1. 实际问题         初步查看发现,无法对外新建TCP连接时,线上服务器存在大量处于TIME_WAIT状态的TCP连接(最多的一次为单机10w+,其中引起报警的那个模块产生的TIME_WAIT约2w),导致其无法跟下游模块建立新TCP连接. TIME_WAIT涉及到TCP释放连接过程中的状态迁移,也涉及到具体的socket api对TCP状态的影响,下面开始逐步介绍这些概念. 2. TCP状态迁移        面向连接的TCP协议要求每次peer间通信前建立一条TCP连接,该连接可抽

close_wait状态的产生原因及解决(转)

最近测试环境server由于需要与大量的后台server交互,今天突然发现有大量的close_wait产生,于是仔细研究了一下: 如果我们的服务器程序处于CLOSE_WAIT状态的话,说明套接字是被动关闭的! 因为如果是CLIENT端主动断掉当前连接的话,那么双方关闭这个TCP连接共需要四个packet: 1.Client -> FIN  -> Server   2.Client <- ACK  <- Server   这时候Client端处于FIN_WAIT_2状态:而Serve

close_wait状态的产生原因及解决

最近测试环境server由于需要与大量的后台server交互,今天突然发现有大量的close_wait产生,于是仔细研究了一下: 如果我们的服务器程序处于CLOSE_WAIT状态的话,说明套接字是被动关闭的! 因为如果是CLIENT端主动断掉当前连接的话,那么双方关闭这个TCP连接共需要四个packet: 1.Client -> FIN  -> Server 2.Client <- ACK  <- Server   这时候Client端处于FIN_WAIT_2状态:而Server

TIME_WAIT状态及存在原因

1. 客户端与服务器端建立TCP/IP连接后关闭SOCKET后,服务器端连接的端口状态为TIME_WAIT: 2. 主动关闭的Socket端会进入TIME_WAIT状态,并且持续2MSL时间长度,MSL就是maximum segment lifetime(最大分节生命期):     这是一个IP数据包能在互联网上生存的最长时间,超过这个时间将在网络中消失.     MSL在RFC 1122上建议是2分钟,而源自berkeley的TCP实现传统上使用30秒,因而,TIME_WAIT状态一般维持在1

UIToggle修改状态无效的原因及解决办法[NGUI]

场景:当一个UItoggle的状态发生变化时,动态修改另外一个UItoggle的状态无效.(NGUI版本:3.8.0) 原因:因为NGUI的UIToggle处理机制(或者说BUG),如法在UItoggle变化的同一帧设置另外的UItoggle状态. 解决办法:在下一帧中进行修改(Coroutine中yield return null) 原因详情: 参见UIToggle.cs中的public void Set (bool state) 其中current的定义

TIME_WAIT状态原理(转)

---------------------------- 转自:http://elf8848.iteye.com/blog/1739571 通信双方建立TCP连接后,主动关闭连接的一方就会进入TIME_WAIT状态. 客户端主动关闭连接时,会发送最后一个ack后,然后会进入TIME_WAIT状态,再停留2个MSL时间(后有MSL的解释),进入CLOSED状态. 下图是以客户端主动关闭连接为例,说明这一过程的. TIME_WAIT状态存在的理由 --------------------------

TCP/IP中TIME_WAIT状态详解

TIME_WAIT状态原理: 通信双方建立连接后,主动关闭连接的一方就会进入TIME_WAIT状态. 客户端主动关闭连接时,会发送最后一个ACK确认,然后就会进入TIME_WAIT状态,再停留2MSL,就会进入CLOSED状态. 接下来我们看一张图,来说明这一过程: 上图是TCP"四次挥手"的过程,相信你们都会很了解,下面我们来说说为什么要存在TIME_WAIT状态 TIME_WAIT状态存在的理由如下: (1)可靠地实现TCP全双工连接的终止 TCP协议在关闭连接的四次挥手中,最终的

TCP/IP TIME_WAIT状态原理

TIME_WAIT状态原理 ---------------------------- 通信双方建立TCP连接后,主动关闭连接的一方就会进入TIME_WAIT状态. 客户端主动关闭连接时,会发送最后一个ack后,然后会进入TIME_WAIT状态,再停留2个MSL时间(后有MSL的解释),进入CLOSED状态. 下图是以客户端主动关闭连接为例,说明这一过程的. TIME_WAIT状态存在的理由 ---------------------------- TCP/IP协议就是这样设计的,是不可避免的.主

[Nginx笔记]关于线上环境CLOSE_WAIT和TIME_WAIT过高

运维的同学和Team里面的一个同学分别遇到过Nginx在线上环境使用中会遇到TIME_WAIT过高或者CLOSE_WAIT过高的状态 先从原因分析一下为什么,问题就迎刃而解了. 首先是TIME_WAIT: 理解一下TIME_WAIT状态产生的原因,这个问题已经被很多很多的书说烂了,但是为什么很多人还是不能解决,究其原因还是因为 大多数都是学术派,并没有真正的遇到过这样的问题,因为TIME_WAIT大量产生很多都发生在实际应用环境中. TIME_WAIT产生的原因还是因为在通讯过程中服务端主动关闭