解决Linux下TIME_WAIT和CLOSE_WAIT过多的问题

作者: 风 哥 分类: Linux运维 发布时间: 2019-03-26 14:28

最近将 WebSocket 部署上服务器后,发现系统有大量的 TIME_WAIT CLOSE_WAIT 状态的链接,大量TIME_WAIT状态的链接不能被及时回收导致的结果就是系统可用 socket 被耗尽而无法处理新的请求。
对于http协议的短连接请求,应该要防止产生大量的 TIME_WAIT。使用以下命令查看 TIME_WAIT 和 CLOSE_WAIT 链接状态。

# netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

其中$NF表示最后一个字段
它会显示例如下面的信息:

LAST_ACK 2
CLOSE_WAIT 4
ESTABLISHED 295
TIME_WAIT 1245

常用的三个状态是:ESTABLISHED 表示正在通信,TIME_WAIT 表示主动关闭,CLOSE_WAIT 表示被动关闭。

 

1.TIME_WAIT(通过优化系统内核参数可容易解决)

再具体一点,四次挥手的交互过程如下:
客户端先发送FIN,进入FIN_WAIT1状态
服务端收到FIN,发送ACK,进入CLOSE_WAIT状态,客户端收到这个ACK,进入FIN_WAIT2状态
服务端发送FIN,进入LAST_ACK状态
客户端收到FIN,发送ACK,进入TIME_WAIT状态,服务端收到ACK,进入CLOSE状态
客户端TIME_WAIT持续2倍MSL时长,在linux体系中大概是60s,转换成CLOSE状态

能不能发送完ACK之后不进入TIME_WAIT就直接进入CLOSE状态呢?不行的,这个是为了TCP协议的可靠性,由于网络原因,ACK可能会发送失败,那么这个时候,被动一方会主动重新发送一次FIN,这个时候如果主动方在TIME_WAIT状态,则还会再发送一次ACK,从而保证可靠性。那么从这个解释来说,2MSL的时长设定是可以理解的,MSL是报文最大生存时间,如果重新发送,一个FIN+一个ACK,再加上不定期的延迟时间,大致是在2MSL的范围。
如果服务器出了异常,百分之八九十都是下面两种情况:
1.服务器保持了大量TIME_WAIT状态
2.服务器保持了大量CLOSE_WAIT状态

对比/etc/sysctl.conf 配置文件中参数 net.ipv4.tcp_max_tw_buckets 值,看是否有超出情况。如果确认已经超出,则可以编辑 /etc/sysctl.conf 配置文件,根据系统规格,适当调大net.ipv4.tcp_max_tw_buckets 参数值

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

服务端的Time-wait过多
先来说一说长连接和短连接,在HTTP1.1协议中,有个 Connection 头,Connection有两个值,close和keep-alive,这个头就相当于客户端告诉服务端,服务端你执行完成请求之后,是关闭连接还是保持连接。如果服务器使用的短连接,那么每次客户端请求后,服务器都会主动发送FIN关闭连接。最后进入time_wait状态。可想而知,对于访问量大的Web Server,会存在大量的TIME_WAIT状态。让服务器能够快速回收和重用那些TIME_WAIT的资源,可以修改内核参数。

net.ipv4.tcp_syncookies = 1  #表示开启SYN Cookies。当出现SYN等待队列溢出时,启用cookies来处理,可防范少量SYN攻击,默认为0,表示关闭         
net.ipv4.tcp_tw_reuse = 1    #表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接,默认为0,表示关闭  
net.ipv4.tcp_tw_recycle = 1  #表示开启TCP连接中TIME-WAIT sockets的快速回收,默认为0,表示关闭    
net.ipv4.tcp_fin_timeout=30  #表示如果套接字由本端要求关闭,这个参数决定了它保持在FIN-WAIT-2状态的时间

然后执行/sbin/sysctl -p让参数生效;经过配置后,暂时的问题是解决了,再查看 TIME_WAIT 数量从5000快速下降100多。


7层 SLB 后端ECS有大量的timewait的原因主要在于SLB使用短链接跟后端ecs通信,http请求中带有Connection: close,所以后端ECS的服务器应用收到这个请求后,产生响应包,并立即结束连接。连接是后端ECS关闭的,ECS上就会有timewait的socket。 这个可以看tcp的状态机就知道了,谁主动关闭连接,那么它的socket就会进timewait状态,而被动被关闭的连接在发完FIN收到ack后直接close了,不会进timewait。 一般timewait不会影响服务器性能。


2.CLOSE_WAIT(需要从程序本身出发)

先来了解 TCP 协议的建立连接的过程,如下图:

然后断开连接的过程,如下图:

对于已经建立的连接,网络双方要进行四次握手才能成功断开连接,如果缺少了其中某个步骤,将会使连接处于假死状态,连接本身占用的资源不会被释放。网络服务器程序要同时管理大量连接,所以很有必要保证无用连接完全断开,否则大量僵死的连接会浪费许多服务器资源。

导致 CLOSE_WAIT 大量存在的原因:就是在对方关闭连接之后服务器程序自己没有进一步发出 ACK 信号。换句话说,就是在对方连接关闭之后,程序里没有检测到,或者程序压根就忘记了这个时候需要关闭连接,于是这个资源就一直被程序占着;服务器对于程序抢占的资源没有主动回收的权利,除非终止程序运行。

解决方案:代码需要判断 socket ,一旦读到 0,断开连接,read 返回负,检查一下 errno,如果不是 AGAIN,就断开连接。
所以解决 CLOSE_WAIT 大量存在的方法还是从自身的代码出发。

发表评论

电子邮件地址不会被公开。 必填项已用*标注