TCP连接问题之time_wait

TCP的TIME_WAIT状态 1. TIME_WAIT状态 主动关闭方在收到被动关闭方的FIN包后并返回ACK后,会进入TIME_WAIT状态,TIME_WAIT状态又称2MSL状态,每个TCP连接都必须有一个最大报文段生存时间MSL,在网络传输中超过这个时间的报文段将被丢弃。当TCP连接发起一个主动关闭,并发出最后一个ACK时,必须在TIME_WAIT状态停留两倍MSL时间,在2MSL等待期间,定义这个连接的插口(客户端IP... 阅读详情

一、TCP四次挥手连接状态图

在这里插入图片描述
(1) TCP客户端发送一个FIN,用来关闭客户到服务器的数据传送。

(2) 服务器收到这个FIN,它发回一个ACK,确认序号为收到的序号加1。和SYN一样,一个FIN将占用一个序号。

(3) 服务器关闭客户端的连接,发送一个FIN给客户端。

(4) 客户段发回ACK报文确认,并将确认序号设置为收到序号加1。
  
注:
从上图可知,只有首先调用close()发起主动关闭的一方才会进入TIME_WAIT状态(client和server均可以发起主动关闭,常见为client方发起主动关闭),而且是必须进入。
从图中还可看到,进入TIME_WAIT状态的TCP连接需要经过2MSL才能回到初始状态,其中,MSL是指Max Segment Lifetime,即数据包在网络中的最大生存时间。每种TCP协议的实现方法均要指定一个合适的MSL值,如RFC1122给出的建议值为2分钟,又如Berkeley体系的TCP实现通常选择30秒作为MSL值。这意味着TIME_WAIT的典型持续时间为1-4分钟。

二、time_wait的作用

1)可靠地实现TCP全双工连接的终止
在进行关闭连接四次挥手协议时,最后的ACK是由主动关闭端发出的,如果这个最终的ACK丢失,服务器将重发最终的FIN,
因此客户端必须维护状态信息允许它重发最终的ACK。如果不维持这个状态信息,那么客户端将响应RST分节,服务器将此分节解释成一个错误(在java中会抛出connection reset的SocketException)。
因而,要实现TCP全双工连接的正常终止,必须处理终止序列四个分节中任何一个分节的丢失情况,主动关闭的客户端必须维持状态信息进入TIME_WAIT状态。

2)允许老的重复分节在网络中消逝
TCP分节可能由于路由器异常而“迷途”,在迷途期间,TCP发送端可能因确认超时而重发这个分节,迷途的分节在路由器修复后也会被送到最终目的地,这个原来的迷途分节就称为lost duplicate。
在关闭一个TCP连接后,马上又重新建立起一个相同的IP地址和端口之间的TCP连接,后一个连接被称为前一个连接的化身(incarnation),那么有可能出现这种情况,前一个连接的迷途重复分组在前一个连接终止后出现,从而被误解成从属于新的化身。
为了避免这个情况,TCP不允许处于TIME_WAIT状态的连接启动一个新的化身,因为TIME_WAIT状态持续2MSL,就可以保证当成功建立一个TCP连接的时候,来自连接先前化身的重复分组已经在网络中消逝。

三、time_wait过多原因

看到这里我们会看到time_wait的产生是必然的,而且也有它存在的意义。但是,在某种情形下,会产生time_wait现象造成部分client连接不上server,产生条件如下:

  1. 高并发可以让服务器在短时间范围内同时占用大量端口,而端口有个0~65535的范围,并不是很多,刨除系统和其他服务要用的,剩下的就更少了,此时有的客户端会连接不上服务器。

  2. 在这个场景中,客户端连接的速度 远远小于2MSL,这时候time_wait占用的并没被释放

四、time_wait过多解决

1、通过接口setsockopt()设置套接字属性SO_REUSEADDR。这个套接字选项通知内核,如果端口忙,但TCP状态位于 TIME_WAIT ,可以重用端口。
2、修改内核参数
编辑内核文件/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 时间

