- 综合排序
- 最热优先
- 最新优先
- 来自专栏程序猿成长计划
Time_Wait详解(译文)
其中一些错误是因为对TIME_WAIT状态不理解导致的。 在本文中，我将会讲解为什么要存在TIME_WAIT 状态，它的存在所造成的一些问题以及如何解决这些问题。 之所以TIME_WAIT能够影响系统的扩展性是因为在一个TCP连接中，一个Socket如果关闭的话，它将保持TIME_WAIT状态大约 4分钟 。 Windows下并不是这样做的，它只防止完全匹配的处于TIME_WAIT状态的出站连接的建立。 入站连接很少会被TIME_WAIT影响。 但是，累积在服务端的处于TIME_WAIT状态的连接可能会影响性能和资源的使用，因为处于TIME_WAIT状态的连接最终都会超时，这就需要服务器对超时进行处理，并且在TIME_WAIT状态结束之前都会占用服务器的资源 ，让TIME_WAIT不再成为问题。
5.8K20发布于 2019-02-27 - 来自专栏网络 后台
TCP TIME_WAIT
TCP TIME_WAIT状态理解： 下面是tcp状态图（来自下面的参考文章）： tcp_flow.png 从图中可以看出，若服务器主动关闭连接，在四次挥手的最后一个ACK后连接端口会变为TIME_WAIT TIME_WAIT状态限制是比较严格的，设置TIME_WAIT状态主要有两个目的： 1、为了防止一个连接的延迟分段被后面新建的连接接收。 从上述两点原因来看， 有TIME_WAIT状态是比较保险的。 ---- TCP TIME_WAIT可能出现问题以及参数调整: 当服务器上存在大量连接的时候，TIME_WAIT状态就会变得比较麻烦，连接表里有大量处于TIME_WAIT状态的连接，会导致新的连接不能够建立 为了保证开启选项后， 也能达到TIME_WAIT状态同样的效果，它会记录远程端发来数据的最新时间戳，在TIME_WAIT状态生效期内，放弃所有时间戳小于记录时间戳的包。
2.5K00发布于 2018-12-06 - 来自专栏全栈程序员必看
什么是TIME_WAIT
TIME_WAIT是怎样产生的？ 因为TCP连接是双向的，所以在关闭连接的时候，两个方向各自都需要关闭。先发FIN包的一方执行的是主动关闭； 后发FIN包的一方执行的是被动关闭。 主动关闭的一方会进入TIME_WAIT状态，并且在此状态停留两倍的MSL时长。 什么是MSL？ MSL指的是报文段的最大生存时间，如果报文段在网络活动了MSL时间，还没有被接收，那么会被丢弃。 就是一分钟，也就是60秒，并且这个数值是硬编码在内核中的， 也就是说除非你重新编译内核，否则没法修改它： #define TCP_TIMEWAIT_LEN (60*HZ) linux系统下怎样修改TIME_WAIT
62130编辑于 2022-09-05 - 来自专栏开源部署
谈谈 TCP 的 TIME_WAIT
TIME_WAIT 定义 我们从上面的图中可以看出来，当 TCP 连接主动关闭时，都会经过 TIME_WAIT 状态。 此时， TIME_WAIT 的存在是为了保证网络中迷失的数据包正常过期。 由以上两个原因，TIME_WAIT 状态的存在是非常有意义的。 时长的确定 由原因来推实现，TIME_WAIT 状态的保持时长也就可以理解了。确定 TIME_WAIT 的时长主要考虑上文的第二种情况，保证关闭连接后这个连接在网络中的所有数据包都过期。 登上服务器一看，果然，有大量的 TIME_WAIT 状态的连接。 但是由于服务器监听的端口会复用，这些 TIME_WAIT 状态的连接并不会对服务器造成太大影响，只是会占用一些系统资源。 小结 当然，高并发情况下，太多的 TIME_WAIT 也会给服务器造成很大的压力，毕竟维护这么多 socket 也是要消耗资源的，关于如何解决 TIME_WAIT 过多的问题，可以看 tcp短连接TIME_WAIT
76820编辑于 2022-07-26 - 来自专栏Greenplum
TIME_WAIT 的那些事
19.2 TIME_WAIT 的那些事 19.2.1 描述 我们知道 TCP 在关闭连接的时候，主动断开的一方将处于 TIME_WAIT 状态，并将持续两倍的 MSL。 这个 MSL 在 RFC 793 中的建议是 1 分钟，但是很多系统实现都是 30 秒，所以 TIME_WAIT 的时长也就是 1 分钟。 这个参数实在内核中设置的，如果想修改需要重新编译内核参数，查看可以使用ss 来查看 TIME_WAIT 的剩余存活时长(netstat 也可以 -o 参数) 19.2.2 查看TIME_WAIT $ ss 当然，TCP Timer 除了 TIME_WAIT 这种，还有 KEEPALIVE, ON, OFF 三种类型。 19.2.3 查看KEEPALIVE状态 $ netstat -otn ?
97430发布于 2019-08-02 - 来自专栏火丁笔记
再叙TIME_WAIT
虽然一个TIME_WAIT网络连接耗费的资源无非就是一个端口、一点内存，但是架不住基数大，所以这始终是一个需要面对的问题。 为什么会存在TIME_WAIT？ 如何控制TIME_WAIT的数量？ 从前面的描述我们可以得出这样的结论：TIME_WAIT这东西没有的话不行，不过太多可能也是个麻烦事。 tcp_tw_recycle：顾名思义就是回收TIME_WAIT连接。 tcp_tw_reuse：顾名思义就是复用TIME_WAIT连接。当创建新连接的时候，如果可能的话会考虑复用相应的TIME_WAIT连接。 参考文档： tcp短连接TIME_WAIT问题解决方法大全（1）——高屋建瓴 tcp短连接TIME_WAIT问题解决方法大全（2）——SO_LINGER tcp短连接TIME_WAIT问题解决方法大全（
50030编辑于 2021-12-14 - 来自专栏枕边书
谈谈 TCP 的 TIME_WAIT
TIME_WAIT ---- 定义 我们从上面的图中可以看出来，当 TCP 连接主动关闭时，都会经过 TIME_WAIT 状态。 此时， TIME_WAIT 的存在是为了保证网络中迷失的数据包正常过期。 由以上两个原因，TIME_WAIT 状态的存在是非常有意义的。 时长的确定 由原因来推实现，TIME_WAIT 状态的保持时长也就可以理解了。确定 TIME_WAIT 的时长主要考虑上文的第二种情况，保证关闭连接后这个连接在网络中的所有数据包都过期。 登上服务器一看，果然，有大量的 TIME_WAIT 状态的连接。 但是由于服务器监听的端口会复用，这些 TIME_WAIT 状态的连接并不会对服务器造成太大影响，只是会占用一些系统资源。 TIME_WAIT问题解决方法大全（1）——高屋建瓴。
1.1K10发布于 2019-05-25 - 来自专栏全栈程序员必看
为什么要Time_wait
Time_wait 啊，老哥们肯定会想，time_wait什么鬼? 为毛我主动断开tcp连接。发完最后一个ACK后不能直接断开连接啊，我能做的都做了。但是….. 所以time_wait时间俩个MSL。 所以说time_wait 就是为了防止在连接上有多个重传的FIN包出现，所以必须time_wait这个是为了防止当再一次建立相同的新连接时防止收到老连接的数据包从而导致的影响。 不知道这波解释为什么time_wait，老哥们听懂了没有 对于为什么3次握手？为毛不是2次/4次?
36620编辑于 2022-09-02 - 来自专栏后端技术
TCP TIME_WAIT解决办法
** 若TIME_WAIT事件设置过短, 会导致错误后果 TIME_WAIT结束过早, 导致之前迷失的第三次握手突然到达, 新连接突然成功 ? TIME_WAIT结束过早, 若最后的ACK丢失, 却过早结束TIME_WAIT, 导致新连接发起连接请求时, 旧连接还未关闭状态, 拒绝连接 小总结 最合适的解决方案是增加更多的四元组数目, 比如, 状态socket, tcp_tw_recycle处理更激进，它会快速回收TIME_WAIT状态的socket。 可主动跳过TIME_WAIT 从上面的tcp_time_wait源码也可以看出, 当TIME_WAIT状态的socket数量超过tcp_max_tw_buckets选项指定的数量值时，会直接关闭socket 若把tcp_max_tw_buckets选项设置为0，则可以直接跳过TIME_WAIT状态。
2.6K21发布于 2019-12-24 - 来自专栏golang云原生new
为什么需要 TIME_WAIT 状态
还是用一下上一篇文章画的图 TCP 的 11 个状态，每一个状态都缺一不可，自然 TIME_WAIT 状态被赋予的意义也是相当重要，咱们直接结论先行 上文我们提到 tcp 中，主动关闭的一边会进入 TIME_WAIT 状态， 另外 Tcp 中的有 TIME_WAIT 状态，主要是有如下 2 个原因： 为了防止被动关闭一方的延迟数据被其他连接窃取 为了防止被动关闭的一方，没有收到最后的一个 ACK 包 如何理解呢？ 为了防止被动关闭一方的延迟数据被其他连接窃取 对于第一个 咱们一个一个的来详细解释一下，还是上面这个图，咱们人为的加一点异常的情况 咱们在 tcp 连接中，客户端先发起关闭，那么 TIME_WAIT 状态，或者咱们人为的将 TIME_WAIT 的值设小，就会出现 seq=100 这个包不能正常的被 client 收到，因为 client 已经是 CLOSED 状态了 这个时候，和 client 占用同一端口的程序 状态存在，或者是正常保持 2MSL 的时间，就不会出现这个情况 ，1 个 MSL 是报文在网络环境中的最大存活时间，对于上面这个例子， client 现在那就还是 TIME_WAIT 状态， client
83130编辑于 2023-09-12 - 来自专栏数通
为什么 TCP 需要 TIME_WAIT ?
通过 TIME_WAIT 状态，发起主动关闭连接的一端会等待 2 个 MSL 时间，这个时间足够长，可以最大限度消除延迟的数据包可能对新 (复用端口) 的连接造成影响， TIME_WAIT 状态下接收到的延迟数据包会被直接丢弃 状态的作用之外，什么场景下会出现大量的 TIME_WAIT 状态连接呢？ 通信双方主动发起关闭连接的一端，存在 TIME_WAIT 状态，最经典的场景就是 并发压力测试。 :59472 TIME_WAIT tcp6 0 0 1.1.1.1:443 127.0.0.1:59480 TIME_WAIT tcp6 TIME_WAIT 这类问题如何解决，后面再专门写一篇高性能网络编程中 TCP 调优的文章 :-)。
37110编辑于 2024-12-03 - 来自专栏任浩强的运维生涯
TIME_WAIT状态过多的排查
一、概述 （一）现象 服务器有两个现象，第一是tcp连接数不多，不超过10个，但是time_wait状态的2000。 2．下图是连接中本地的IP 命令：netstat -tn|grep TIME_WAIT|awk '{print $4}'|sort|uniq -c|sort -nr|head ? 排名第一这个是我们本地IP，6601是api项目的监听端口，从这里可以看出在所欲的TIME_WAIT状态的TCP里面，API项目的后端是被请求最多的那个。估计反向代理服务器也被请求了很多。 而每次请求API项目就返回了access_token，API返回数据之后就发出断开信号，逻辑和现象很符合，也可以断定TIME_WAIT的状态也是这请求引起。 而TIME_WAIT不是不回收，而是回收了，但不断的生成。
3.8K00发布于 2018-08-08 - 来自专栏陶士涵的菜地
time_wait与长连接短连接
服务端上查看tcp连接的建立情况,直接使用netstat命令来统计,看到了很多的time_wait状态的连接.这些状态是tcp连接中主动关闭的一方会出现的状态.该服务器是nginx的webserver监听 先查看本机监听80端口的time_wait状态,可以看到不同客户端的ip端口,来连接我的服务端,并且是我服务端主动关闭连接,因此可以看到time_wait,这些对我们服务器没有影响.因为这是http的短连接 比如我需要连接数据库的3960端口,这个时候我的服务器会随机占用本机的端口,连接远程的3960端口.因为php连接数据库是使用的短连接,每次请求都会在创建连接,并且是我服务端主动关闭的连接,所以会有大量time_wait
1.8K30发布于 2019-11-07 - 来自专栏宜信技术实践
TCP漫谈-之keepalive和time_wait
二、TCP Time_wait 第二个希望和大家分享的话题是TCP的Time_wait状态。、 ? 为啥需要time_wait状态呢？为啥不直接进入closed状态呢？ 为此设计了time_wait状态。在高并发情况下，如果能将time_wait的TCP复用， time_wait复用是指可以将处于time_wait状态的连接重复利用起来。 从time_wait转化为established，继续复用。Linux内核通过net.ipv4.tcp_tw_reuse参数控制是否开启time_wait状态复用。 读者可能很好奇，之前不是说time_wait设计之初是为了解决上面两个问题的吗？如果直接复用不是反而会导致上面两个问题出现吗？ 最后还需要提醒读者的是，Linux 4.1内核版本之前除了tcp_tw_reuse以外，还有一个参数tcp_tw_recycle，这个参数就是强制回收time_wait状态的连接，它会导致NAT环境丢包
2.6K20发布于 2020-04-09 - 来自专栏全栈程序员必看
TIME_WAIT过多的解决办法
TIME_WAIT存在的两个理由： 1 可靠的实现TCP全双工连接的终止 2 允许老的重复的分节在网络上的消逝 第一个：如果客户端不维持TIME_WAIT状态，那么将响应给服务端一个RST，该分节被服务器解释成一个错误 为做到这一点，TCP将不给处于TIME_WAIT状态的连接发起新的化身。 下面主要讨论TIME_WAIT对短连接的影响： 正常的TCP客户端连接在关闭后，会进入一个TIME_WAIT的状态，持续的时间一般在1~4分钟，对于连接数不高的场景，1~4分钟其实并不长，对系统也不会有什么影响 举例来说：假设每秒建立了1000个短连接（Web场景下是很常见的，例如每个请求都去访问memcached），假设TIME_WAIT的时间是1分钟，则1分钟内需要建立6W个短连接， 由于TIME_WAIT 对于应对短连接导致的大量TIME_WAIT连接问题，个人认为第二种处理是最优的选择，libmemcached就是采用这种方式， 从实测情况来看，打开这个选项后，TIME_WAIT连接数为0，且不受网络组网
1.4K20编辑于 2022-06-27 - 来自专栏C/C++基础
TCP TIME_WAIT 过多怎么处理
1.什么是 TCP TIME_WAIT？ 2.为什么要 TIME_WAIT? 这个值默认为 18000，当系统中处于 TIME_WAIT 的连接一旦超过这个值时，新的 TIME_WAIT 连接会被立即销毁，并打印警告，这个方法比较暴力。 程序中使用 SO_LINGER。 这为跨越 TIME_WAIT 状态提供了一个可能，不过是一个非常危险的行为，不值得提倡。 5.小结 TIME_WAIT 是我们的朋友，不要试图避免这个状态，而是应该弄清楚它。 如果服务端要避免过多的 TIME_WAIT 状态的连接，就永远不要主动断开连接，让客户端去断开，由分布在各处的客户端去承受 TIME_WAIT。
93520编辑于 2024-02-03 - 来自专栏运维研习社
关于TIME_WAIT优化，必须要了解的……
此时， TIME_WAIT 的存在是为了保证网络中迷失的数据包正常过期。 第一种场景下，TIME_WAIT是为了确保被动关闭方收到ACK，连接正常关闭，且不因被动关闭方重传FIN影响下一个连接 第二种场景下，TIME_WAIT保留2个MSL，以确保数据不会丢失 注释：MSL( 状态来解决，由此可见TIME_WAIT并不是完全不存在才是合理的或以消除TIME_WAIT为优化的一个目标 那么TIME_WAIT具体要怎么优化，什么样的状态是一个合理的状态？ 溢出状态，默认是4096 当弃用reuse的时候，在一个高并发的服务器上，TIME_WAIT并不会快速回收，而是复用之前的链接，这样的情况下TIME_WAIT必然会保持一定的数量，那么tw_buckets 之上，虽然长时间大量TIME_WAIT会消耗一定的内存资源，但是对于现在的服务器，TIME_WAIT所占用的内存是可以容忍的 总结： 结合上面的分析，recycle在内核4.1以后就被弃用了，所以它并不是
1.5K20发布于 2021-07-06 - 来自专栏earthchen的专栏
服务器TIME_WAIT和CLOSE_WAIT
time_wait和close_wait tcp连接和关闭中常见的三种状态是: ESTABLISHED 表示正在通信 TIME_WAIT 表示主动关闭 CLOSE_WAIT 表示被动关闭。 有时服务器会在网络状态上出现异常，一半来说是以下两种情况： 服务器保持了大量TIME_WAIT状态 服务器保持了大量CLOSE_WAIT状态 服务器保持了大量TIME_WAIT状态 TIME_WAIT是主动关闭连接的一方 TIME_WAIT是主动关闭连接的一方保持的状态，对于爬虫服务器来说他本身就是“客户端”，在完成一个爬取任务之后，他就会发起主动关闭连接，从而进入TIME_WAIT的状态，然后在保持这个状态2MSL（max 所以主动方要处于 TIME_WAIT 状态，而不能是 CLOSED 。另外这么设计TIME_WAIT 会定时的回收资源，并不会占用很大资源的，除非短时间内接受大量请求或者受到攻击。 当然现代操作系统都会用快速的查找算法来管理这些TIME_WAIT，所以对于新的 TCP连接请求，判断是否hit中一个TIME_WAIT不会太费时间，但是有这么多状态要维护总是不好。
1.4K20发布于 2020-09-24 - 来自专栏蘑菇先生的技术笔记
time_wait 详解和解决方案
如上图，主动关闭方，最后发送 ACK 时，会进入 TIME_WAIT 状态，要等 2MSL 时间后，这条连接才真正消失。 为什么要进入 TIME_WAIT 状态？ 导致问题 从前面的分析来看，出现 TIME_WAIT 属于正常行为。但在实际生产环境中，大量的 TIME_WAIT 会导致系统异常。 的日志，有的话是超出最大 TIME_WAIT 的数量了，超出后系统会把多余的 TIME_WAIT 删除掉，会导致前面章节介绍的 2 种情况。 加快回收 tcp_tw_timeout = 30：表示连接在 TIME_WAIT 状态下的过期时间。 复用 TIME_WAIT 连接 tcp_tw_reuse = 1： 1 表示开启复用 TIME_WAIT 状态的连接，这个参数在 Linux tcp_twsk_unique 函数中读取的。
3.6K30发布于 2020-04-13 - 来自专栏后台公论
实践解读CLOSE_WAIT和TIME_WAIT
CLOSE_WAIT和TIME_WAIT是如何产生的？大量的CLOSE_WAIT和TIME_WAIT又有何隐患？本文将通过实践角度来带你揭开CLOSE_WAIT和TIME_WAIT的神秘面纱！ 遇事不决先祭此图： 稍微补充一点：TIME_WAIT到CLOSED，这一步是超时自动迁移。 - 云主机上原先ESTABLISHED的那条瞬间变成TIME_WAIT了。 TIME_WAIT和CLOSE_WAIT在一些异常条件下，还是会触发的。 并不是说TIME_WAIT就真的无风险，其实无论是TIME_WAIT还是CLOSE_WAIT，永远记住当你的服务出现这两种现象的时候，它们只是某个问题导致的结果，而不是问题本身。
1.7K30编辑于 2021-12-08
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号