精华内容
参与话题
问答
  • TIME_WAIT

    2019-09-28 19:30:48
    如果用TIME_WAIT作为关键字到网络上搜索,会得到很多关于如何减少TIME_WAIT数量的建议,其中有些建议是有错误或者有风险的,列举如下: net.ipv4.tcp_syncookies = 1,这个参数表示开启SYN Cookies。当出现SYN...

    常见的TIMEWAIT错误参数

    如果用TIME_WAIT作为关键字到网络上搜索,会得到很多关于如何减少TIME_WAIT数量的建议,其中有些建议是有错误或者有风险的,列举如下:

    1. net.ipv4.tcp_syncookies = 1,这个参数表示开启SYN Cookies。当出现SYN等待队列溢出时,启用cookies来处理,可防范少量SYN攻击。这个和TIME_WAIT没有什么关系。
    2. net.ipv4.tcp_tw_reuse = 1,这个参数表示重用TIME_WAIT的连接,重用的条件是TCP的4元组(源地址、源端口、目标地址、目标端口)要完全一致,而且开启了net.ipv4.tcp_timestamps,且新建立连接的使用的timestamp要大于当前连接的timestamp。所以,开启了这个参数对减少TIME_WAIT的TCP连接有点用,但条件太苛刻,所以实际用处不大。
    3. net.ipv4.tcp_tw_recycle = 1,这个参数表示开启TIME_WAIT回收功能,开启了这个参数后,将大大减小TIME_WAIT进入CLOSED状态的时间。但是开启了这个功能了风险很大,可能会导致处于NAT后面的某些客户端无法建立连接。因为,开启这个功能后,它要求来自同一个IP的TCP新连接的timestamp要大于之前连接的timestamp。

    TIMEWAIT的“正确”处理方法

    简单总结一下我对于TIME_WAIT状态TCP连接的理解和处理方法: 
    1. TIME_WAIT状态的设计初衷是为了保护我们的。服务端不必担心系统中有几w个处于TIME_WAIT状态的TCP连接。可以调大net.ipv4.tcp_max_tw_buckets这个参数。 
    2. 使用短连接的客户端,需要关注TIME_WAIT状态的TCP连接,建议是采用长连接,同时调节参数net.ipv4.ip_local_port_range,增加本地可用端口的范围。 
    3. 可以开启net.ipv4.tcp_tw_reuse这个参数,但是实际用处有限。 
    4. 不要开启net.ipv4.tcp_tw_recycle这个参数,它带来的问题比用处大。 
    5. 某些Linux的发行版可以调节TIME_WAIT到CLOSED的等待时间(比如Ali的Linux内核提供了参数net.ipv4.tcp_tw_timeout 
    ),可以稍微调小一点这个参数。

    按照HTTP协议的头,我们在压测程序发出的HTTP协议头里面加上connection:keep-alive当然能解决这个问题。

    还有的方法就是系统参数调优:

    sysctl net.ipv4.tcp_tw_reuse=1
    
    sysctl net.ipv4.tcp_tw_recycle=1
    sysctl net.ipv4.tcp_timestamps=1

    tcp_tw_reuse

    这个参数作用是当新的连接进来的时候,可以复用处于TIME_WAIT的socket。默认值是0。

    tcp_tw_recycle和tcp_timestamps

    默认TIME_WAIT的超时时间是2倍的MSL,但是MSL一般会设置的非常长。如果tcp_timestamps是关闭的,开启tcp_tw_recycle是没用的。但是一般情况下tcp_timestamps是默认开启的,所以直接开启就有用了。

    转载于:https://www.cnblogs.com/liuqiang0/p/9007988.html

    展开全文
  • TIME_WAIT和CLOSE_WAIT

    2017-09-08 15:25:15
    TIME_WAIT和CLOSE_WAIT如何解决存在大量TIME_WAIT和CLOSE_WAIT的问题 减少TIME_WAIT状态 减少CLOSE_WAIT状态 TIME_WAIT和CLOSE_WAIT 在服务器的日常维护过程中,会经常用到下面的命令: netstat -n...



    Table of Contents

    1. TIME_WAIT和CLOSE_WAIT
    2. 如何解决存在大量TIME_WAIT和CLOSE_WAIT的问题
      1. 减少TIME_WAIT状态
    3. 减少CLOSE_WAIT状态

    TIME_WAIT和CLOSE_WAIT

    在服务器的日常维护过程中,会经常用到下面的命令:

    netstat -n | awk ‘/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}’

    它会显示例如下面的信息:

    TIME_WAIT 814
    CLOSE_WAIT 1
    FIN_WAIT1 1
    ESTABLISHED 634
    SYN_RECV 2
    LAST_ACK 1

    常用的三个状态是:

    • ESTABLISHED 表示正在通信
    • TIME_WAIT 表示主动关闭
    • CLOSE_WAIT 表示被动关闭。

    这几种状态什么意思呢,看看图

    tcp断开时候也可能是图中的情况,反过来所以说服务端可能处于TIME_WAIT状态,也有可能处于CLOSE_WAIT状态

    一般不到万不得已的情况也不会去查看网络状态,如果服务器出了异常,百分之八九十都是下面两种情况:

    1. 服务器保持了大量TIME_WAIT状态
    2. 服务器保持了大量CLOSE_WAIT状态

    因为Linux分配给一个用户的文件句柄是有限的,而TIME_WAIT和CLOSE_WAIT两种状态如果一直被保持,那么意味着对应数目的通道就一直被占着,而且是“占着茅坑不使劲”,一旦达到句柄数上限,新的请求就无法被处理了,接着就是大量Too Many Open Files异常,tomcat崩溃

    如何解决存在大量TIME_WAIT和CLOSE_WAIT的问题

    减少TIME_WAIT状态

    解决思路很简单,就是让服务器能够快速回收和重用那些TIME_WAIT的资源。
    /etc/sysctl.conf文件修改

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    #对于一个新建连接,内核要发送多少个 SYN 连接请求才决定放弃,不应该大于255,默认值是5,对应于180秒左右时间
    net.ipv4.tcp_syn_retries=2
    #net.ipv4.tcp_synack_retries=2
    #表示当keepalive起用的时候,TCP发送keepalive消息的频度。缺省是2小时,改为300秒
    net.ipv4.tcp_keepalive_time=1200
    net.ipv4.tcp_orphan_retries=3
    #表示如果套接字由本端要求关闭,这个参数决定了它保持在FIN-WAIT-2状态的时间
    net.ipv4.tcp_fin_timeout=30
    #表示SYN队列的长度,默认为1024,加大队列长度为8192,可以容纳更多等待连接的网络连接数。
    net.ipv4.tcp_max_syn_backlog = 4096
    #表示开启SYN Cookies。当出现SYN等待队列溢出时,启用cookies来处理,可防范少量SYN攻击,默认为0,表示关闭
    net.ipv4.tcp_syncookies = 1
    #表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接,默认为0,表示关闭
    net.ipv4.tcp_tw_reuse = 1
    #表示开启TCP连接中TIME-WAIT sockets的快速回收,默认为0,表示关闭
    net.ipv4.tcp_tw_recycle = 1
    ##减少超时前的探测次数
    net.ipv4.tcp_keepalive_probes=5
    ##优化网络设备接收队列
    net.core.netdev_max_backlog=3000

    修改完之后执行/sbin/sysctl -p让参数生效。

    要注意的几个参数:

    • net.ipv4.tcp_tw_reuse
    • net.ipv4.tcp_tw_recycle
    • net.ipv4.tcp_fin_timeout
    • net.ipv4.tcpkeepalive*

    net.ipv4.tcp_tw_reuse和net.ipv4.tcp_tw_recycle的开启都是为了回收处于TIME_WAIT状态的资源。

    net.ipv4.tcp_fin_timeout这个时间可以减少在异常情况下服务器从FIN-WAIT-2转到TIME_WAIT的时间

    net.ipv4.tcpkeepalive*一系列参数,是用来设置服务器检测连接存活的相关配置

    减少CLOSE_WAIT状态

    TIME_WAIT状态可以通过优化服务器参数得到解决,因为发生TIME_WAIT的情况是服务器自己可控的,要么就是对方连接的异常,要么就是自己没有迅速回收资源,总之不是由于自己程序错误导致的。

    但是CLOSE_WAIT就不一样了,从上面的图可以看出来,如果一直保持在CLOSE_WAIT状态,那么只有一种情况,就是在对方关闭连接之后服务器程序自己没有进一步发出ack信号。换句话说,就是在对方连接关闭之后,程序里没有检测到,或者程序压根就忘记了这个时候需要关闭连接,于是这个资源就一直被程序占着。

    个人觉得这种情况,通过服务器内核参数也没办法解决,服务器对于程序抢占的资源没有主动回收的权利,除非终止程序运行。

    所以如果将大量CLOSE_WAIT的解决办法总结为一句话那就是:查代码。因为问题出在服务器程序里头啊。

    参考:


    Table of Contents

    1. TIME_WAIT和CLOSE_WAIT
    2. 如何解决存在大量TIME_WAIT和CLOSE_WAIT的问题
      1. 减少TIME_WAIT状态
    3. 减少CLOSE_WAIT状态

    TIME_WAIT和CLOSE_WAIT

    在服务器的日常维护过程中,会经常用到下面的命令:

    netstat -n | awk ‘/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}’

    它会显示例如下面的信息:

    TIME_WAIT 814
    CLOSE_WAIT 1
    FIN_WAIT1 1
    ESTABLISHED 634
    SYN_RECV 2
    LAST_ACK 1

    常用的三个状态是:

    • ESTABLISHED 表示正在通信
    • TIME_WAIT 表示主动关闭
    • CLOSE_WAIT 表示被动关闭。

    这几种状态什么意思呢,看看图

    tcp断开时候也可能是图中的情况,反过来所以说服务端可能处于TIME_WAIT状态,也有可能处于CLOSE_WAIT状态

    一般不到万不得已的情况也不会去查看网络状态,如果服务器出了异常,百分之八九十都是下面两种情况:

    1. 服务器保持了大量TIME_WAIT状态
    2. 服务器保持了大量CLOSE_WAIT状态

    因为Linux分配给一个用户的文件句柄是有限的,而TIME_WAIT和CLOSE_WAIT两种状态如果一直被保持,那么意味着对应数目的通道就一直被占着,而且是“占着茅坑不使劲”,一旦达到句柄数上限,新的请求就无法被处理了,接着就是大量Too Many Open Files异常,tomcat崩溃

    如何解决存在大量TIME_WAIT和CLOSE_WAIT的问题

    减少TIME_WAIT状态

    解决思路很简单,就是让服务器能够快速回收和重用那些TIME_WAIT的资源。
    /etc/sysctl.conf文件修改

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    #对于一个新建连接,内核要发送多少个 SYN 连接请求才决定放弃,不应该大于255,默认值是5,对应于180秒左右时间
    net.ipv4.tcp_syn_retries=2
    #net.ipv4.tcp_synack_retries=2
    #表示当keepalive起用的时候,TCP发送keepalive消息的频度。缺省是2小时,改为300秒
    net.ipv4.tcp_keepalive_time=1200
    net.ipv4.tcp_orphan_retries=3
    #表示如果套接字由本端要求关闭,这个参数决定了它保持在FIN-WAIT-2状态的时间
    net.ipv4.tcp_fin_timeout=30
    #表示SYN队列的长度,默认为1024,加大队列长度为8192,可以容纳更多等待连接的网络连接数。
    net.ipv4.tcp_max_syn_backlog = 4096
    #表示开启SYN Cookies。当出现SYN等待队列溢出时,启用cookies来处理,可防范少量SYN攻击,默认为0,表示关闭
    net.ipv4.tcp_syncookies = 1
    #表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接,默认为0,表示关闭
    net.ipv4.tcp_tw_reuse = 1
    #表示开启TCP连接中TIME-WAIT sockets的快速回收,默认为0,表示关闭
    net.ipv4.tcp_tw_recycle = 1
    ##减少超时前的探测次数
    net.ipv4.tcp_keepalive_probes=5
    ##优化网络设备接收队列
    net.core.netdev_max_backlog=3000

    修改完之后执行/sbin/sysctl -p让参数生效。

    要注意的几个参数:

    • net.ipv4.tcp_tw_reuse
    • net.ipv4.tcp_tw_recycle
    • net.ipv4.tcp_fin_timeout
    • net.ipv4.tcpkeepalive*

    net.ipv4.tcp_tw_reuse和net.ipv4.tcp_tw_recycle的开启都是为了回收处于TIME_WAIT状态的资源。

    net.ipv4.tcp_fin_timeout这个时间可以减少在异常情况下服务器从FIN-WAIT-2转到TIME_WAIT的时间

    net.ipv4.tcpkeepalive*一系列参数,是用来设置服务器检测连接存活的相关配置

    减少CLOSE_WAIT状态

    TIME_WAIT状态可以通过优化服务器参数得到解决,因为发生TIME_WAIT的情况是服务器自己可控的,要么就是对方连接的异常,要么就是自己没有迅速回收资源,总之不是由于自己程序错误导致的。

    但是CLOSE_WAIT就不一样了,从上面的图可以看出来,如果一直保持在CLOSE_WAIT状态,那么只有一种情况,就是在对方关闭连接之后服务器程序自己没有进一步发出ack信号。换句话说,就是在对方连接关闭之后,程序里没有检测到,或者程序压根就忘记了这个时候需要关闭连接,于是这个资源就一直被程序占着。

    个人觉得这种情况,通过服务器内核参数也没办法解决,服务器对于程序抢占的资源没有主动回收的权利,除非终止程序运行。

    所以如果将大量CLOSE_WAIT的解决办法总结为一句话那就是:查代码。因为问题出在服务器程序里头啊。

    参考:

    展开全文
  • TCP连接双方中,TIME_WAIT,主动关闭方才会出现,会等待 2MSL后消亡;CLOSE_WAIT,被动关闭方才会出现,往往由于程序代码错误而导致连接不能释放,带来问题。目录1. TIME_WAIT 存在的理由2.TIME_WAIT 出现的场景及...

    TCP连接双方中,TIME_WAIT,主动关闭方才会出现,会等待 2MSL后消亡;CLOSE_WAIT,被动关闭方才会出现,往往由于程序代码错误而导致连接不能释放,带来问题。

    目录

    • 1. TIME_WAIT 存在的理由

    • 2. TIME_WAIT 出现的场景及解决方案

    • 3. CLOSE_WAIT 出现的场景及解决方案

    c6d662ca8302b17781f773e8b5b74ca0.png

    1. TIME_WAIT 存在的理由

    TIME_WAIT 仅在主动断开连接的一方出现,被动断开连接的一方最终会进入 CLOSED 状态,进入 TIME_WAIT 的客户端需要等待 2 MSL 才可以真正关闭连接。

    TCP 协议需要 TIME_WAIT 状态的原因和客户端需要等待两个 MSL 不能直接进入 CLOSED 状态的原因是一样的:

    (1)防止延迟的数据段被其他使用相同源地址、源端口、目的地址以及目的端口的 TCP 连接收到;

    (2)保证 TCP 连接的远程被正确关闭,即等待被动关闭连接的一方收到 FIN 对应的 ACK 消息;

    RFC 793 中虽然指出了 TCP 连接需要在 TIME_WAIT 中等待 2 倍的 MSL(maximum segment lifetime),但是并没有解释清楚这里的两倍是从何而来,比较合理的解释是 — 网络中可能存在来自发起方的数据段,当这些发起方的数据段被服务端处理后又会向客户端发送响应,所以一来一回需要等待 2 倍的时间

    TIME_WAIT 状态是 TCP 与不确定的网络延迟斗争的结果,而不确定性是 TCP 协议在保证可靠这条路的最大阻碍。

    2. TIME_WAIT 出现的场景及解决方案

    在高并发短连接的 TCP 服务器上,当服务器处理完请求后立刻主动正常关闭连接。这个场景下会出现大量 socket 处于 TIME_WAIT 状态。如果客户端的并发量持续很高,此时部分客户端就会显示连接不上。

    (1)高并发可以让服务器在短时间范围内同时占用大量端口,而端口有个 0~65535 的范围,并不是很多,刨除系统和其他服务要用的,剩下的就更少了。

    (2)在这个场景中,短连接表示“业务处理+传输数据的时间 远远小于 TIMEWAIT 超时的时间”的连接。

    综合这两个方面,持续的到达一定量的高并发短连接,会使服务器因端口资源不足而拒绝为一部分客户服务。同时,这些端口都是服务器临时分配,无法用 SO_REUSEADDR 选项解决这个问题。

    编辑内核文件/etc/sysctl.conf,加入以下内容:

    net.ipv4.tcp_syncookies = 1 # 表示开启 SYN Cookies。当出现 SYN 等待队列溢出时,启用 cookies 来处理,可防范少量 SYN 攻击,默认为 0,表示关闭;net.ipv4.tcp_tw_reuse = 1  # 表示开启重用。允许将 TIME-WAIT sockets 重新用于新的 TCP 连接,默认为 0,表示关闭;net.ipv4.tcp_tw_recycle = 1 # 表示开启 TCP 连接中 TIME-WAIT sockets 的快速回收,默认为 0,表示关闭。net.ipv4.tcp_fin_timeout    #修改系默认的 FIN_WAIT_2 超时时间# 关于 FIN_WAIT2 的处理# 断开的时候,主动关闭方就进入 FIN_WAIT_1 的状态,被动关闭方收到 FIN 后,发送 ACK,就进入 CLOSE_WAIT 的状态。# 主动关闭方收到被动关闭方的ACK之后,就进入 FIN_WAIT_2 的状态,如果这个时候被动关闭方直接跑路,则主动关闭方将永远在这个状态。# TCP 协议里面并没有对这个状态的处理,但是 Linux 有,可以调整 tcp_fin_timeout 这个参数,设置一个超时时间。

    然后执行 /sbin/sysctl -p 让参数生效

    简单来说,就是打开系统的 TIME_WAIT 重用和快速回收。

    如果以上配置调优后性能还不理想,可继续修改一下配置:

    # vi /etc/sysctl.confnet.ipv4.tcp_keepalive_time = 1200  #表示当 keepalive 启用的时候,TCP 发送 keepalive 消息的频度。缺省是 2 小时,改为 20 分钟。net.ipv4.ip_local_port_range = 1024 65000 #表示用于向外连接的端口范围。缺省情况下很小:32768 到 61000,改为 1024 到 65000。net.ipv4.tcp_max_syn_backlog = 8192 #表示 SYN 队列的长度,默认为 1024,加大队列长度为 8192,可以容纳更多等待连接的网络连接数。net.ipv4.tcp_max_tw_buckets = 5000 #表示系统同时保持 TIME_WAIT 套接字的最大数量,如果超过这个数字,TIME_WAIT 套接字将立刻被清除并打印警告信息。默认为 180000,改为 5000。对于 Apache、Nginx 等服务器,上几行的参数可以很好地减少 TIME_WAIT 套接字数量,但是对于 Squid,效果却不大。此项参数可以控制 TIME_WAIT 套接字的最大数量,避免 Squid 服务器被大量的 TIME_WAIT 套接字拖死。
    3. CLOSE_WAIT 出现的场景及解决方案

    CLOSE_WAIT,被动关闭,程序代码错误经常导致连接不能释放。

    (1)在发起 get 或者 post 请求时,设置 Connection 属性为 close,而非 keep-alive。如:httpGet.setHeader("Connection","close");

    (2)代码中的HTTP连接需即时关闭(在finally块中关闭资源)。如果没有关闭,可能导致出现大量的 close_wait

    (3)设置tcp_keepalive_time超时时间。当超过 net.ipv4.tcp_keepalive_time 时间,对端如果已经释放,那么本端的 TCP 也会释放。

    资料来源

    1. 20170208 大量 Http 请求 close_wait 的问题

    https://blog.csdn.net/gisredevelopment/article/details/54930040

    2. 解决 TIME_WAIT 过多造成的问题

    https://www.cnblogs.com/dadonggg/p/8778318.html

    3. 为什么 TCP 协议有 TIME_WAIT 状态

    https://draveness.me/whys-the-design-tcp-time-wait/

    62d7e3bb3088c0c711f5d6e179770d8f.png
    展开全文
  • 在服务器的日常维护过程中,排查TIME_WAIT和CLOSE_WAIT问题需要用到下面的命令: netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}' TIME_WAIT 814 CLOSE_WAIT 1 FIN_WAIT1 1 ESTABLISHED ...

    在服务器的日常维护过程中,排查TIME_WAIT和CLOSE_WAIT问题需要用到下面的命令:

    netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
    
    
    TIME_WAIT 814
    CLOSE_WAIT 1
    FIN_WAIT1 1
    ESTABLISHED 634
    SYN_RECV 2
    LAST_ACK 1

    常用的三个状态是:ESTABLISHED 表示正在通信,TIME_WAIT 表示主动关闭,CLOSE_WAIT 表示被动关闭。

    查看网络状态,如果出现以下两种问题,服务器一般都出了异常。

    • 服务器保持了大量TIME_WAIT状态
    • 服务器保持了大量CLOSE_WAIT状态

    因为linux分配给一个用户的文件句柄是有限的,而TIME_WAIT和CLOSE_WAIT两种状态如果一直被保持,那么意味着对应数目的通道就一直被占着,一旦达到句柄数上限,新的请求就无法被处理了,接着就是大量Too Many Open Files异常,最终导致tomcat崩溃。

    什么是TIME-WAIT和CLOSE-WAIT ?

    由于socket是全双工的工作模式,一个socket的关闭,是需要四次握手来完成的:

    1. 主动关闭连接的一方,调用close();协议层发送FIN包 ;
    2. 被动关闭的一方收到FIN包后,协议层回复ACK;然后被动关闭的一方,进入CLOSE_WAIT状态,主动关闭的一方等待对方关闭,则进入FIN_WAIT_2状态;此时,主动关闭的一方等待被动关闭一方的应用程序,调用close操作 ;
    3. 被动关闭的一方在完成所有数据发送后,调用close()操作;此时,协议层发送FIN包给主动关闭的一方,等待对方的ACK,被动关闭的一方进入LAST_ACK状态;
    4.  主动关闭的一方收到FIN包,协议层回复ACK;此时,主动关闭连接的一方,进入TIME_WAIT状态;而被动关闭的一方,进入CLOSED状态 ;
    5. 等待2MSL时间,主动关闭的一方,结束TIME_WAIT,进入CLOSED状态 ; 

    通过上面的一次socket关闭操作,可以得出以下几点:

    1. 主动关闭连接的一方 – 也就是主动调用socket的close操作的一方,最终会进入TIME_WAIT状态 ;
    2. 被动关闭连接的一方,有一个中间状态,即CLOSE_WAIT,因为协议层在等待上层的应用程序,主动调用close操作后才主动关闭这条连接 ;
    3. TIME_WAIT会默认等待2MSL时间后,才最终进入CLOSED状态;
    4. 在一个连接没有进入CLOSED状态之前,这个连接是不能被重用的

    TIME_WAIT并不可怕,CLOSE_WAIT才可怕,因为CLOSE_WAIT很多,表示说要么是你的应用程序写的有问题,没有合适的关闭socket。要么是服务器CPU处理不过来(CPU太忙)或者你的应用程序一直睡眠到其它地方(锁,或者文件I/O等等),你的应用程序获得不到合适的调度时间,造成你的程序没法真正的执行close操作。

    处理方法

    服务器保持了大量TIME_WAIT状态

    这种情况比较常见,一些爬虫服务器或者WEB服务器上经常会遇到这个问题。

    TIME_WAIT是主动关闭连接的一方保持的状态,对于爬虫服务器来说他本身就是“客户端”,在完成一个任务之后,他就会发起主动关闭连接,从而进入TIME_WAIT的状态,然后在保持这个状态2MSL(max segment lifetime)时间之后,彻底关闭回收资源。

    这样做的主要出于以下两个方面的考虑:

    • 防止上一次连接中的包,迷路后重新出现,影响新连接(经过2MSL,上一次连接中所有的重复包都会消失),可靠的关闭TCP连接。在主动关闭方发送的最后一个 ack(fin) ,有可能丢失,这时被动方会重新发fin, 如果这时主动方处于 CLOSED 状态 ,就会响应 rst 而不是 ack。所以主动方要处于 TIME_WAIT 状态,而不能是 CLOSED 。另外这么设计TIME_WAIT 会定时的回收资源,并不会占用很大资源的,除非短时间内接受大量请求或者受到攻击。
    • 基于TCP的HTTP协议,关闭TCP连接的是Server端,这样,Server端会进入TIME_WAIT状态,可 想而知,对于访 问量大的Web Server,会存在大量的TIME_WAIT状态,假如server一秒钟接收1000个请求,那么就会积压 240*1000=240,000个 TIME_WAIT的记录,维护这些状态给Server带来负担。当然现代操作系统都会用快速的查找算法来管理这些 TIME_WAIT,所以对于新的 TCP连接请求,判断是否hit中一个TIME_WAIT不会太费时间,但是有这么多状态要维护总是不好。  

    主动方要处于 TIME_WAIT 状态,而不能是 CLOSED 。另外这么设计TIME_WAIT 会定时的回收资源,并不会占用很大资源的,除非短时间内接受大量请求或者受到攻击。

    解决方案

    • 通过修改/etc/sysctl.conf文件,服务器能够快速回收和重用那些TIME_WAIT的资源。
    #表示开启SYN Cookies。当出现SYN等待队列溢出时,启用cookies来处理,可防范少量SYN攻击,默认为0,表示关闭    
    net.ipv4.tcp_syncookies = 1    
    #表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接,默认为0,表示关闭    
    net.ipv4.tcp_tw_reuse = 1    
    #表示开启TCP连接中TIME-WAIT sockets的快速回收,默认为0,表示关闭    
    net.ipv4.tcp_tw_recycle = 1  
    #表示如果套接字由本端要求关闭,这个参数决定了它保持在FIN-WAIT-2状态的时间    
    net.ipv4.tcp_fin_timeout=30  

    服务器保持了大量的close_wait状态

    time_wait问题可以通过调整内核参数和适当的设置web服务器的keep-Alive值来解决。因为time_wait是自己可控的,要么就是对方连接的异常,要么就是自己没有快速的回收资源,总之不是由于自己程序错误引起的。但是close_wait就不一样了,服务器保持大量的close_wait只有一种情况,那就是对方发送一个FIN后,程序自己这边没有进一步发送ACK以确认。换句话说就是在对方关闭连接后,程序里没有检测到,或者程序里本身就已经忘了这个时候需要关闭连接,于是这个资源就一直被程序占用着。

    解决方案

    • 关闭正在运行的程序,这个需要视业务情况而定。
    • 尽快的修改程序里的bug,然后提交到线上服务器。
    展开全文
  • TIME_WAIT过多是因为什么 (首先需要注意的是,客户机、服务器均可以发起对 TCP 连接的关闭,以下以服务器发起关闭为例。) TIME_WAIT 是什么:关闭 TCP 连接过程中,第 4 次挥手时,服务器发送了 ACK 报文段之后...
  • time_wait

    2015-03-10 16:40:33
    TIME_WAIT状态原理 ---------------------------- 通信双方建立TCP连接后,主动关闭连接的一方就会进入TIME_WAIT状态。 客户端主动关闭连接时,会发送最后一个ack后,然后会进入TIME_WAIT状态,再停留2个...
  • 查看网络连接数:netstat -an |wc -lnetstat -an |grep xx |wc -l查看某个/特定ip的连接数netstat -an |grep TIME_WAIT|wc -l查看连接数等待time_wait状态连接数netstat -an |grep ESTABLISHED |wc -l查看建立稳定...
  • Linux和windows下TIME_WAIT过多的解决办法 如果使用了nginx代理,那么系统TIME_WAIT的数量会变得比较多,这是由于nginx代理使用了短链接的方式和后端交互的原因,使得nginx和后端的ESTABLISHED变得很少而TIME_WAIT...
  • TIME_WAIT和CLOSE_WAIT的区别

    千次阅读 2019-04-18 14:35:25
    系统上线之后,通过如下语句查看服务器时,发现有不少TIME_WAIT和CLOSE_WAIT。 netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}' TIME_WAIT 297 ESTABLISHED 53 CLOSE_WAIT 5 解释 TIME_...
  • 先给出四次挥手过程中C/S的状态变化示意图。有了图理解起来就容易许多。...TIME_WAIT 表示主动关闭,CLOSE_WAIT 表示被动关闭。 CLOSE_WAIT状态的生成原因 首先我们知道,如果我们的服务器程序APACHE处于CLOS
  • CLOSE_WAIT TIME_WAIT

    2018-05-08 17:36:04
    TIME_WAIT状态可以通过优化服务器参数得到解决,因为发生TIME_WAIT的情况是服务器自己可控的,要么就是对方连接的异常,要么就是自己没有迅速回收资源,总之不是由于自己程序错误导致的。但是CLOSE_WAIT就不一样了,...
  • TCP四次挥手之FIN_WAIT_2和CLOSE_WAIT,TIME_WAIT以及LAST_ACK的细节
  • [size=small]使用netstat监测http连接状态的时候,可以看到几种WAIT:FIN_WAIT、TIME_WAIT和CLOSE_WAIT.它们的含义需要结合tcp的连接中断说明: Server Client --------FIN------> ...
  • 先发起 close 的 FIN_WAIT_1 并收到 对方回应的ACK 处于FIN_WAIT_2,这时对方也 close 而收到 FIN信号并进入 TIME_WAIT; 先收到FIN 信号 会进入 CLOSE_WAIT 如果不 close 则处于close_wait; 比如下图进行理解 ...
  • 系统上线之后,通过如下语句查看服务器时,发现有不少TIME_WAIT和CLOSE_WAIT。 netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}' 打印显示如下: TIME_WAIT 297 ESTABLISHED 53 CLOSE_...
  • CLOSE_WAIT和TIME_WAIT

    2019-03-24 22:46:19
    在服务器的日常维护过程中,会经常用到下面的命令: netstat -n | awk '/^tcp/ {++S[$NF]} END {for...TIME_WAIT 814 CLOSE_WAIT 1 FIN_WAIT1 1 ESTABLISHED 634 SYN_RECV 2 LAST_ACK 1 常用的三个状态是:ESTABLIS...
  • 命令查看TIME_WAIT连接数 netstat -ae|grep "TIME_WAIT" |wc -l 早上登陆服务器的时候输入netstat -an|grep mysql 发现存在大量TIME_WAIT状态的连接 tcp 0 0 127.0.0.1:3306 127.0.0.1:41378 T
  • TCP/IP之TIME_WAIT和CLOSE_WAIT TCP/IP四次挥手 要了解 TIME_WAIT 和 CLOSE_WAIT 就需要了解一下TCP/IP的四次挥手,因为这两个状态发生在四次挥手的过程 client和server端 在这里我们这么定义client 和 server 端: ...
  • TIME_WAIT、 CLOSE_WAIT

    2015-12-11 23:56:23
    TCP连接释放的过程TIME_WAIT 大量TiME_WAIT的后果解决方案 CLOSE_WAIT 大量CLOSE_WAIT的后果解决方案     TCP 连接释放的过程     图中,A是主动关闭的一方,B是被动关闭的一
  • TIME_WAIT过多危害 网络情况不好时,如果主动方无TIME_WAIT等待,关闭前个连接后,主动方与被动方又建立起新的TCP连接,这时被动方重传或延时过来的FIN包过来后会直接影响新的TCP连接; 同样网络情况不好并且无TIME...
  • 文章目录存在close_wait的原因和解决办法存在FIN_WAIT2的原因和解决办法存在TIME_WAIT的原因和解决办法处理这类问题的实用命令 存在close_wait的原因和解决办法 close_wait这个状态存在于服务端,当服务端发送FIN...
  • 网上查了一下端口状态的资料,我下面总结了一下,自己学习学习: TCP状态转移要点 TCP协议规定,对于已经建立的连接,网络双方要进行四次握手才能成功断开连接,如果缺少了其中某个步骤,将会使连接处于假死状态,...

空空如也

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

time_wait