然后执行 /sbin/sysctl -p 让参数生效.

/etc/sysctl.conf是一个允许改变正在运行中的Linux系统的接口,它包含一些TCP/IP堆栈和虚拟内存系统的高级选项,修改内核参数永久生效。
简单来说,就是打开系统的TIMEWAIT重用和快速回收。

如果以上配置调优后性能还不理想,可继续修改一下配置:

net.ipv4.tcp_keepalive_time = 1200
#表示当keepalive起用的时候,TCP发送keepalive消息的频度。缺省是2小时,改为20分钟。 net.ipv4.ip_local_port_range = 1024 65000
#表示用于向外连接的端口范围。缺省情况下很小:32768到61000,改为1024到65000。 net.ipv4.tcp_max_syn_backlog = 8192
#表示SYN队列的长度,默认为1024,加大队列长度为8192,可以容纳更多等待连接的网络连接数。 net.ipv4.tcp_max_tw_buckets = 5000
#表示系统同时保持TIME_WAIT套接字的最大数量,如果超过这个数字,TIME_WAIT套接字将立刻被清除并打印警告信息。 默认为180000,改为5000。对于Apache、Nginx等服务器,上几行的参数可以很好地减少TIME_WAIT套接字数量,但是对于 Squid,效果却不大。此项参数可以控制TIME_WAIT套接字的最大数量,避免Squid服务器被大量的TIME_WAIT套接字拖死。

深入TCP协议——tcp_tw_reuse和tcp_tw_recycle 我们已经知道TCP四次挥手中,主动方在收到被动方的FIN数据包之后会进入TIME_WAIT状态等待2MSL的时间后才进入CLOSED。在 Linux 操作系统下,TIME_WAIT 状态的持续时间是 60 秒,这意味着这 60 秒内,客户端一直会占用着这个端口,这是有一定的开销的。如果如果主动关闭连接方的 TIME_WAIT 状态过多,占满了所有端口资源,则会导致无法创建新连接。 阅读详情

相关推荐

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

time_wait问题处理

Tec Log 6330

TCP 协议(四)重传与超时

本博客从TCP重传、超时、拥塞控制、流量控制等方面进行了深入探讨,以帮助读者更好地理解TCP协议在网络传输过程中如何确保数据的可靠性和高效性。我们详细分析了各种重传原理、触发条件和优化策略,以及超时检测、动态调整和与重传的关系。同时,我们还探讨了拥塞控制与流量控制在调整网络传输速率、协同作用以确保网络稳定性的重要性。在实践中,我们针对不同的网络环境提供了优化策略,并对常见性能问题进行了分析和解决。此外,我们还展望了未来TCP重传与超时的发展趋势,为进一步提高网络性能提供了指导。

cliffordl的专栏 6437

Windows11+VS2022驱动开发环境搭建实战:从零到编译(避坑指南)

本文详细介绍了在Windows11系统下使用VS2022搭建驱动开发环境的完整流程,包括版本匹配、工具安装、环境配置及常见问题解决。重点强调了WDK与系统版本的严格匹配,以及VS2022中驱动开发组件的正确配置方法,帮助开发者高效避坑并成功编译第一个驱动程序。

weixin_29251337的博客 526

LINUX如何解决服务器TCP连接TIMEOUT过长

根据TCP协议定义的3次握手断开连接规定,发起socket主动关闭的一方 socket将进入TIME_WAIT状态,TIME_WAIT状态将持续2个MSL(Max Segment Lifetime),在Windows下默认为4分钟,即240秒,TIME_WAIT状态下的socket不能被回收使用. 具体现象是对于一个处理大量短连接的服务器,如果是由服务器主动关闭客户端的连接,将导致服务器端存在大量...

pan269的博客 1万+

LVGL移植教程(正点原子)

学习正点原子LVGL移植教程,根据视频教程写的博客

papalila的博客 939

