高并发场景下大量TCP链接处于time_wait状态原因及优化思路分析-Toy模板网

这篇具有很好参考价值的文章主要介绍了高并发场景下大量TCP链接处于time_wait状态原因及优化思路分析。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

问题现象

对一台服务器进行压测（模拟高并发场景），会发现大量 TIME_WAIT 状态的 TCP连接，连接关闭后，这些TIME_WAIT会被系统回收
tcp大量timewait,tcp/ip,网络,服务器

一般来讲，在高并发的场景中，出现TIME_WAIT连接是正常现象，一旦四次握手连接关闭之后，这些连接也就随之被系统回收了

但是在实际高并发场景中，很有可能会出现这样的极端情况——大量的TIME_WAIT连接

TIME_WAIT状态连接过多的引发的问题

TIME_WAIT 状态下，TCP连接占用的本地端口将一直无法释放
如果TIME_WAIT连接把所有可用端口都占完了（TCP端口数量上限是65535）而且还未被系统回收，就会出现无法向服务端创建新的socket连接的情况，此时系统几乎停转，任何链接都不能建立：address already in use : connect 异常

如何查看TIME_WAIT连接？

以我本地虚拟机（CentOS7）为例：

查看状态为TIME_WAIT的TCP连接
$ netstat -tan |grep TIME_WAIT

统计TCP各种状态的连接数
$ netstat -n | awk '/^tcp/ {++S[$NF]} END {for(i in S) print i, S[i]}'

大量的TIME_WAIT连接存在，其本质原因是什么？

1.大量的短连接存在

在HTTP/1.0协议中默认使用短连接。

也就是说，浏览器和服务器每进行一次HTTP操作，就会建立一次连接，任务结束后就会断开连接，而断开连接这个请求是由server去发起的，主动关闭连接请求一端才会有TIME_WAIT状态连接

2.HTTP请求头里connection值被设置为close

如果HTTP请求中，connection的值被设置成close，那就相当于告诉server：server执行完HTTP请求后去主动关闭连接

优化思路

客户端层面

我们可以在客户端将HTTP请求头里connection的值设置为：keep-alive。将短连接改成长连接

长连接比短连接从根本上减少了server去主动关闭连接的次数，减少了TIME_WAIT状态连接的产生

（在利用nginx做反向代理时，如果要设置成长连接，则需要设置成：1.从client到nginx的连接是长连接。2.从nginx到server的连接是长连接）

服务器层面

我们可以通过修改服务器的系统内核参数来进行优化

1.允许将TIME_WAIT状态的socket重新用于新的TCP连接

这样的好处就是如果出现大量TIME_WAIT状态的连接，也能够将这些连接占用的端口重新用于新的TCP连接

$ vim /etc/sysctl.confnet.ipv4.tcp_tw_reuse = 1 #默认为0，表示关闭

2.快速回收TIME_WAIT状态的socket

$ vim /etc/sysctl.confnet.ipv4.tcp_tw_recycle = 1#默认为0，表示关闭

3.将MSL值缩减

linux中MSL的值默认为60s，我们可以通过缩减MSL值来使得主动关闭连接一端由TIME_WAIT状态到关闭状态的时间减少

但是这样做会导致延迟报文无法清除以及主动关闭连接一端不能收到重传来的FIN请求，也会影响很多基于TCP的应用的连接复用和调优

所以在实际生产环境中，需要谨慎操作文章来源地址https://www.toymoban.com/news/detail-760250.html

#查看默认的MSL值
$cat /proc/sys/net/ipv4/tcp_fin_timeout

#修改
$echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout

或者
$ vim /etc/sysctl.conf
net.ipv4.tcp_fin_timeout = 30

到了这里，关于高并发场景下大量TCP链接处于time_wait状态原因及优化思路分析的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！