- 综合排序
- 最热优先
- 最新优先
- 来自专栏action的经验之路
TCP连接的TIME-WAIT状态
TIME-WAIT状态是TCP的11个状态其中之一，是发生在正常关闭TCP连接的时候发生的。
72510编辑于 2022-11-30 - 来自专栏运维研习社
Nginx通过这个配置减少TIME-WAIT
可以看到，服务端直接发送了reset，此时查看服务器连接状态，没有产生time-wait ? 从上面的分析可以看到，如果使用此配置，可以有效减少客户端网络差的情况，引起的time-wait，但是考虑下面这种场景 服务端由于并发量大，网络拥塞，客户端的确认包迟迟到不了服务端，而服务端接收不到确认包
2.6K20发布于 2021-07-06 - 来自专栏开源部署
Nginx后端服务大量TIME-WAIT的解决
keepalive的原因 keepalive的数量很难设置的准确，偏小的话就没啥作用 偏大的话会影响worker的短连接处理，都是内网 tcp连接的过程耗时应该可忽略吧，==但是带来的问题可能会造成后端服务的TIME-WAIT
1.5K30编辑于 2022-07-24 - 来自专栏呆呆熊的技术路
能跳出TIME-WAIT的坑吗
Linux 中TIME_WAIT时间为60s,并且还无法修改 TIME_WAIT过期时间宏定义 //include/net/tcp.h /* how long to wait to destroy TIME-WAIT 他是记录标记时间戳 tcp_tw_reuse 是怎么工作的 如果开启了 tcp_tw_reuse, 如果客户端发来的时间戳大于先前连接内核记录的最新时间戳, 则 Linux 将重新使用状态中的现有连接以 TIME-WAIT 用于新的对外请求连接, 状态中的传出连接 TIME-WAIT可在仅一秒之后重复使用. tcp_tw_recycle 是怎么工作的 如果开启了 tcp_tw_recycle, 则内核会记住客户端上次发来数据包的时间戳 客户端不必处理将TIME-WAIT状态推向更适合处理此问题的服务器的状态。 所以最终建议可以开启 tcp_tw_reuse, 禁用 tcp_tw_recycle. 7. 附TCP状态图 ?
1.5K20发布于 2019-12-02 - 来自专栏JMCui
tcp 连接 time-wait 状态过多问题解释
问题描述 模拟高并发的场景，会出现批量的 time-wait 的 tcp 连接： 短时间后，所有的 time-wait 全都消失，被回收，端口包括服务，均正常。 即，在高并发的场景下，time-wait 连接存在，属于正常现象。 线上场景中，持续的高并发场景： 一部分 time-wait 连接被回收，但新的 time-wait 连接产生； 一些极端情况下，会出现大量的 time-wait 连接； 所以，上述大量的 time-wait 问题分析 大量的 time-wait 状态 tcp 连接存在，其本质原因是什么？ 状态： tcp 连接中，主动关闭连接的一方出现的状态；（收到 FIN 命令，进入 time-wait 状态，并返回 ACK 命令） 保持 2 个 MSL 时间，即 4 分钟；（MSL 为 2 分钟）
1.9K30编辑于 2021-12-11 - 来自专栏微观技术
三次握手、四次挥手、TIME-WAIT、HTTP 2.0 ....
此时，客户端就进入了 TIME-WAIT 状态。注意此时客户端到 TCP 连接还没有释放，必须经过 2*MSL（最长报文段寿命）的时间后，才进入CLOSED 状态。 为什么需要四次挥手？ 客户端 TIME-WAIT ，为什么要等待 2MSL 才进入 CLOSED 状态？ 答案：MSL 是报文段在网络上最大存活时间。 确保 ACK 报文能够到达服务端，从而使服务端正常关闭连接。
67720发布于 2021-09-15 - 来自专栏sunsky
不要启用 net.ipv4.tcp_tw_recycle
关于TCP连接的TIME-WAIT状态，它是为何而生，存在的意义是什么？ 让我们回忆一下，什么是TCP TIME-WAIT状态？如下图 ? 这图中的流程不是很好理解，再看一张流程更清晰的图 ? RFC1137解释了当TIME-WAIT状态不足时将会发生什么。如果TIME-WAIT状态连接没有被快速回收，会避免什么问题呢？请看下面的例子： ? 在这种做法中，不会再有TIME-WAIT状态的SOCKET出现。 连出的TIME-WAIT状态连接，仅仅1秒后就可以被重用了。 如何确通讯安全性? TIME-WAIT的第一个作用是避免新的连接（不相关的）接收到重复的数据包。 除非TIME-WAIT状态已经过期。
8.2K21发布于 2020-08-20 - 来自专栏笔记+
TCP ACK loop导致软中断高问题分析
观察一段时间后发现有几百个TIME-WAIT socket一直没有释放，理论上TIME-WAIT超时后会自动回收掉 image.png （3）排除端口存在复用： ss命令查看其中一个一直为time-wait 设置为0后time-wait数量仍然没有减少可以排除是端口复用导致的time-wait不释放。 （4）排查time-wait不释放原因 系统tcp_tw_recycle设置为0没有开启快速回收，timewait的数量也没有超过net.ipv4.tcp_max_tw_buckets设置的值正常情况下 time-wait数量没有超过net.ipv4.tcp_max_tw_buckets设置的值并且没有开启快速回收time-wait功能时，time-wait状态的socket会在到达TCP_TIMEWAIT_LEN （60s）后被回收，那么这里time-wait 状态不回收的原因是什么呢？
1.9K50发布于 2020-06-02 - 来自专栏johnnyxsu技术交流分享
玩转CVM之tw_reuse和tw_recycle 罪与罚
允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭 net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收 net.ipv4.tcp_tw_reuse TIME-WAIT状态是为了防止不相关的延迟请求包被接收。 此时处在TIME-WAIT状态连接，仅仅1秒后就可以被重用了。 作为客户端因为有端口65535限制的问题，TIME-WAIT状态的连接过多直接影响处理能力，打开tw_reuse 即可解决该问题。 总结 最合适的解决方案是增加更多的四元组数目，比如，服务器可用端口，或服务器IP，让服务器能容纳足够多的TIME-WAIT状态连接。 在客户端上启用net.ipv4.tcp_tw_reuse，还算稍微安全的解决TIME-WAIT的方案。
8.8K1590发布于 2019-07-24 - 来自专栏首富手记
服务之间调用连接不上运维层面问题分析
所以从 这个问题开始着手分析；监控数据如下 然后怀疑是 TCP timeout 连接数过多产生的问题，针对这方面进行排查 排查过程 查看系统默认 tcp 相关指标 # 是否允许将TIME-WAIT sockets重新用于新的TCP连接，默认是否 [root@idc-111 ~]# cat /proc/sys/net/ipv4/tcp_tw_reuse 0 # 是否开启TCP连接中TIME-WAIT 0 0 172.16.102.220:60001 172.16.102.221:80 TIME-WAIT 0 0 172.16.102.220 0 0 172.16.102.220:60001 172.16.102.221:80 TIME-WAIT 0 0 172.16.102.220 :443 TIME-WAIT 0 0 172.16.102.220:60000 172.16.102.221:443 可以看到相同目标 ip 不同目标端口下
89330编辑于 2022-01-12 - 来自专栏王亚昌的专栏
短连接过多时,TIME_WAIT问题解决
日常运维中用netstat -an命令发现服务器中有大量状态为TIME-WAIT的TCP连接，于是用/sbin/sysctl -a查看了一下Linux的各项内核参数，并翻阅有关资料，决定修改其中的两项参数 ，以达到减少TCP连接中TIME-WAIT sockets的目的。 允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭； net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收
1.3K30发布于 2018-08-03 - 来自专栏爬虫逆向案例
TCP connection timed out:110 (Scrapy)
连接超时’’ 的错误 ，错误状态码110 TCP : 传输控制协议，是一种可靠的面向连接的协议 从客户端来看，在我们的应用场景中，因为频繁的使用短连接，而且在同一台机上的客户端的数量比较多，造成了大量的 TIME－WAIT 状态的端口，当 TIME－WAIT 状态端口的数量铺满了整个 port_range 范围后，就会产生 99 号错误；从服务端来看，因为频繁大量的 accept 短连接，到达一定量后，服务端口的 listen 状态：是连接一端主动关闭并发送完最后一个 ACK 之后所处的状态，（即首先调用close()发起主动关闭的一方，在发送最后一个ACK之后会进入time-wait状态）。 为了避免混淆在 TIME-WAIT 状态连接上的处理的包是前一个连接迟到的包还是新连接的包，TCP 协议规定在整个 TIME－WAIT 状态下，不能再建立同样的连接。并且会检测端口的使用情况。 短连接过多，会导致TIME－WAIT溢出，端口无法使用，从而TCP连接超时。
1.6K20发布于 2021-11-22 - 来自专栏学习日记
TCP协议细节学习
TIME-WAIT状态 主动关闭的一方收到对端发出的FIN报之后，就从FIN-WAIT-2状态切换到TIME-WAIT状态了，再等待2MSL时间才再切换到CLOSED状态。 TIME-WAIT状态如果过多，会占用系统资源。Linux下有几个参数可以调整TIME-WAIT状态时间： net.ipv4.tcp_tw_reuse = 1 表示开启重用。 允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭。 net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。 然而，从TCP状态转换图可以看出，主动进行关闭的链接才会进入TIME-WAIT状态，所以最好的办法：尽量不要让服务器主动关闭链接，除非一些异常情况，如客户端协议错误、客户端超时等等。
71040发布于 2019-06-11 - 来自专栏码农桃花源
高并发服务遇 redis 瓶颈引发的事故
下面是出问题节点的 TCP 连接状况，可以看到 established 在 6w，而time-wait 连接干到 2w 多个。 ? 为什么会产生这么多 time-wait？ 另外，linux 主机被 ops 交付时应该有做内核调优初始化的，在开启 tw_reuse 参数后，time-wait 是可以复用的。难道是没开启 reuse？ 查看 sysctl.conf 的内核参数得知，果然 tcp_tw_reuse 参数没有打开，不能快速地复用还处在 time-wait 状态的地址，只能等待 time-wait 的超时关闭，rfc 协议里规定等待 内在问题 追究问题 上面是表象问题，来查查为什么会有这么多的 time-wait ？再说一遍，通常哪一端主动 close fd，哪一端就会产生 time-wait。 事后通过 netstat 得知 time-wait 连接基本是来自 redis 主机。 下面是推送代码中的连接池配置，空闲连接池只有 50，最大可以 new 的连接可以到 500 个。
66550发布于 2021-02-01 - 来自专栏全栈程序员必看
TCP四次挥手过程
ESTABLISHED -> A终止等待1状态FIN-WAIT-1 -> B关闭等待状态2CLOSE-WAIT -> A终止等待2状态FIN-WAIT-2 -> B最后确认状态LAST-ACK -> A时间等待状态TIME-WAIT 第四次挥手：A收到B的连接释放报文段后，对此发出确认报文段（ACK = 1，seq=u+1，ack=w+1）,A进入TIME-WAIT（时间等待）状态。 为什么A在TIME-WAIT状态必须等待2MSL（最大报文生存时间）的时间？ 1.保证A发送的最后一个ACK报文段能够到达B，保证A、B正常进入CLOSED状态。 +ACK报文段的确认，B超时重传FIN+ACK报文段，A能2MSL时间内收到这个重传的FIN+ACK报文段，接着A重传一次确认，同时重启2MSL计数器，2MSL时间后A和B进入CLOSE状态，如果A在TIME-WAIT
56420编辑于 2022-09-05 - 来自专栏luxixing
Linux操作系统内核参数优化
net.ipv4.tcp_keepalive_time 当keepalive起作用的时候，tcp发送keepalive消息的频度，默认2小时 # net.ipv4.tcp_tw_reuse 开启重用 允许将状态为TIME-WAIT 的sockets 重新用于新的tcp连接，默认为0(关闭) # net.ipv4.tcp_tw_recycle 开启tcp连接中TIME-WAIT状态的socket的快速回收,默认0(关闭) # net.ipv4.ip_local_port_range 用于向外连接的端口范围，默认 32768 61000 # net.ipv4.tcp_max_tw_buckets 表示系统同时保持TIME-WAIT 状态的socket连接的最大数量，超过则清除TIME-WAIT状态socket连接，并打印警告信息，默认18000 # net.ipv4.route_max_size 路由缓存最大值 # kernel.core_pattern
4.1K40发布于 2019-05-28 - 来自专栏nginx
Linux网络性能优化与监控实战指南：从参数调优到请求分析
ip_local_reserved_ports=9100 # 调整本地端口范围（默认32768-60999） sysctl -w net.ipv4.ip_local_port_range="1024 61999" # 允许复用TIME-WAIT somaxconn cat /proc/sys/net/core/somaxconn 避免TCP连接队列溢出 tcp_tw_reuse sysctl net.ipv4.tcp_tw_reuse 减少TIME-WAIT 实时监控TCP连接状态 watch -n 1 "ss -ant | awk 'NR>1 {print \$1}' | sort | uniq -c" 输出示例： ESTAB 500 TIME-WAIT static_configs: - targets: ['localhost:9100'] 在Grafana中可视化： TCP连接数 请求延迟分布 五、常见问题与解决方案 问题1：TIME-WAIT 状态过多 现象： ss -ant | grep -c 'TIME-WAIT' # 返回数>10000 解决： echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse echo
34510编辑于 2025-11-15 - 来自专栏耕耘实录
Linux 系统管理没有 netstat ，不惆怅！ 拥抱 ss ，事半功倍
synchronized|bucket|big|TCP-STATES} TCP-STATES := {established|syn-sent|syn-recv|fin-wait-{1,2}|time-wait |close-wait|last-ack|closing} synchronized := {established|syn-recv|fin-wait-{1,2}|time-wait|close-wait |last-ack|closing} bucket := {syn-recv|time-wait} big := {established|syn-sent |close-wait|last-ack|closing} synchronized := {established|syn-recv|fin-wait-{1,2}|time-wait|close-wait |last-ack|closing} bucket := {syn-recv|time-wait} big := {established|syn-sent
4.8K50发布于 2019-07-04 - 来自专栏服务端思维
高并发服务遇 redis 瓶颈引发的事故
下面是出问题节点的 TCP 连接状况，可以看到 established 在 6w，而time-wait 连接干到 2w 多个。 ? 为什么会产生这么多 time-wait？ 另外，linux 主机被 ops 交付时应该有做内核调优初始化的，在开启 tw_reuse 参数后，time-wait 是可以复用的。难道是没开启 reuse？ 查看 sysctl.conf 的内核参数得知，果然 tcp_tw_reuse 参数没有打开，不能快速地复用还处在 time-wait 状态的地址，只能等待 time-wait 的超时关闭，rfc 协议里规定等待 内在问题 追究问题 上面是表象问题，来查查为什么会有这么多的 time-wait ？再说一遍，通常哪一端主动 close fd，哪一端就会产生 time-wait。 事后通过 netstat 得知 time-wait 连接基本是来自 redis 主机。 下面是推送代码中的连接池配置，空闲连接池只有 50，最大可以 new 的连接可以到 500 个。
99120发布于 2021-01-28 - 来自专栏算法修养
Nginx 日志 worker_connections are not enough while connecting to upstream
第四次，A服务器接受FIN报文，发送ACK报文给B，进入TIME-WAIT状态，B接受ACK报文，关闭连接。 A服务器能不能发送完ACK之后不进入TIME_WAIT就直接进入CLOSE状态呢？ 然后这样的设置根本无济于事，因为问题的原因可能不再并发量这里，于是我又把注意力转移到tcp连接的TIME-WAIT上。因为很多时候，站点负荷大是因为出现了大量的TIME-WAIT的tcp连接。 tcp连接主动关闭的一方会进入TIME-WAIT状态，这个状态会持续比较久的时间，这样如果有大量的tcp处于TIME-WAIT状态： 网络情况不好时，如果主动方无TIME_WAIT等待，关闭前个连接后， ，但是我太天真了，Linux系统对于TIME-WAIT 有一个处理机制TIME-WAIT的tcp连接很快被回收关闭，并没有占有很长时间。 现在还不知道为什么会有这些处于TIME-WAIT的本地tcp连接： ?
3K100发布于 2018-04-27
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号