Win11+VSCode+TeXLive:学术党必备的LaTeX环境配置避坑指南(2024最新版)

本文详细介绍了如何在Windows 11系统下,通过VSCode编辑器与TeXLive发行版配置高效的LaTeX学术写作环境。针对国内用户常见的镜像下载慢、插件配置复杂等问题,提供了优化方案和避坑指南,帮助科研人员和学生快速搭建流畅的学术写作工作流。

plum99的博客 617

TCP连接大量TIME_WAIT状态问题排查

TIME_WAIT连接过多 TIME_WAIT的产生   TIMEWAIT是主动关闭的一方,在使用FIN|ACK|FIN|ACK四分组正常关闭TCP连接时产生的。TIMEWAIT状态本身和应用层的客户端或者服务器是没有关系的。服务器在处理客户端请求的时候,如果你的程序设计为服务器主动关闭,那么你才有可能需要关注这个TIMEWAIT状态过多的问题。如果你的服务器设计为被动关闭,那么你首先要关

04stone37 3734

AndroidKiller之APK 编译失败,无法继续下一步签名【BUG解决】【App反向解析】

文章目录项目场景:问题描述原因分析:解决方案:BUG解决 项目场景: AndroidKiller: 在反向解析APP包时报错:APK 编译失败,无法继续下一步签名。 网上很多方法都是无效的哈,我追究原因发现,这个bug的出现大部分情况都是因为Apktool的问题。 此方法:百分之百解决此bug! 错误如下: 问题描述 APK 编译失败,无法继续下一步签名! 原因分析: Apktool版本不适配的问题,现在的技术更新换代太快,我们安装AndroidKiller的时候,有时候不是官方渠道的话,他的版本是非常

一键难忘的博客 2万+

python time wait_TCP大并发短连接造成TIME_WAIT问题解决办法

这两天用python写了一个TCP的短连接压力测试脚本,模拟100路并发不间断的访问。脚本运行几分钟后开始全面报错,错误代码为10048或者99,使用netstat命令查看网络发现大量的连接处于TIME_WAIT状态。仔细阅读了《unix网络编程》相关章节,弄清楚了问题发生的原因,并找到了解决办法。问题原因:TCP连接的Close默认行为是将socket标记为关闭然后立即返回。此时socket描述...

weixin_39904587的博客 1234

YOLO11 改进、魔改|分组残差自注意力GRSA,通过分组残差优化 QKV 计算、指数空间映射优化位置偏差,在大幅降低自注意力模块参数和计算量的同时,增强特征关系与位置信息的表征能力

【摘要】研究人员提出GRSA(分组残差自注意力)机制,解决Transformer在图像超分辨率任务中效率与性能难以兼顾的问题。GRSA通过分组残差层减少自注意力参数冗余,同时采用指数空间相对位置偏差优化位置信息表征。实验表明,GRSA在降低50%参数量的同时保持模型性能,适用于目标检测和图像分割任务。在YOLO系列模型中集成GRSA可提升小目标检测精度,代码实现已开源,详细部署教程见相关视频与GitHub资源。该机制为轻量化Transformer模型提供了高效解决方案。

qq_64693987的博客 795

dolphinscheduler-3.4.0

dolphinscheduler集群部署

docsz的博客 660

服务端 TCP 连接的 TIME_WAIT 过多问题的分析与解决

可靠的实现 TCP 全双工连接的终止:四次挥手关闭 TCP 连接过程中,最后的 ACK 是由「主动关闭连接」的一端发出的,如果这个 ACK 丢失,则,对方会重发 FIN 请求,因此,在「主动关闭连接」的一段,需要维护一个 time_wait 状态,处理对方重发的 FIN 请求;短时间后,所有的 TIME_WAIT 全都消失,被回收,端口包括服务,均正常。1.TCP 连接建立后,「主动关闭连接」的一端,收到对方的 FIN 请求后,发送 ACK 响应,会处于 time_wait 状态;

zunguitiancheng的专栏 1245

