HttpClient出现大量time_wait问题

Posted kaleidoscope

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了HttpClient出现大量time_wait问题相关的知识,希望对你有一定的参考价值。

高并发短连接的TCP服务器上,当服务器处理完请求后立刻主动正常关闭连接。这个场景下会出现大量socket处于TIME_WAIT状态。如果客户端的并发量持续很高,此时部分客户端就会显示连接不上。我来解释下这个场景。主动正常关闭TCP连接,都会出现TIMEWAIT。

为什么我们要关注这个高并发短连接呢?有两个方面需要注意:
1. 高并发可以让服务器在短时间范围内同时占用大量端口,而端口有个0~65535的范围,并不是很多,刨除系统和其他服务要用的,剩下的就更少了。
2. 在这个场景中,短连接表示“业务处理+传输数据的时间 远远小于 TIMEWAIT超时的时间”的连接

这里有个相对长短的概念,比如取一个web页面,1秒钟的http短连接处理完业务,在关闭连接之后,这个业务用过的端口会停留在TIMEWAIT状态几分钟,而这几分钟,其他HTTP请求来临的时候是无法占用此端口的(占着茅坑不拉翔)。单用这个业务计算服务器的利用率会发现,服务器干正经事的时间和端口(资源)被挂着无法被使用的时间的比例是 1:几百,服务器资源严重浪费。(说个题外话,从这个意义出发来考虑服务器性能调优的话,长连接业务的服务就不需要考虑TIMEWAIT状态。同时,假如你对服务器业务场景非常熟悉,你会发现,在实际业务场景中,一般长连接对应的业务的并发量并不会很高

综合这两个方面,持续的到达一定量的高并发短连接,会使服务器因端口资源不足而拒绝为一部分客户服务。同时,这些端口都是服务器临时分配,无法用SO_REUSEADDR选项解决这个问题。

存在即是合理的,既然TCP协议能盛行四十多年,就证明他的设计合理性。所以我们尽可能的使用其原本功能。 

依靠TIME_WAIT状态来保证我的服务器程序健壮,服务功能正常。

那是不是就不要性能了呢?并不是。如果服务器上跑的短连接业务量到了我真的必须处理这个TIMEWAIT状态过多的问题的时候,我的原则是尽量处理,而不是跟TIMEWAIT干上,非先除之而后快。

如果尽量处理了,还是解决不了问题,仍然拒绝服务部分请求,那我会采取负载均衡来抗这些高并发的短请求。持续十万并发的短连接请求,两台机器,每台5万个,应该够用了吧。一般的业务量以及国内大部分网站其实并不需要关注这个问题,一句话,达不到时才需要关注这个问题的访问量。

如何尽量处理TIMEWAIT过多?

编辑内核文件/etc/sysctl.conf,加入以下内容:

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 修改系默认的 TIMEOUT 时间 

http1.0 默认是短连接,client端主动发起,server端服务完毕后,将连接关毕,client端也借此判断数据发送完毕。所以http1.0时代,服务端容易有较多的time_wait。

  • 如果http 1.0协议,client希望使用长连接,需要在header中设置connection:keep-alive 

http1.1默认是长连接

  • 如果client不希望使用长连接,需要在header中设置connection:close
  • 如果server不希望使用长连接,也需要在reponse中设置connection:close
http header中keep-alive参数用于设置客户端希望服务端保持连接的秒数  

长连接的问题 

keep-alive模式带来的问题:此时服务端不关闭连接,客户端如何知道消息内容是否发送完毕(曾经因为对http1.0没有主动关闭连接,导致一些老旧php上的的socket http包因为等待服务端关闭连接判断消息发送完毕而超时)

keep-alive模式下,通过两种方式

  • 服务端reqponse设置content-length参数:告知内容大小,客户端收到指定内容长度后即可关闭连接。客户端发送post时也会采用这种方式,如若content-length大于实际发生的值会超时,小于则服务端会响应400。这种模式有缺陷,动态页面服务器也不知道内容大小,只有等内容全准备完毕后才知道,若等到此时发送,效率太低了。
  • transfer-encoding:chunked模式:此模式下简单说是规定一直特殊的响应data格式,此种格式中会包含body结束的标志。客户端收到此标志即知道数据发送完毕,可以组装解密数据了。


以上是关于HttpClient出现大量time_wait问题的主要内容,如果未能解决你的问题,请参考以下文章

zabbix proxy 服务器 netstat 出现大量Time_Wait连接问题

HttpClient4 TIME_WAIT和CLOSE_WAIT

一次HttpClient连接池设置不当,引发服务雪崩

HttpClient 设置不当引发的一次雪崩

内部分享:一次HttpClient连接池引发的雪崩案例复盘....

HttpClient 设置不当引发的一次雪崩