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

      开源Linux

    专注分享开源技术知识

    本文给出一个 TIME_WAIT 状态的 TCP 连接过多的问题的解决思路,非常典型,大家可以好好看看,以后遇到这个问题就不会束手无策了。

    问题描述

    模拟高并发的场景,会出现批量的 TIME_WAIT 的 TCP 连接:

    短时间后,所有的 TIME_WAIT 全都消失,被回收,端口包括服务,均正常。即,在高并发的场景下,TIME_WAIT 连接存在,属于正常现象。

    线上场景中,持续的高并发场景:

    •  一部分 TIME_WAIT 连接被回收,但新的 TIME_WAIT 连接产生;

    •  一些极端情况下,会出现大量的 TIME_WAIT 连接。

    Think:上述大量的 TIME_WAIT 状态 TCP 连接,有什么业务上的影响吗?

    Nginx 作为反向代理时,大量的短链接,可能导致 Nginx 上的 TCP 连接处于 time_wait 状态:

    • 1.每一个 time_wait 状态,都会占用一个「本地端口」,上限为 65535(16 bit,2 Byte);

    • 2.当大量的连接处于 time_wait 时,新建立 TCP 连接会出错,address already in use : connect 异常

    统计 TCP 连接的状态:

    // 统计:各种连接的数量
    
    $ netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
    
    ESTABLISHED 1154
    
    TIME_WAIT 1645

    Tips:TCP 本地端口数量,上限为 65535(6.5w),这是因为 TCP 头部使用 16 bit,存储「端口号」,因此约束上限为 65535。

    问题分析

    大量的 TIME_WAIT 状态 TCP 连接存在,其本质原因是什么?

    • 1.大量的短连接存在

    • 2.特别是 HTTP 请求中,如果 connection 头部取值被设置为 close 时,基本都由「服务端」发起主动关闭连接

    • 3.而,TCP 四次挥手关闭连接机制中,为了保证 ACK 重发和丢弃延迟数据,设置 time_wait 为 2 倍的 MSL(报文最大存活时间)

    TIME_WAIT 状态:

    • 1.TCP 连接中,主动关闭连接的一方出现的状态;(收到 FIN 命令,进入 TIME_WAIT 状态,并返回 ACK 命令)

    • 2.保持 2 个 MSL 时间,即,4 分钟;(MSL 为 2 分钟)

    解决办法

    解决上述 time_wait 状态大量存在,导致新连接创建失败的问题,一般解决办法:

    1.客户端,HTTP 请求的头部,connection 设置为 keep-alive,保持存活一段时间:现在的浏览器,一般都这么进行了

    2.服务器端

    允许 time_wait 状态的 socket 被重用

    缩减 time_wait 时间,设置为 1 MSL(即,2 mins)

    结论:几个核心要点

    1.time_wait 状态的影响:

      • TCP 连接中,「主动发起关闭连接」的一端,会进入 time_wait 状态

      • time_wait 状态,默认会持续 2 MSL(报文的最大生存时间),一般是 2x2 mins

      • time_wait 状态下,TCP 连接占用的端口,无法被再次使用

      • TCP 端口数量,上限是 6.5w(65535,16 bit)

      • 大量 time_wait 状态存在,会导致新建 TCP 连接会出错,address already in use : connect 异常

      2.现实场景:

        • 服务器端,一般设置:不允许「主动关闭连接」

        • 但 HTTP 请求中,http 头部 connection 参数,可能设置为 close,则,服务端处理完请求会主动关闭 TCP 连接

        • 现在浏览器中, HTTP 请求 connection 参数,一般都设置为 keep-alive

        • Nginx 反向代理场景中,可能出现大量短链接,服务器端,可能存在

        3.解决办法:

          • 服务器端允许 time_wait 状态的 socket 被重用

          • 缩减 time_wait 时间,设置为 1 MSL(即,2 mins)

          附录

          几个方面:

          1.TCP 连接状态的查询

          2.MSL 时间

          3.TCP 三次握手和四次握手


          附录 A:查询 TCP 连接状态

          Mac 下,查询 TCP 连接状态的具体命令:

          // Mac 下,查询 TCP 连接状态
          $ netstat -nat |grep TIME_WAIT
          
          // Mac 下,查询 TCP 连接状态,其中 -E 表示 grep 或的匹配逻辑
          $ netstat -nat | grep -E "TIME_WAIT|Local Address"
          Proto Recv-Q Send-Q Local Address Foreign Address (state)
          tcp4 0 0 127.0.0.1.1080 127.0.0.1.59061 TIME_WAIT
          
          // 统计:各种连接的数量
          $ netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
          ESTABLISHED 1154
          TIME_WAIT 1645

          附录 B:MSL 时间

          MSL,Maximum Segment Lifetime,“报文最大生存时间”

          1.任何报文在网络上存在的最长时间,超过这个时间报文将被丢弃。(IP 报文)

          2.TCP报文 (segment)是ip数据报(datagram)的数据部分。

          Tips:RFC 793中规定MSL为2分钟,实际应用中常用的是30秒,1分钟和2分钟等。

          2MSL,TCP 的 TIME_WAIT 状态,也称为2MSL等待状态:

          • 当TCP的一端发起主动关闭(收到 FIN 请求),在发出最后一个ACK 响应后,即第3次握 手完成后,发送了第四次握手的ACK包后,就进入了TIME_WAIT状态。

          • 2.必须在此状态上停留两倍的MSL时间,等待2MSL时间主要目的是怕最后一个 ACK包对方没收到,那么对方在超时后将重发第三次握手的FIN包,主动关闭端接到重发的FIN包后,可以再发一个ACK应答包。

          • 3.在 TIME_WAIT 状态时,两端的端口不能使用,要等到2MSL时间结束,才可继续使用。(IP 层)

          • 4.当连接处于2MSL等待阶段时,任何迟到的报文段都将被丢弃。

          不过在实际应用中,可以通过设置 「SO_REUSEADDR选项」,达到不必等待2MSL时间结束,即可使用被占用的端口。

          附录 C:TCP 三次握手和四次握手

          具体示意图:

          1.三次握手,建立连接过程

          2.四次挥手,释放连接过程

          几个核心疑问:

          1.time_wait 是「服务器端」的状态?or 「客户端」的状态?

          • RE:time_wait 是「主动关闭 TCP 连接」一方的状态,可能是「客服端」的,也可能是「服务器端」的

          • 一般情况下,都是「客户端」所处的状态;「服务器端」一般设置「不主动关闭连接」

          2.服务器在对外服务时,是「客户端」发起的断开连接?还是「服务器」发起的断开连接?

          • 正常情况下,都是「客户端」发起的断开连接

          • 「服务器」一般设置为「不主动关闭连接」,服务器通常执行「被动关闭」

          • 但 HTTP 请求中,http 头部 connection 参数,可能设置为 close,则,服务端处理完请求会主动关闭 TCP 连接

          关于 HTTP 请求中,设置的主动关闭 TCP 连接的机制:TIME_WAIT的是主动断开方才会出现的,所以主动断开方是服务端?

          1.答案是是的。在HTTP1.1协议中,有个 Connection 头,Connection有两个值,close和keep-alive,这个头就相当于客户端告诉服务端,服务端你执行完成请求之后,是关闭连接还是保持连接,保持连接就意味着在保持连接期间,只能由客户端主动断开连接。还有一个keep-alive的头,设置的值就代表了服务端保持连接保持多久。

          2.HTTP默认的Connection值为close,那么就意味着关闭请求的一方几乎都会是由服务端这边发起的。那么这个服务端产生TIME_WAIT过多的情况就很正常了。

          3.虽然HTTP默认Connection值为close,但是,现在的浏览器发送请求的时候一般都会设置Connection为keep-alive了。所以,也有人说,现在没有必要通过调整参数来使TIME_WAIT降低了。

          关于 time_wait:

          1.TCP 连接建立后,「主动关闭连接」的一端,收到对方的 FIN 请求后,发送 ACK 响应,会处于 time_wait 状态;

          2.time_wait 状态,存在的必要性:

          • a、可靠的实现 TCP 全双工连接的终止:四次挥手关闭 TCP 连接过程中,最后的 ACK 是由「主动关闭连接」的一端发出的,如果这个 ACK 丢失,则,对方会重发 FIN 请求,因此,在「主动关闭连接」的一段,需要维护一个 time_wait 状态,处理对方重发的 FIN 请求;

            b、处理延迟到达的报文:由于路由器可能抖动,TCP 报文会延迟到达,为了避免「延迟到达的 TCP 报文」被误认为是「新 TCP 连接」的数据,则,需要在允许新创建 TCP 连接之前,保持一个不可用的状态,等待所有延迟报文的消失,一般设置为 2 倍的 MSL(报文的最大生存时间),解决「延迟达到的 TCP 报文」问题;

          链接:NingG
           ningg.top/computer-basic-theory-tcp-time-wait/


          好文和朋友一起看~
          
          展开全文
        1. TCP会话中,首先发起关闭连接(调用 close() 系统调用)的一方在收到对端的 ACK\FIN+ACK 之后会进入到 TIME_WAIT 状态.服务器进入该该状态后,对于从相同的对端 ip 和端口的 tcp 发过来的数据包进行丢弃(Drop)处理.在 ...

          问题描述

                  TCP会话中,首先发起关闭连接(调用 close() 系统调用)的一方在收到对端的 ACK\FIN+ACK 之后会进入到 TIME_WAIT 状态.服务器进入该该状态后,对于从相同的对端 ip 和端口的 tcp 发过来的数据包进行丢弃(Drop)处理.在 linux 系统中,该状态正常会持续1分钟的时间,该事件是硬编码的,不可以调整.

          问题一:

                  此时如果有大量的并发客户端通过一个 SNAT 设备向服务器发起连接,由于客户端的 IP 经过 SNAT 设备,其源 IP 被修改为 NAT 设备的 ip 地址,由于NAT设备的端口有限, 此时就有可能导致 SYN 包被丢弃,连接建立不成功的问题.

          问题二:

                  大量的并发客户端建立连接有断开连接,在服务端留下了大量的 TIME_WAIT 状态的 TCP 会话数据,需要清理,

                

          通用方案零:增加 IP 和端口范围

                  最通用的解决方案是增加服务端对外开放的ip地址个数和端口个数!

          解决方案一:使用 SO_LINGER

                  当你调用 close()时,所有尚存在内核 buffer 中的数据将在后台继续发送,socket 将会进入到 TIME-WAIT 状态. 应用可以假设所有的数据将被安全送达.

                 这种行为被称为 socket lingering,应用可以通过设置 SO_LINGER 来改变或者关闭该机制.SO_LINGER使用如下结构:

          struct linger {
          
               int l_onoff; /* 0 = off, nozero = on */
          
               int l_linger; /* linger time */
          
          };

          有下列三种情况:

          1、设置 l_onoff为0,则该选项关闭,l_linger的值被忽略,等于内核缺省情况,close调用会立即返回给调用者,如果可能将会传输任何未发送的数据,此时会产生正常的 TIME_WAIT;

          2、设置 l_onoff为非0,l_linger 为0,则套接口关闭(close)时TCP 立即关闭连接,TCP 将丢弃套接口发送缓冲区中的任何数据并发送一个RST给对方,而不是通常的四分组终止序列,如此方式根本不会出现 TIME_WAIT 状态;

          3、设置 l_onoff 为非0,l_linger为非0,当套接口关闭时内核将等待一段时间(由l_linger决定或者全部数据发送完成且接收到确认)。如果套接口缓冲区中仍残留数据,进程将处于睡眠状态,直到所有数据发送完且被对方确认,之后进行正常的终止序列(描述字访问计数为0),若设置的延迟时间超时是还未发送完成或没接收到确认。此种情况下,应用程序检查close的返回值是非常重要的,如果在数据发送完并被确认前时间到,close将返回EWOULDBLOCK错误,且套接口发送缓冲区中的任何数据都丢失,此时同样会发送 RST 立即关闭连接, 从而本端将没有TIME_WAIT 状态。

                 注意:close的成功返回仅告诉我们发送的数据(和FIN)已由对方TCP确认,并不意味这对方应用进程是否已读了数据。如果套接口设为非阻塞的,它甚至将不等待close完.

           

          解决方案二: 发起连接方使用内核参数 tcp_tw_reuse

             TIME-WAIT 用来防止上一次会话延迟到达的数据帧被下一次会话错误地接受. 但一些特定情况下,我们可以假设新的会话不会被上一次会话所干扰.

                  RFC 1323 带来了一些 TCP 扩展用来提升其在高带宽链路上的性能. 其中包含了一个新的四字节字段 timestamp .首字节表示 TCP 发送该 segment 的当前 timestamp ,第二字节标识 最近收到的远端主机发来的 segment 的 timestamp .

                 设置 net.ipv4.tcp_timestamps = 1来启用timestamp. tcp_tw_reuse 必须配合该功能使用才能生效.

                  当启用 net.ipv4.tcp_tw_reuse 时, Linux 将会重用一个当前已经处于 TIME-WAIT 用于建立新的 对外发起的connection.条件是新的时间戳比上一个连接的最后记录的时间戳大1秒.

                 该机制如何保证安全性?  TIME-WAIT 状态的第一个目的是避免重复的报文被后续不相关的连接接受.启用了时间戳功能后, 这类的 segment 因为时间戳过期而被丢弃.

            TIME-WAIT 状态的第二个目的是 确保远端主机不会因为最后一个 ACK 帧的丢失而保持在 LAST-ACK 状态. 远端主机将会重传FIN segment 知道以下情况之一:

          1. 远端主机放弃 并主动拆除该会话连接;
          2. 远端主机收到了它苦苦等待的 ACK 帧 并主动拆除该会话连接;
          3. 远端主机收到了 RST 帧并主动拆除该会话连接.

                 如果及时收到了 FIN segment ,本端 socket 将保持在 TIME-WAIT状态并发送 ACK segment.

                 一旦一个新的连接更新了 TIME-WAIT 表项, 新连接的 SYN segment 将被忽略(根据 timestamps) ,本端会重传一个 FIN segment,而不是直接回复 RST. 该 FIN 将被一个 RST  应答(因为本端处于 SYN-SENT 状态) ,这将允许其从 LAST-ACK 状态切换出来. 1秒后,初始建立链路的 SYN 将因为没有应答而重发,新的链路可以成功建立,带来的副作用仅仅是一个轻微的延迟.如下图示意:

           

           

          ps:每当一个连接被重用, TWRecycled 计数器将被递增.

          重要:在仅负责接受连接的服务端,该参数是无效的!

           

          解决方案三: 根据情况使用 tcp_tw_recycle (不推荐)

                  如果你的服务器前端没有代理NAT设备或者具有修改源IP地址的LB设备,客户端也不位于NAT网关设备的后面,可以在服务端开启 net.ipv4.tcp_tw_recycle .将其设置为1, 该参数在 linux 内核版本 4.12 以后已经被移除.

                  该特性同样基于 timestamp 选项,与 tcp_tw_reuse 所不同的是:该特性可以作用于本服务器主动关闭的入向连接和出向连接.

             设置 net.ipv4.tcp_timestamps = 1来启用timestamp. tcp_tw_recycle 必须配合该功能使用才能生效.

             启用该特性后, TIME-WAIT 将在 RTO 时间后被移除 (retransmission timeout), 这个间隔是根据实时 RTT 时间计算出来的. 使用 ss 命令可以查看一个当前连接的 RTT 和 RTO:

          $ ss --info sport = :2112 dport = :4057 
          State Recv-Q Send-Q Local Address:Port Peer Address:Port 
          ESTAB 0 1831936 10.47.0.113:2112 10.65.1.42:4057 
          cubic wscale:7,7 rto:564 rtt:352.5/4 ato:40 cwnd:386 ssthresh:200 send 4.5Mbps rcv_space:5792

                 在大幅降低超时时间的情况下,为了保证原来 TIME-WAIT 状态提供的功能, 当一个连接进入到 TIME-WAIT 状态时, 该回话最后的时间戳将被记录在一个指定的结构中,该结构包含了当前已知目的端的 metric . 此后, Linux 会默默地丢弃进入 TIME_WAIT 状态对端发来的时间戳小于其已记录的最后的时间戳的 数据帧(Segment).直到到达超时时间.

          if (tmp_opt.saw_tstamp &&
          tcp_death_row.sysctl_tw_recycle &&
          (dst = inet_csk_route_req(sk, &fl4, req, want_cookie)) != NULL &&
          fl4.daddr == saddr &&
          (peer = rt_get_peer((struct rtable *)dst, fl4.daddr)) != NULL) {
          inet_peer_refcheck(peer);
          if ((u32)get_seconds() - peer->tcp_ts_stamp < TCP_PAWS_MSL &&
          (s32)(peer->tcp_ts - req->ts_recent) >
          TCP_PAWS_WINDOW) {
          NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_PAWSPASSIVEREJECTED);
          goto drop_and_release;
          }
          }

                 但是当远端设备实际上是一个 NAT 设备时, 位于 NAT 设备之后的主机们并没有共享同一个时钟,其连接中的时间戳会发生混乱,此时 tcp_tw_recycle 并不能正常工作,只有在 1分钟之后才能使 TIME_WAIT 状态超时.此时适用于该功能无益于问题的解决,反而使问题的发现和诊断带来干扰.所以并不建议使用该参数.

           

          解决方案四: 配置 tcp_max_tw_buckets

                  配置 net.ipv4.tcp_max_tw_buckets 数量,超过配置的数量.linux将会清理一些 TIME_WAIT状态的连接.

           

          参考:

          https://blog.csdn.net/factor2000/article/details/3929816

          https://vincent.bernat.ch/en/blog/2014-tcp-time-wait-state-linux

           

          展开全文
        2. 那么这个服务端产生TIME_WAIT过多的情况就正常了。 3.虽然HTTP默认Connection值为close,但是,现在的浏览器发送请求的时候一般都会设置Connection为keep-alive了。所以,也有人说,现在没有必要通过调整参数来使...

          点击上方 "程序员小乐"关注, 星标或置顶一起成长

          每天凌晨00点00分, 第一时间与你相约

          每日英文

          If you carry a heavy burden in your heart, try to consult someone you can trust. It will ease your pain. 

          如果你心里有过于沉重的负担,试着告诉一个你信任的人, 这样才能减轻你的痛苦。

          每日掏心

          天地万物都暂时不存在了,只剩下你的名字和你的心在一起。当我们孤零零地来到这个世界时,你只有你自己。

          来自:NingG | 责编:乐乐

          链接:ningg.top/computer-basic-theory-tcp-time-wait/

          程序员小乐(ID:study_tech) 第 886 次推文  图源:百度

          往日回顾:知乎部署系统演进,看了都说好!

               

             正文   

          写在开头,大概 4 年前,听到运维同学提到 TIME_WAIT 状态的 TCP 连接过多的问题,但是当时没有去细琢磨;最近又听人说起,是一个新手进行压测过程中,遇到的问题,因此,花点时间,细深究一下。

          0.概要

          几个方面:

          1.问题描述:什么现象?什么影响?

          2.问题分析

          3.解决方案

          4.底层原理

          1.问题描述

          模拟高并发的场景,会出现批量的 TIME_WAIT 的 TCP 连接:

          短时间后,所有的 TIME_WAIT 全都消失,被回收,端口包括服务,均正常。

          即,在高并发的场景下,TIME_WAIT 连接存在,属于正常现象。

          线上场景中,持续的高并发场景

          1. 一部分 TIME_WAIT 连接被回收,但新的 TIME_WAIT 连接产生;

          2. 一些极端情况下,会出现大量的 TIME_WAIT 连接。

          Think:

          上述大量的 TIME_WAIT 状态 TCP 连接,有什么业务上的影响吗?

          Nginx 作为反向代理时,大量的短链接,可能导致 Nginx 上的 TCP 连接处于 time_wait 状态:

          1.每一个 time_wait 状态,都会占用一个「本地端口」,上限为 65535(16 bit,2 Byte);

          2.当大量的连接处于 time_wait 时,新建立 TCP 连接会出错,address already in use : connect 异常

          统计 TCP 连接的状态:

          // 统计:各种连接的数量
          $ netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
          ESTABLISHED 1154
          TIME_WAIT 1645
          

          Tips:

          TCP 本地端口数量,上限为 65535(6.5w),这是因为 TCP 头部使用 16 bit,存储「端口号」,因此约束上限为 65535。

          2.问题分析

          大量的 TIME_WAIT 状态 TCP 连接存在,其本质原因是什么?

          1.大量的短连接存在

          2.特别是 HTTP 请求中,如果 connection 头部取值被设置为 close 时,基本都由「服务端」发起主动关闭连接

          3.而,TCP 四次挥手关闭连接机制中,为了保证 ACK 重发和丢弃延迟数据,设置 time_wait 为 2 倍的 MSL(报文最大存活时间)

          TIME_WAIT 状态:

          1.TCP 连接中,主动关闭连接的一方出现的状态;(收到 FIN 命令,进入 TIME_WAIT 状态,并返回 ACK 命令)

          2.保持 2 个 MSL 时间,即,4 分钟;(MSL 为 2 分钟)

          3.解决办法

          解决上述 time_wait 状态大量存在,导致新连接创建失败的问题,一般解决办法:

          1.客户端,HTTP 请求的头部,connection 设置为 keep-alive,保持存活一段时间:现在的浏览器,一般都这么进行了

          2.服务器端

          允许 time_wait 状态的 socket 被重用

          缩减 time_wait 时间,设置为 1 MSL(即,2 mins)

            结论:几个核心要点

            1.time_wait 状态的影响:

              1. TCP 连接中,「主动发起关闭连接」的一端,会进入 time_wait 状态

              2. time_wait 状态,默认会持续 2 MSL(报文的最大生存时间),一般是 2x2 mins

              3. time_wait 状态下,TCP 连接占用的端口,无法被再次使用

              4. TCP 端口数量,上限是 6.5w(65535,16 bit)

              5. 大量 time_wait 状态存在,会导致新建 TCP 连接会出错,address already in use : connect 异常

            2.现实场景:

              1. 服务器端,一般设置:不允许「主动关闭连接」

              2. 但 HTTP 请求中,http 头部 connection 参数,可能设置为 close,则,服务端处理完请求会主动关闭 TCP 连接

              3. 现在浏览器中, HTTP 请求 connection 参数,一般都设置为 keep-alive

              4. Nginx 反向代理场景中,可能出现大量短链接,服务器端,可能存在

            3.解决办法:

              1. 服务器端允许 time_wait 状态的 socket 被重用

              2. 缩减 time_wait 时间,设置为 1 MSL(即,2 mins)

            4.附录

            几个方面:

            1.TCP 连接状态的查询

            2.MSL 时间

            3.TCP 三次握手和四次握手

            附录 A:查询 TCP 连接状态

            Mac 下,查询 TCP 连接状态的具体命令:

            // Mac 下,查询 TCP 连接状态
            $ netstat -nat |grep TIME_WAIT
            
            
            // Mac 下,查询 TCP 连接状态,其中 -E 表示 grep 或的匹配逻辑
            $ netstat -nat | grep -E "TIME_WAIT|Local Address"
            Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)
            tcp4       0      0  127.0.0.1.1080         127.0.0.1.59061        TIME_WAIT
            
            
            // 统计:各种连接的数量
            $ netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
            ESTABLISHED 1154
            TIME_WAIT 1645
            

            附录 B:MSL 时间

            MSL,Maximum Segment Lifetime,“报文最大生存时间”

            1.任何报文在网络上存在的最长时间,超过这个时间报文将被丢弃。(IP 报文)

            2.TCP报文 (segment)是ip数据报(datagram)的数据部分。

            Tips:

            RFC 793中规定MSL为2分钟,实际应用中常用的是30秒,1分钟和2分钟等。

            2MSL,TCP 的 TIME_WAIT 状态,也称为2MSL等待状态:

            1.当TCP的一端发起主动关闭(收到 FIN 请求),在发出最后一个ACK 响应后,即第3次握 手完成后,发送了第四次握手的ACK包后,就进入了TIME_WAIT状态。

            2.必须在此状态上停留两倍的MSL时间,等待2MSL时间主要目的是怕最后一个 ACK包对方没收到,那么对方在超时后将重发第三次握手的FIN包,主动关闭端接到重发的FIN包后,可以再发一个ACK应答包。

            3.在 TIME_WAIT 状态时,两端的端口不能使用,要等到2MSL时间结束,才可继续使用。(IP 层)

            4.当连接处于2MSL等待阶段时,任何迟到的报文段都将被丢弃。

            不过在实际应用中,可以通过设置 「SO_REUSEADDR选项」,达到不必等待2MSL时间结束,即可使用被占用的端口。

            附录 C:TCP 三次握手和四次握手

            具体示意图:

            1.三次握手,建立连接过程

            2.四次挥手,释放连接过程

            几个核心疑问:

            1.time_wait 是「服务器端」的状态?or 「客户端」的状态?

              1. RE:time_wait 是「主动关闭 TCP 连接」一方的状态,可能是「客服端」的,也可能是「服务器端」的

              2. 一般情况下,都是「客户端」所处的状态;「服务器端」一般设置「不主动关闭连接」

            2.服务器在对外服务时,是「客户端」发起的断开连接?还是「服务器」发起的断开连接?

              1. 正常情况下,都是「客户端」发起的断开连接

              2. 「服务器」一般设置为「不主动关闭连接」,服务器通常执行「被动关闭」

              3. 但 HTTP 请求中,http 头部 connection 参数,可能设置为 close,则,服务端处理完请求会主动关闭 TCP 连接

            关于 HTTP 请求中,设置的主动关闭 TCP 连接的机制:TIME_WAIT的是主动断开方才会出现的,所以主动断开方是服务端?

            1.答案是是的。在HTTP1.1协议中,有个 Connection 头,Connection有两个值,close和keep-alive,这个头就相当于客户端告诉服务端,服务端你执行完成请求之后,是关闭连接还是保持连接,保持连接就意味着在保持连接期间,只能由客户端主动断开连接。还有一个keep-alive的头,设置的值就代表了服务端保持连接保持多久。

            2.HTTP默认的Connection值为close,那么就意味着关闭请求的一方几乎都会是由服务端这边发起的。那么这个服务端产生TIME_WAIT过多的情况就很正常了。

            3.虽然HTTP默认Connection值为close,但是,现在的浏览器发送请求的时候一般都会设置Connection为keep-alive了。所以,也有人说,现在没有必要通过调整参数来使TIME_WAIT降低了。

            关于 time_wait:

            1.TCP 连接建立后,「主动关闭连接」的一端,收到对方的 FIN 请求后,发送 ACK 响应,会处于 time_wait 状态;

            2.time_wait 状态,存在的必要性:

              1. 可靠的实现 TCP 全双工连接的终止:四次挥手关闭 TCP 连接过程中,最后的 ACK 是由「主动关闭连接」的一端发出的,如果这个 ACK 丢失,则,对方会重发 FIN 请求,因此,在「主动关闭连接」的一段,需要维护一个 time_wait 状态,处理对方重发的 FIN 请求;

              2. 处理延迟到达的报文:由于路由器可能抖动,TCP 报文会延迟到达,为了避免「延迟到达的 TCP 报文」被误认为是「新 TCP 连接」的数据,则,需要在允许新创建 TCP 连接之前,保持一个不可用的状态,等待所有延迟报文的消失,一般设置为 2 倍的 MSL(报文的最大生存时间),解决「延迟达到的 TCP 报文」问题;

            欢迎在留言区留下你的观点,一起讨论提高。如果今天的文章让你有新的启发,学习能力的提升上有新的认识,欢迎转发分享给更多人。

            欢迎各位读者加入订阅号程序员小乐技术群,在后台回复“加群”或者“学习”即可。

            猜你还想看

            阿里、腾讯、百度、华为、京东最新面试题汇集

            Spring Boot 打的包为什么能直接运行?

            “秒杀” 问题的数据库和 SQL 设计,看了都说好!

            SpringBoot 源码分析之 SpringBoot 可执行文件解析

            关注订阅号「程序员小乐」,收看更多精彩内容
            

            嘿,你在看吗

            展开全文
          1. 参考文章:https://www.jianshu.com/p/d782f663ac72 bug信息:https://github.com/alibaba/nacos/issues/2018 1.1.3版本: 修改为1.2.1后:

            参考文章:https://www.jianshu.com/p/d782f663ac72

            bug信息:https://github.com/alibaba/nacos/issues/2018

            1.1.3版本:

            修改为1.2.1后:

             

             

             

            展开全文
          2. TCP连接出现大量TIME_WAIT的解决办法

            万次阅读 多人点赞 2019-07-05 15:15:41
            一个TCP/IP连接断开以后,会通过TIME_WAIT的状态保留一段时间,时间过了才会释放这个端口,当端口接受的频繁请求数量过多的时候,就会产生大量的TIME_WAIT状态的连接,这些连接占着端口,会消耗大量的资源。...
          3. 目录发送ACK和RST的场景TIME_WAIT状态产生大量TIME_WAIT原因解决办法 发送ACK和RST的场景 在有以下几种情景,TCP会把ack包发出去: 收到1个包,启动200ms定时器,等到200ms的定时器到点了(第二个包没来),于是对...
          4. 最近用户的tomcat服务器上出现大量TIME_WAIT 状态的连接,导致后面的连接进不去,出现服务没有响应的情况。 首先使用命令查看当前的各种状态的数量: netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in...
          5. 在7层负载均衡上,查询网络状态发现timewait,于是开始准备优化事宜 整体的拓扑结构,前面是lvs做dr模式的4层负载均衡,后端使用(nginx、or haproxy)做7层负载均衡 【优化效果】 修改前,建立连接的...
          6. 1. TIME_WAIT产生的原因 1.1 四次挥手 假设主动关闭连接的一方为A,被动关闭连接的一方为B A调用close();协议层发送FIN包 B收到FIN包后,回复ACK,进入CLOSE_WAIT状态,A等待对方关闭,进入FIN_WAIT_2状态,此时...
          7. 解决TimeWait过多的问题

            千次阅读 2020-08-18 20:06:12
            1、 time_wait的作用: TIME_WAIT状态存在的理由: 1)可靠地实现TCP全双工连接的终止 在进行关闭连接四次挥手协议时,最后的ACK是由主动关闭端发出的,如果这个最终的ACK丢失,服务器将重发最终的FIN, 因此客户端...
          8. 1、 time_wait的作用: TIME_WAIT状态存在的理由: 1)可靠地实现TCP全双工连接的终止 在进行关闭连接四次挥手协议时,最后的ACK是由主动关闭端发出的,如果这个最终的ACK丢失,服务器将重发最终的FIN, 因此...
          9. TIME_WAIT1. 声明2. 问题描述:什么现象?...本篇博客转载自面试官问:大量的TIME WAIT状态TCP连接,对业务有什么影响?怎么处理? 2. 问题描述:什么现象?什么影响?        在四次
          10. 主动正常关闭TCP连接,都会出现TIMEWAIT。 为什么我们要关注这个高并发短连接呢?有两个方面需要注意: 1. 高并发可以让服务器在短时间范围内同时占用大量端口,而端口有个0~65535的范围,并不是很多,刨除系统...
          11. Nginx后端服务大量TIME-WAIT的解决

            千次阅读 2018-10-12 10:08:09
            在HTTP1.1协议中,有个 Connection 头,Connection有两个值,close和keep-alive,这个头就相当于客户端告诉服务端服务端你执行完成请求之后,是关闭连接还是保持连接,保持连接就意味着在保持连接期间,只能由...
          12. 大量的TIME_WAIT netstat ss -s netstat -n | awk '/^tcp/ {++state[$NF]} END {for(key in state) print key,"\t",state[key]}' RFC 793协议中给出的建议是两分钟,不过实际上不同的操作系统可能有不同的设置,...
          13. TIME_WAIT过多的解决办法

            千次阅读 2018-08-09 09:44:28
            第一个:如果客户端不维持TIME_WAIT状态,那么将响应给服务端一个RST,该分节被服务器解释成一个错误。如果TCP打算执行所有必要的工作以彻底终止某个连接上两个方向的数据流,那么必须正确的处...
          14. Linux下使用以下命令查看网络连接状态 netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}' ...netstat -n |find /i "time_wait" /c netstat -n |find /i "close_wait" /c netstat -...
          15. TIME_WAIT过多问题

            2019-02-26 10:47:38
            网络连接状态 查看网络连接状态 netstat -nat | grep -iw “8080” 或者计数 netstat -nat | grep -iw “8080” | wc -l 或者分组统计 netstat -ant | grep 8080 | awk ‘/^tcp/ {++S[$NF]} END {for(a in S) print...
          16. 网络情况不好时,如果主动方无TIME_WAIT等待,关闭前个连接后,主动方与被动方又建立起新的TCP连接,这时被动方重传或延时过来的FIN包过来后会直接影响新的TCP连接; 同样网络情况不好并且无TIME_WAIT等待,关闭连接...
          17. 但是在运行的过程中,发现服务端和数据库(分别布置在两台电脑,其中ws服务在IP地址172.16.1.12的电脑上,数据库SQL server在IP地址172.16.1.13上),在每次调用ws服务后都产生TCP连接,而且很多一直处于Time wait的...
          18. 0、引言 生产环境中,运行一段时间后,发现经常出现残留着大量的TCP链接,如下图...第一次握手:建立连接时,客户端A发送SYN包(SYN=j)到服务器B,并进入SYN_SEND状态,等待服务器B确认。 第二次握手:服务器B收到S...
          19. TIME_WAIT示例图: 1、 time_wait的作用: TIME_WAIT状态存在的理由: 1)可靠地实现TCP全双工连接的终止  在进行关闭连接四次挥手协议时,最后的ACK是由主动关闭端发出的,如果这个最终的ACK丢失,服务器将...
          20. 对于Apache、Nginx等服务器,上几行的参数可以好地减少TIME_WAIT套接字数量,但是对于Squid,效果却不大。此项参数可以控制TIME_WAIT套接字的最大数量,避免Squid服务器被大量的TIME_WAIT套接字拖死。 ...
          21. 如果服务端在一段时间内主动关闭的连接比较,则服务端会有大量的TIME-WAIT状态的连接要等2MSL时间,在Windows下默认为4分钟。 大量time-wait和close-wait出现后问题解决: 1.服务器保持了大量TIME_WAIT状态:解决...
          22. 解决Linux TIME_WAIT过多造成的问题

            万次阅读 多人点赞 2019-04-15 21:23:35
            1、 time_wait的作用: TIME_WAIT状态存在的理由: 1)可靠地实现TCP全双工连接的终止 在进行关闭连接四次挥手协议时,最后的ACK是由主动关闭端发出的,如果这个最终的ACK丢失,服务器将重发最终的FIN, 因此...
          23. 通信双方建立TCP连接后,主动关闭连接的一方就会进入TIME_WAIT状态。 客户端主动关闭连接时,会发送最后一个ack后,然后会进入TIME_WAIT状态,再停留2个MSL时间(后有MSL的解释),进入CLOSED状态。 下图是以客户端...
          24. HttpClient出现大量time_wait问题 在高并发短连接的TCP服务器上,当服务器处理完请求后...主动正常关闭TCP连接,都会出现TIMEWAIT。 为什么我们要关注这个高并发短连接呢?有两个方面需要注意: 1.高并发可以让服...
          25. redis服务器端连接产生太TIME_WAIT,使用下方的命令统计,高达20000+个状态连接, netstat -na | grep 6379 | grep TIME_WAIT | wc -l 排查 去查看应用代码中连接redis的方式,发现每次操作都会重新获取一次连接...
          26. 代码问题:短连接模式,忘记 close 连接,就不会发出 FIN 包,导致连接处于 CLOSE_WAIT状态;或者程序在close 连接之前陷入死循环或者执行时间过长; backlog太大:backlog太大这里指的accept 的连接队列设置的太大...
          27. netstat -ano发现大量mysql3306的timewait。![图片说明](https://img-ask.csdn.net/upload/201608/15/1471232742_683804.png) ![图片说明](https://img-ask.csdn.net/upload/201608/15/1471232758_385728.png) 我的...

          空空如也

          空空如也

          1 2 3 4 5 ... 20
          收藏数 30,722
          精华内容 12,288
          关键字:

          服务端很多连接timewait