前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
社区首页 >专栏 >TCP的TIME_WAIT和CLOSE_WAIT状态

TCP的TIME_WAIT和CLOSE_WAIT状态

作者头像
opencode
发布于 2022-12-26 07:32:44
发布于 2022-12-26 07:32:44
7310
举报
文章被收录于专栏:知识同步知识同步

面试中常问的问题

很多面试中,特别是后端岗位,特别是和服务器相关岗位的面试中喜欢问这两个状态,首先回忆下这两个状态出现的时间,下面是三次握手和四次挥手的状态图

TIME_WAIT

TIME_WAIT是出现在主动关闭的一端,一般是客户端,在收到服务端发来的FIN报文之后进入TIME_WAIT,TIME_WAIT的时间一般是2MSL,1MSL是30秒,主要是等待某些在网络延迟的报文到达,从而正确关闭

那如果服务器这时候出现大量的TIME_WAIT状态,会是什么原因呢

首先出现TIME_WAIT状态是正常的,如果是在服务器出现,那么一般可能是有以下两个原因,

原因

  1. 大量的短连接
  2. 服务器主动关闭
  3. http请求头没有设置keep_alive,而是close

第一种情况就是连接时长很短,导致连接关闭后进入TIME_WAIT状态,并且大量的短连接同时进行

第二种情况就是像某些爬虫服务器可能会主动断开连接,那这时候服务器会进入TIME_WAIT状态

第三种就是请求不是一个长连接,如果客户端挂机后,服务器超时会主动断开

所以针对以上情况,有以下解决方法:

解决方法

  1. 在业务层尽量避免服务端主动关闭
  2. http请求头设置keep_alive
  3. 服务端开启TIME_WAIT复用选项,设置net.ipv4.tcp_reuse=1和net.ipv4.tcp_timestamps=1

大量的TIME_WAIT状态会导致新连接创建失败,因为端口只有65535个,端口不够用了会报错

CLOSE_WAIT

原因

CLOSE_WAIT是服务端收到FIN报文后,发出最后一个FIN报文前的状态,所以出现CLOSE_WAIT有很大可能是服务端没有及时发送出FIN报文,也就是没有主动close或者shutdown,这种一般是代码写得有问题

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2021-08-11,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
TCP TIME_WAIT 过多怎么处理
TCP 断开连接四次挥手过程中,主动断开连接的一方,在第四次挥手(回复 ACK 报文)后,会进入 TIME_WAIT 状态,等待 2*MSL 后才进入 CLOSE 状态。
恋喵大鲤鱼
2024/02/03
3950
TCP TIME_WAIT 过多怎么处理
为什么 TCP 需要 TIME_WAIT ?
客户端需要维护一个 TIME_WAIT 状态长达 2 个 MSL 时间,以 Linux 5.0 代码为例,也就是 2 分钟。
ICT系统集成阿祥
2024/12/03
1060
为什么 TCP 需要 TIME_WAIT ?
【计网】从零开始理解TCP协议 --- TIME_WAIT状态 , CLOSE_WAIT状态,流量控制机制,滑动窗口机制
在四次挥手问题中,客户端向服务端发送FIN请求断开连接,服务端返回应答,并也发送一个FIN请求进行断开连接,客户端收到后就返回应答。这里服务端发送ACK和FIN可以合并为一次,所以也能成为三次挥手!所以建立连接和断开连接本质上是没有区别的,那为什么还要强调四次挥手呢?因为一方端口连接,另一方可能还有需要发送的数据,所以有可能是进行四次挥手。
叫我龙翔
2024/10/19
700
【计网】从零开始理解TCP协议 --- TIME_WAIT状态 , CLOSE_WAIT状态,流量控制机制,滑动窗口机制
再叙TIME_WAIT
之所以起这样一个题目是因为很久以前我曾经写过一篇介绍TIME_WAIT的文章,不过当时基本属于浅尝辄止,并没深入说明问题的来龙去脉,碰巧这段时间反复被别人问到相关的问题,让我觉得有必要全面总结一下,以备不时之需。
LA0WAN9
2021/12/14
3560
再叙TIME_WAIT
一分钟告诉面试官TIME_WAIT
[FIN_WAIT1] :FIN_WAIT1和FIN_WAIT2均为等待对方的FIN报文。两者区别为,当SOCKET在ESTABLISHED状态时,想主动关闭连接从而想对方发送FIN报文,此时进入FIN_WAIT1状态。当收到ACK报文进入FIN_WAIT2状态。
我是程序员小贱
2020/06/29
1.5K0
[tcp] 服务端大量close_wait 和 time_wait状态
我开发的某个服务出现这个状态 , 出现了大量的close_wait , 占满了单进程的连接数1024
唯一Chat
2021/05/24
1.8K0
[tcp] 服务端大量close_wait 和 time_wait状态
谈谈 TCP 的 TIME_WAIT
最近有同事在用 ab 进行服务压测,到 QPS 瓶颈后怀疑是起压机的问题,来跟我借测试机,于是我就趁机分析了一波起压机可能成为压测瓶颈的可能,除了网络 I/O、机器性能外,还考虑到了网络协议的问题。
枕边书
2019/05/25
8940
网络连接存在大量time_wait和close_wait的原因以及解决方法
如果对tcp中的握手挥手不了解的同学,请先看这篇博客:《关于三次握手与四次挥手你要知道这些》。
全菜工程师小辉
2021/06/25
3.8K0
网络连接存在大量time_wait和close_wait的原因以及解决方法
TCP time_wait close_wait问题(可能是全网最清楚的例子)
测试老大看到了,根据经验就推测是应该是文件句柄使用完了,应该有TCP连接很多没释放,果真发现是很多CLOSE_WAIT的状态
千往
2019/11/21
4.1K0
大量的 TIME_WAIT 状态连接怎么处理?(文末有福利)
Nginx 作为反向代理时,大量的短链接,可能导致 Nginx 上的 TCP 连接处于 time_wait 状态:
范蠡
2020/08/07
8.6K0
大量的 TIME_WAIT 状态连接怎么处理?(文末有福利)
如何优化高并发TCP链接中产生的大量的TIME_WAIT的状态
线上有几台QPS每秒几万请求的服务器,大致访问链路如下:client -> nginx -> web 服务器,由于每台机器上混布了多个web服务并通过nginx反向代理统一分发请求,在服务升级的时候经常出现端口被占用的情况,排查问题时,发现系统过存在几万多个 time_wait状态。统计命令如下:
我是攻城师
2020/02/25
27.4K3
TCP连接的TIME_WAIT和CLOSE_WAIT 状态解说-运维笔记
相信很多运维工程师遇到过这样一个情形: 用户反馈网站访问巨慢, 网络延迟等问题, 然后就迫切地登录服务器,终端输入命令"netstat -anp | grep TIME_WAIT | wc -l " 查看一下, 接着发现有几百几千甚至几万个TIME_WAIT 连接数. 顿时慌了~
洗尽了浮华
2018/11/21
3.2K0
终于搞懂了服务器为啥产生大量的TIME_WAIT!
写在开头,大概 4 年前,听到运维同学提到 TIME_WAIT 状态的 TCP 连接过多的问题,但是当时没有去细琢磨;最近又听人说起,是一个新手进行压测过程中,遇到的问题,因此,花点时间,细深究一下。
用户1107783
2023/11/02
1.9K0
终于搞懂了服务器为啥产生大量的TIME_WAIT!
tcp的四次挥手(为什么三次握手和四次挥手)
在断开连接之前客户端和服务器都处于ESTABLISHED状态,双方都可以主动断开连接,以客户端主动断开连接为优。
全栈程序员站长
2022/07/29
7420
tcp的四次挥手(为什么三次握手和四次挥手)
一次TIME_WAIT和CLOSE_WAIT故障和解决办法
里头的分析过程有提到,通过查看服务器网络状态检测到服务器有大量的CLOSE_WAIT的状态。
sunsky
2020/08/20
7310
一个TCP TIME_WAIT过高引起的连接mysql超时案例
     客户将mysql从IDC迁移至公有云后,时常有出现建立连接超时的情况,业务使用的场景是PHP短连接到mysql,每秒的新建连接数在3000个左右,这个量算是比较大。 客户反馈在IDC内自建时也是这样的使用场景,从未遇到过这个问题。
