TIME-WAIT状态是TCP的11个状态其中之一，是发生在正常关闭TCP连接的时候发生的。
可以看到，服务端直接发送了reset，此时查看服务器连接状态，没有产生time-wait ?...从上面的分析可以看到，如果使用此配置，可以有效减少客户端网络差的情况，引起的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状态图 ?
keepalive的原因 keepalive的数量很难设置的准确，偏小的话就没啥作用 偏大的话会影响worker的短连接处理，都是内网 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 分钟）
此时，客户端就进入了 TIME-WAIT 状态。注意此时客户端到 TCP 连接还没有释放，必须经过 2*MSL（最长报文段寿命）的时间后，才进入CLOSED 状态。 为什么需要四次挥手？...客户端 TIME-WAIT ，为什么要等待 2MSL 才进入 CLOSED 状态？ 答案：MSL 是报文段在网络上最大存活时间。 确保 ACK 报文能够到达服务端，从而使服务端正常关闭连接。
关于TCP连接的TIME-WAIT状态，它是为何而生，存在的意义是什么？ 让我们回忆一下，什么是TCP TIME-WAIT状态？如下图 ? 这图中的流程不是很好理解，再看一张流程更清晰的图 ?...RFC1137解释了当TIME-WAIT状态不足时将会发生什么。如果TIME-WAIT状态连接没有被快速回收，会避免什么问题呢？请看下面的例子： ?...在这种做法中，不会再有TIME-WAIT状态的SOCKET出现。...连出的TIME-WAIT状态连接，仅仅1秒后就可以被重用了。 如何确通讯安全性? TIME-WAIT的第一个作用是避免新的连接（不相关的）接收到重复的数据包。...除非TIME-WAIT状态已经过期。
观察一段时间后发现有几百个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 状态不回收的原因是什么呢？
所以从 这个问题开始着手分析；监控数据如下 然后怀疑是 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 不同目标端口下
允许将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的方案。
日常运维中用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的快速回收
连接超时’’ 的错误 ，错误状态码110 TCP : 传输控制协议，是一种可靠的面向连接的协议 从客户端来看，在我们的应用场景中，因为频繁的使用短连接，而且在同一台机上的客户端的数量比较多，造成了大量的 TIME－WAIT...状态的端口，当 TIME－WAIT 状态端口的数量铺满了整个 port_range 范围后，就会产生 99 号错误；从服务端来看，因为频繁大量的 accept 短连接，到达一定量后，服务端口的 listen...状态：是连接一端主动关闭并发送完最后一个 ACK 之后所处的状态，（即首先调用close()发起主动关闭的一方，在发送最后一个ACK之后会进入time-wait状态）。...为了避免混淆在 TIME-WAIT 状态连接上的处理的包是前一个连接迟到的包还是新连接的包，TCP 协议规定在整个 TIME－WAIT 状态下，不能再建立同样的连接。并且会检测端口的使用情况。...短连接过多，会导致TIME－WAIT溢出，端口无法使用，从而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状态，所以最好的办法：尽量不要让服务器主动关闭链接，除非一些异常情况，如客户端协议错误、客户端超时等等。
下面是出问题节点的 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 个。
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
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
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
第四次，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连接： ?
危害是超过阀值后﹐系统会把多余的time-wait socket 删除掉，并且显示警告信息，如果是NAT网络环境又存在大量访问，会产生各种连接不稳定断开的情况。...允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭； net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