基于Simulink的固态变压器(SST)多级协同控制​

本文介绍了基于Simulink的固态变压器(SST)多级协同控制方法。SST作为智能电网关键设备,其三级架构(AC-DC整流、DC-DC隔离、DC-AC逆变)存在级间耦合问题。文章提出纵向解耦与横向联动相结合的协同控制策略,详细推导了各级控制算法,并通过Simulink实现了10kV/400V级联型SST系统建模。仿真结果显示,在±20%电网波动和0-100%负载跳变下,系统能保持直流母线电压波动<2%。文章还提供了工程部署建议和代码生成方法,为SST的研发提供了实用指导。

amy_mhd的博客 299

tcp短连接TIME_WAIT问题解决方法大全(1)——高屋建瓴

tcp连接是网络编程中最基础的概念,基于不同的使用场景,我们一般区分为“长连接”和“短连接”, 长短连接的优点和缺点这里就不详细展开了,有心的同学直接去google查询,本文主要关注如何解决tcp短连接的TIME_WAIT问题。 短连接最大的优点是方便,特别是脚本语言,由于执行完毕后脚本语言的进程就结束了,基本上都是用短连接。 但短连接最大的缺点是将占用大量的系统资源,例如:本地端口

华仔-技术博客 3万+

15、虚拟环境中的数据保护与恢复方案解析

本文深入解析了虚拟环境中两种重要的数据保护与恢复解决方案:RecoverPoint for Virtual Machines(RP4VM)在VxRail上的设计,以及Veeam Backup & Replication(VBR)与VxRail的集成方案。文章详细介绍了RP4VM的网络布局、故障转移场景及其相关问题,以及VBR的架构设计、备份与复制流程、许可证选项及其多平台支持特性。此外,还探讨了RP4VM与VBR结合使用的综合解决方案,以及未来数据保护领域的发展趋势,如智能化管理、云原生集成和零信任架构,为

t4y5u6i7o的博客 95

文档:亲测可用解决vnc灰屏,黑屏,鼠标大黑叉情况

主要解决vnc-viewer灰屏,黑屏,鼠标大黑叉等现象,详细见文档。

TCP短连接TIME_WAIT问题解决方法大全

TCP短连接TIME_WAIT问题解决方法大全

qq_38472574的博客 204

汉书HE8,好用的汇编代码编写工具

汉书HE8,好用的汇编代码编写工具早期编写汇编代码所用功能强大

经典!服务端 TCP 连接的 TIME_WAIT 过多问题的分析与解决

开源Linux专注分享开源技术知识本文给出一个 TIME_WAIT 状态的 TCP 连接过多的问题的解决思路,非常典型,大家可以好好看看,以后遇到这个问题就不会束手无策了。问题描述模...

关注微信公众号【开源Linux】,后台回复『10T』,领取10T学习资源大放送,涵盖Linux、虚拟化、容器、云计算、网络、Python、Go等书籍和视频 1271

NTscan扫描工具

ntscan是一个扫描器,可以扫描没有密码和弱密码的共享,先到配置文件中填写猜测的用户名和密码,扫描过程中右侧出现的是扫描日志。

IDEA的使用指南

IDEA基于java的使用手册,可以最快速的上手,在使用中不断的丰富自己的使用技巧.

连接总是被mysql回收_解决MySQL建立连接问题,快速回收复用TCP的TIME_WAIT

最近同事遇到一个问题,使用python开发的工具在执行的时候无法和MySQL建立连接,其最直接的现象就是满篇的TIME_WAIT,最后通过调整tcp_timestamps参数问题得以解决,再次记录一下这次解决的经验总结。ps:不过先汗颜一个,对基础的tcp知识太不敏感了,需要回炉重新学习啊。一、看下TIME_WAIT产生的原因大家都知道建立连接是著名的三次握手机制。那么如何关闭连接呢? 其实也是著...

weixin_35980011的博客 519

关闭tcp服务器_服务端 TCP 连接的 TIME_WAIT 问题分析与解决