腾讯云数据库 TencentDB
2019/04/02
5.2K1
一个TCP TIME_WAIT过高引起的连接mysql超时案例
实践解读CLOSE_WAIT和TIME_WAIT
CLOSE_WAIT和TIME_WAIT是如何产生的?大量的CLOSE_WAIT和TIME_WAIT又有何隐患?本文将通过实践角度来带你揭开CLOSE_WAIT和TIME_WAIT的神秘面纱!遇事不决先祭此图:
果冻虾仁
2021/12/08
1.4K0
实践解读CLOSE_WAIT和TIME_WAIT
TCP四次挥手和TIME_WAIT
FIN_WAIT_1 : FIN_WAIT_1和FIN_WAIT_2状态的真正含义都是表示等待对方的FIN报文。而这两种状态的区别是: FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时,它想主动关闭连接,向对方发送了FIN报文,此时该SOCKET即进入到FIN_WAIT_1状态。而当对方回应ACK报文后,则进入到FIN_WAIT_2状态,当然在实际的正常情况下,无论对方何种情况下,都应该马上回应ACK报文,所以FIN_WAIT_1状态一般是比较难见到的,而FIN_WAIT_2状态还有时常常可以用netstat看到。(主动方)
全栈程序员站长
2022/08/25
5390
TCP四次挥手和TIME_WAIT
聊聊TCP中最能整活的TIME_WAIT
TCP 四次挥手,在四次挥手的过程中,发起连接断开的一方会有一段时间处于 TIME_WAIT 的状态,你知道 TIME_WAIT 是用来做什么的么?
穿过生命散发芬芳
2025/01/18
510
tcp 连接 time-wait 状态过多问题解释
网络上类似的图有很多,但是有的细节不够,有的存在误导。有的会把两条线分别标记成 client 和 server。给读者造成困惑。对于断开连接这件事,客户端和服务端都能作为主动方发起,也就是 active close 可以是客户端,也可以是服务端。而对端相应的就是 passive close。不管谁发起,状态迁移如上图。
JMCui
2021/12/11
1.6K0
tcp 连接 time-wait 状态过多问题解释
相关推荐
TCP TIME_WAIT 过多怎么处理
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档
查看详情【社区公告】 技术创作特训营有奖征文