民工哥技术之路 写在开头,大概 4 年前,听到运维同学提到 TIME_WAIT 状态的 TCP 连接过多的问题,但是当时没有去细琢磨;最近又听人说起,是一个新手进行压测过程中,遇到的问题,因此,花点时间,细深究一下。问题描述模拟高并发的场景,会出现批量的 TIME_WAIT 的 TCP 连接:短时间后,所有的 TIME_WAIT 全都消失,被回收,端口包括服务,均正常。即,在高并发的场景下,TIM...

weixin_39869197的博客 493

TCP大并发短连接造成TIME_WAIT问题解决办法

这两天用python写了一个TCP的短连接压力测试脚本,模拟100路并发不间断的访问。脚本运行几分钟后开始全面报错,错误代码为10048或者99,使用netstat命令查看网络发现大量的连接处于TIME_WAIT状态。 仔细阅读了《unix网络编程》相关章节,弄清楚了问题发生的原因,并找到了解决办法。 问题原因: TCP连接的Close默认行为是将socket标记为关闭然后立即返回。此时so

aaronjzhang_的专栏 4823

传输层 服务端 TCP 连接的 TIME_WAIT 过多问题的分析与解决

a、可靠的实现 TCP 全双工连接的终止:四次挥手关闭 TCP 连接过程中,最后的 ACK 是由「主动关闭连接」的一端发出的,如果这个 ACK 丢失,则,对方会重发 FIN 请求,因此,在「主动关闭连接」的一段,需要维护一个 time_wait 状态,处理对方重发的 FIN 请求;短时间后,所有的 TIME_WAIT 全都消失,被回收,端口包括服务,均正常。1.TCP 连接建立后,「主动关闭连接」的一端,收到对方的 FIN 请求后,发送 ACK 响应,会处于 time_wait 状态;

小楼一夜听春雨,深巷明朝卖杏花 991

83998 连接服务器出错_服务端 TCP 连接的 TIME_WAIT 问题分析与解决

民工哥技术之路 写在开头,大概 4 年前,听到运维同学提到 TIME_WAIT 状态的 TCP 连接过多的问题,但是当时没有去细琢磨;最近又听人说起,是一个新手进行压测过程中,遇到的问题,因此,花点时间,细深究一下。问题描述模拟高并发的场景,会出现批量的 TIME_WAIT 的 TCP 连接:短时间后,所有的 TIME_WAIT 全都消失,被回收,端口包括服务,均正常。即,在高并发的场景下,TIM...

weixin_39588983的博客 144

大量的time_wait状态tcp连接导致性能问题的解决方案,及grpc client请求优化

测试说,网站页面突然很卡。 首先kubernates集群没有报警,集群资源cpu,内存使用也还算正常。 然后查看jvm,发现并没有大量的full gc。确切的说,近期连一次full gc都没有发生。那么说明,不是pod问题,不是jvm的gc引起的。 再然后排查数据库连接,通过druid查看,发现sql也没有什么问题。 看起来一切都是这么安好。。。 转念一想,既然服务都如此正常,会不会是网络资源问题...

zhangzhen02的博客 4828

close wait 过多原因_干货分享!服务端 TCP 连接的 TIME_WAIT 问题分析与解决

写在开头,大概 4 年前,听到运维同学提到 TIME_WAIT 状态的 TCP 连接过多的问题,但是当时没有去细琢磨;最近又听人说起,是一个新手进行压测过程中,遇到的问题,因此,花点时间,细深究一下。问题描述模拟高并发的场景,会出现批量的 TIME_WAIT 的 TCP 连接:短时间后,所有的 TIME_WAIT 全都消失,被回收,端口包括服务,均正常。即,在高并发的场景下,TIME_WAIT 连...

weixin_39558521的博客 414
上一篇: 【入门篇】RTMP协议详解
下一篇: TCP连接问题之close_wait
Run_Feng
博客等级 码龄11年 144粉丝 10原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值