精华内容
下载资源
问答
  • CLOSE_WAIT和TIME_WAIT
    千次阅读
    2022-03-25 14:52:51

    TIME_WAIT

    TIME_WAIT 是主动关闭链接时形成的,等待2MSL时间,约4分钟。主要是防止最后一个ACK丢失。 由于TIME_WAIT 的时间会非常长,因此server端应尽量减少主动关闭连接

    CLOSE_WAIT
    在被动关闭连接情况下,在已经接收到FIN,但是还没有发送自己的FIN的时刻,连接处于CLOSE_WAIT状态。

    CLOSE_WAIT是被动关闭连接是形成的。根据TCP状态机,服务器端收到客户端发送的FIN,则按照TCP实现发送ACK,因此进入CLOSE_WAIT状态。但如果服务器端不执行close(),就不能由CLOSE_WAIT迁移到LAST_ACK,则系统中会存在很多CLOSE_WAIT状态的连接。此时,可能是系统忙于处理读、写操作,而未将已收到FIN的连接,进行close。此时,recv/read已收到FIN的连接socket,会返回0。

    更多相关内容
  • 详细描述TCP的各个状态,初学者可以快速理解掌握tcp状态图
  • 昨天解决了一个HttpClient调用错误导致的服务器异常,具体过程如下:里头的分析过程有提到,通过查看服务器网络状态检测到服务器有大量的CLOSE_WAIT的状态。在服务器的日常维护过程中,会经常用到下面的命令:...

    昨天解决了一个HttpClient调用错误导致的服务器异常,具体过程如下:

    里头的分析过程有提到,通过查看服务器网络状态检测到服务器有大量的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 表示被动关闭。

    具体每种状态什么意思,其实无需多说,看看下面这种图就明白了,注意这里提到的服务器应该是业务请求接受处理的一方:

    0_13110767960diZ.gif

    这么多状态不用都记住,只要了解到我上面提到的最常见的三种状态的意义就可以了。一般不到万不得已的情况也不会去查看网络状态,如果服务器出了异常,百分之八九十都是下面两种情况:

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

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

    因为linux分配给一个用户的文件句柄是有限的(可以参考:http://blog.csdn.net/shootyou/article/details/6579139),而TIME_WAIT和CLOSE_WAIT两种状态如果一直被保持,那么意味着对应数目的通道就一直被占着,而且是“占着茅坑不使劲”,一旦达到句柄数上限,新的请求就无法被处理了,接着就是大量Too Many Open Files异常,tomcat崩溃。。。

    面来讨论下这两种情况的处理方法,网上有很多资料把这两种情况的处理方法混为一谈,以为优化系统内核参数就可以解决问题,其实是不恰当的,优化系统内核参

    数解决TIME_WAIT可能很容易,但是应对CLOSE_WAIT的情况还是需要从程序本身出发。现在来分别说说这两种情况的处理方法:

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

    这种情况比较常见,一些爬虫服务器或者WEB服务器(如果网管在安装的时候没有做内核参数优化的话)上经常会遇到这个问题,这个问题是怎么产生的呢?

    上面的示意图可以看得出来,TIME_WAIT是主动关闭连接的一方保持的状态,对于爬虫服务器来说他本身就是“客户端”,在完成一个爬取任务之后,他就

    会发起主动关闭连接,从而进入TIME_WAIT的状态,然后在保持这个状态2MSL(max segment

    lifetime)时间之后,彻底关闭回收资源。为什么要这么做?明明就已经主动关闭连接了为啥还要保持资源一段时间呢?这个是TCP/IP的设计者规定

    的,主要出于以下两个方面的考虑:

    1.防止上一次连接中的包,迷路后重新出现,影响新连接(经过2MSL,上一次连接中所有的重复包都会消失)

    2.

    可靠的关闭TCP连接。在主动关闭方发送的最后一个 ack(fin) ,有可能丢失,这时被动方会重新发fin, 如果这时主动方处于 CLOSED

    状态 ,就会响应 rst 而不是 ack。所以主动方要处于 TIME_WAIT 状态,而不能是 CLOSED 。另外这么设计TIME_WAIT

    会定时的回收资源,并不会占用很大资源的,除非短时间内接受大量请求或者受到攻击。

    关于MSL引用下面一段话:

    MSL 為

    一個 TCP Segment (某一塊 TCP 網路封包) 從來源送到目的之間可續存的時間 (也就是一個網路封包在網路上傳輸時能存活的時間),由

    於 RFC 793 TCP 傳輸協定是在 1981 年定義的,當時的網路速度不像現在的網際網路那樣發達,你可以想像你從瀏覽器輸入網址等到第一

    個 byte 出現要等 4 分鐘嗎?在現在的網路環境下幾乎不可能有這種事情發生,因此我們大可將 TIME_WAIT 狀態的續存時間大幅調低,好

    讓 連線埠 (Ports) 能更快空出來給其他連線使用。

    再引用网络资源的一段话:

    得一说的是,对于基于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不会太费时间,但是有这么多状态要维护总是不好。

    HTTP协议1.1版规定default行为是Keep-Alive,也就是会重用TCP连接传输多个 request/response,一个主要原因就是发现了这个问题。

    也就是说HTTP的交互跟上面画的那个图是不一样的,关闭连接的不是客户端,而是服务器,所以web服务器也是会出现大量的TIME_WAIT的情况的。

    现在来说如何来解决这个问题。

    解决思路很简单,就是让服务器能够快速回收和重用那些TIME_WAIT的资源。

    下面来看一下我们网管对/etc/sysctl.conf文件的修改:

    #对于一个新建连接,内核要发送多少个 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.tcp_keepalive_*

    这几个参数。

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

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

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

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

    休息一下,喘口气,一开始只是打算说说TIME_WAIT和CLOSE_WAIT的区别,没想到越挖越深,这也是写博客总结的好处,总可以有意外的收获。

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

    是CLOSE_WAIT就不一样了,从上面的图可以看出来,如果一直保持在CLOSE_WAIT状态,那么只有一种情况,就是在对方关闭连接之后服务器程

    序自己没有进一步发出ack信号。换句话说,就是在对方连接关闭之后,程序里没有检测到,或者程序压根就忘记了这个时候需要关闭连接,于是这个资源就一直

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

    在那边日志里头我举了个场景,来说明CLOSE_WAIT和TIME_WAIT的区别,这里重新描述一下:

    务器A是一台爬虫服务器,它使用简单的HttpClient去请求资源服务器B上面的apache获取文件资源,正常情况下,如果请求成功,那么在抓取完

    资源后,服务器A会主动发出关闭连接的请求,这个时候就是主动关闭连接,服务器A的连接状态我们可以看到是TIME_WAIT。如果一旦发生异常呢?假设

    请求的资源服务器B上并不存在,那么这个时候就会由服务器B发出关闭连接的请求,服务器A就是被动的关闭了连接,如果服务器A被动关闭连接之后程序员忘了

    让HttpClient释放连接,那就会造成CLOSE_WAIT的状态了。

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

    参考资料:

    展开全文
  • 查看TIME_WAITCLOSE_WAIT数的命令:netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'它会显示例如下面的信息:TIME_WAITCLOSE_WAIT 、FIN_WAIT1 、ESTABLISHED 、SYN_RECV 、LAST_ACK...

    fa9f1a86fdad7950ffb3ec96a102126b.png

    06b680d375ba325c161c7f055afcbb30.png

    查看TIME_WAIT和CLOSE_WAIT数的命令:

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

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

    TIME_WAIT 、CLOSE_WAIT 、FIN_WAIT1 、ESTABLISHED 、SYN_RECV 、LAST_ACK

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

    服务器出现异常最长出现的状况是:

    服务器保持了大量的TIME_WAIT状态。

    服务器保持了大量的CLOSE_WAIT状态。

    我们也都知道Linux系统中分给每个用户的文件句柄数是有限的,而TIME_WAIT和CLOSE_WAIT这两种状态如果一直被保持,那么意味着对应数目的通道(此处应理解为socket,一般一个socket会占用服务器端一个端口,服务器端的端口最大数是65535)一直被占用,一旦达到了上限,则新的请求就无法被处理,接着就是大量Too Many Open Files异常,然后tomcat、nginx、apache崩溃。。。

    下面来讨论这两种状态的处理方法,网络上也有很多资料把这两种情况混为一谈,认为优化内核参数就可以解决,其实这是不恰当的。优化内核参数在一定程度上能解决time_wait过多的问题,但是应对close_wait还得从应用程序本身出发。

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

    这种情况比较常见,一般会出现在爬虫服务器和web服务器(如果没做内核参数优化的话)上,那么这种问题是怎么产生的呢?

    从上图可以看出time_wait是主动关闭连接的一方保持的状态,对于爬虫服务器来说它自身就是客户端,在完成一个爬取任务后就会发起主动关闭连接,从而进入time_wait状态,然后保持这个状态2MSL时间之后,彻底关闭回收资源。这里为什么会保持资源2MSL时间呢?这也是TCP/IP设计者规定的。

    TCP要保证在所有可能的情况下使得所有的数据都能够被正确送达。当你关闭一个socket时,主动关闭一端的socket将进入TIME_WAIT状 态,而被动关闭一方则转入CLOSED状态,这的确能够保证所有的数据都被传输。当一个socket关闭的时候,是通过两端四次握手完成的,当一端调用 close()时,就说明本端没有数据要发送了。这好似看来在握手完成以后,socket就都可以处于初始的CLOSED状态了,其实不然。原因是这样安排状态有两个问题, 首先,我们没有任何机制保证最后的一个ACK能够正常传输,第二,网络上仍然有可能有残余的数据包(wandering duplicates),我们也必须能够正常处理。

    TIMEWAIT就是为了解决这两个问题而生的。

    假设最后的一个ACK丢失,那么被动关闭一方收不到这最后一个ACK则会重发FIN。此时主动关闭一方必须保持一个有效的(time_wait状态下维持)状态信息,以便可以重发ACK。如果主动关闭的socket不维持这种状态而是进入close状态,那么主动关闭的一方在收到被动关闭方重新发送的FIN时则响应给被动方一个RST。被动方收到这个RST后会认为此次回话出错了。所以如果TCP想要完成必要的操作而终止双方的数据流传输,就必须完全正确的传输四次握手的四步,不能有任何的丢失。这就是为什么在socket在关闭后,任然处于time_wait状态的第一个原因。因为他要等待可能出现的错误(被动关闭端没有接收到最后一个ACK),以便重发ACK。

    假设目前连接的通信双方都调用了close(),双方同时进入closed的终结状态,而没有走 time_wait状态。则会出现如下问题:假如现在有一个新的连接建立起来,使用的IP地址与之前的端口完全相同,现在建立的一个连接是之前连接的完全复用,我们还假定之前连接中有数据报残存在网络之中,这样的话现在的连接收到的数据有可能是之前连接的报文。为了防止这一点。TCP不允许新的连接复用time_wait状态下的socket。处于time_wait状态的socket在等待2MSL时间后(之所以是两倍的MSL,是由于MSL是一个数据报在网络中单向发出 到认定丢失的时间,即(Maximum Segment Lifetime)报文最长存活时间,一个数据报有可能在发送途中或是其响应过程中成为残余数据报,确认一个数据报及其响应的丢弃需要两倍的MSL),将会转为closed状态。这就意味着,一个成功建立的连接,必须使得之前网络中残余的数据报都丢失了。

    再引用网络中的一段话:

    值得一说的是,基于TCP的http协议,一般(此处为什么说一般呢,因为当你在keepalive时间内 主动关闭对服务器端的连接时,那么主动关闭端就是客户端,否则客户端就是被动关闭端。下面的爬虫例子就是这种情况)主动关闭tcp一端的是server端,这样server端就会进入time_wait状态,可想而知,对于访问量大的web服务器,会存在大量的time_wait状态,假如server一秒钟接收1000个请求,那么就会积压240*1000=240000个time_wait状态。(RFC 793中规定MSL为2分钟,实际应用中常用的是30秒,1分钟和2分钟等。),维持这些状态给服务器端带来巨大的负担。当然现代操作系统都会用快速的查找算法来管理这些 TIME_WAIT,所以对于新的 TCP连接请求,判断是否hit中一个TIME_WAIT不会太费时间,但是有这么多状态要维护总是不好。

    HTTP协议1.1版本规定default行为是keep-Alive,也就是会重用tcp连接传输多个 request/response。之所以这么做的主要原因是发现了我们上面说的这个问题。

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

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

    关闭正在运行的程序,这个需要视业务情况而定。

    尽快的修改程序里的bug,然后测试提交到线上服务器。

    注:

    直到写这篇文章的时候我才完全弄明白之前工作中遇到的一个问题。程序员写了爬虫(php)运行在采集服务器A上,程序去B服务器上采集资源,但是A服务器很快就发现出现了大量的close_wait状态的连接。后来手动检查才发现这些处于close_wait状态的请求结果都是404,那就说明B服务器上没有要请求的资源。

    下面引用网友分析的结论:

    服 务器A是一台爬虫服务器,它使用简单的HttpClient去请求资源服务器B上面的apache获取文件资源,正常情况下,如果请求成功,那么在抓取完 资源后,服务器A会主动发出关闭连接的请求,这个时候就是主动关闭连接,服务器A的连接状态我们可以看到是TIME_WAIT。如果一旦发生异常呢?假设 请求的资源服务器B上并不存在,那么这个时候就会由服务器B发出关闭连接的请求,服务器A就是被动的关闭了连接,如果服务器A被动关闭连接之后程序员忘了 让HttpClient释放连接,那就会造成CLOSE_WAIT的状态了。

    展开全文
  • Linux服务器 大量的CLOSE_WAIT、TIME_WAIT解决办法 系统上线之后,通过如下语句查看服务器时,发现有不少TIME_WAITCLOSE_WAIT。 netstat -an | awk ‘{print KaTeX parse error: Expected 'EOF', got '}' at ...

    Linux服务器 大量的CLOSE_WAIT、TIME_WAIT解决办法
    系统上线之后,通过如下语句查看服务器时,发现有不少TIME_WAIT和CLOSE_WAIT。
    netstat -an | awk ‘{print KaTeX parse error: Expected 'EOF', got '}' at position 2: 6}̲' | sort | uniq…NF]} END {for(a in S) print a, S[a]}’

    打印显示如下:
    TIME_WAIT 297
    ESTABLISHED 53
    CLOSE_WAIT 5

     TIME_WAIT:表示主动关闭,通过优化系统内核参数可容易解决。
     CLOSE_WAIT:表示被动关闭,需要从程序本身出发。
     ESTABLISHED:表示正在通信
    
    通过上网了解,总结如下:
    

    一、TIME_WAIT(通过优化系统内核参数可容易解决)
    TIME_WAIT是主动关闭连接的一方保持的状态,对于服务器来说它本身就是“客户端”,在完成一个爬取任务之后,它就会发起主动关闭连接,从而进入TIME_WAIT的状态,然后在保持这个状态2MSL(max segment lifetime)时间之后,彻底关闭回收资源。为什么要这么做?明明就已经主动关闭连接了为啥还要保持资源一段时间呢?这个是TCP/IP的设计者规定的,主要出于以下两个方面的考虑:
    1.防止上一次连接中的包,迷路后重新出现,影响新连接(经过2MSL,上一次连接中所有的重复包都会消失)
    2.可靠的关闭TCP连接。在主动关闭方发送的最后一个 ack(fin) ,有可能丢失,这时被动方会重新发fin, 如果这时主动方处于 CLOSED 状态 ,就会响应 rst 而不是 ack。所以主动方要处于 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

        生效,如下命令        
    

    /sbin/sysctl -p

    二、CLOSE_WAIT(需要从程序本身出发)
    TCP状态转移要点
    TCP协议规定,对于已经建立的连接,网络双方要进行四次握手才能成功断开连接,如果缺少了其中某个步骤,将会使连接处于假死状态,连接本身占用的资源不会被释放。网络服务器程序要同时管理大量连接,所以很有必要保证无用连接完全断开,否则大量僵死的连接会浪费许多服务器资源.
    客户端TCP状态迁移:
    CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TIME_WAIT->CLOSED

         服务器TCP状态迁移:      
    

    CLOSED->LISTEN->SYN收到->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSED
    当客户端开始连接时,服务器还处于LISTENING,客户端发一个SYN包后,他就处于SYN_SENT状态,服务器就处于SYS收到状态,然后互相确认进入连接状态ESTABLISHED。

       TIME_WAIT状态可以通过优化服务器参数得到解决,因为发生TIME_WAIT的情况是服务器自己可控的,要么就是对方连接的异常,要么就是自己没有迅速回收资源,总之不是由于自己程序错误导致的。
        但是CLOSE_WAIT就不一样了,如果一直保持在CLOSE_WAIT状态,那么只有一种情况,就是在对方关闭连接之后服务器程序自己没有进一步发出ack信号。换句话说,就是在对方连接关闭之后,程序里没有检测到,或者程序压根就忘记了这个时候需要关闭连接,于是这个资源就一直被程序占着。个人觉得这种情况,通过服务器内核参数也没办法解决,服务器对于程序抢占的资源没有主动回收的权利,除非终止程序运行。
       什么情况下,连接处于CLOSE_WAIT状态呢?
       答案一:在被动关闭连接情况下,在已经接收到FIN,但是还没有发送自己的FIN的时刻,连接处于CLOSE_WAIT状态。通常来讲,CLOSE_WAIT状态的持续时间应该很短,正如SYN_RCVD状态。但是在一些特殊情况下,就会出现连接长时间处于CLOSE_WAIT状态的情况。
        答案二:出现大量close_wait的现象,主要原因是某种情况下对方关闭了socket链接,但是我方忙与读或者写,没有关闭连接。代码需要判断socket,一旦读到0,断开连接,read返回负,检查一下errno,如果不是AGAIN,就断开连接。
    

    http://www.cnblogs.com/sunxucool/p/3449068.html
    http://my.oschina.net/foxidea/blog/91431?fromerr=KjV5Lqr3
    发现存在大量TIME_WAIT状态的连接
    tcp 0 0 127.0.0.1:3306 127.0.0.1:41378 TIME_WAIT
    tcp 0 0 127.0.0.1:3306 127.0.0.1:41379 TIME_WAIT
    tcp 0 0 127.0.0.1:3306 127.0.0.1:39352 TIME_WAIT
    tcp 0 0 127.0.0.1:3306 127.0.0.1:39350 TIME_WAIT
    tcp 0 0 127.0.0.1:3306 127.0.0.1:35763 TIME_WAIT
    tcp 0 0 127.0.0.1:3306 127.0.0.1:39372 TIME_WAIT
    tcp 0 0 127.0.0.1:3306 127.0.0.1:39373 TIME_WAIT
    tcp 0 0 127.0.0.1:3306 127.0.0.1:41176 TIME_WAIT

    通过调整内核参数解决
    vi /etc/sysctl.conf

    编辑文件,加入以下内容:
    net.ipv4.tcp_syncookies = 1
    net.ipv4.tcp_tw_reuse = 1
    net.ipv4.tcp_tw_recycle = 1
    net.ipv4.tcp_fin_timeout = 30

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

    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修改系統默认的TIMEOUT时间

    修改之后,再用命令查看TIME_WAIT连接数
    netstat -ae|grep “TIME_WAIT” |wc –l

    发现大量的TIME_WAIT 已不存在,mysql进程的占用率很快就降下来的,网站访问正常。
    不过很多时候,出现大量的TIME_WAIT状态的连接,往往是因为网站程序代码中没有使用mysql.colse(),才导致大量的mysql TIME_WAIT.

    如果你的服务器是Windows平台,可以修改下面的注册表键值:
    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
    “TcpTimedWaitDelay”=dword:0000001e

    此值是TIME_WAIT状态的最长时间。缺省为240秒,最低为30秒,最高为300秒。建议为30秒。

    注释:

    1,TCP结束的过程如下:

    Server Client

    -------------- FIN --------------> server: fin_wait_1

    <------------- ACK --------------- client: close_wait server:fin_wait_2

    <------------- FIN --------------- client发出fin之后就关闭

    -------------- ACK -------------> server发出ack后进入time_wait状态

    Time_Wait的默认时间是2倍的MLS,就是240秒钟。MLS是TCP片在网上的最长存活时间。
    TIME_Wait的主要作用是保证关闭的TCP端口不立即被使用。因为当网络存在延迟时,可能当某个端口被关闭后,网络中还有一些重传的TCP片在发向这个端口,如果这个端口立即建立新的TCP连接,则可能会有影响。所以使用2倍的MSL时间来限制这个端口立即被使用。

    现在的问题在于,4分钟的时间有点长。
    因此,Time_wait的影响,我想,首先每个TCP连接都各自有个数据结构,叫TCP Control Block.Time_wait的时候这个数据结构没有被释放。所以当有太多的TCP连接时,内存可能会被占用很多。

    2,To ValorZ:TIME_WAIT状态也称为2MSL等待状态,而不是2MLS,笔误吧!

    每个TCP报文在网络内的最长时间,就称为MSL(Maximum Segment Lifetime),它的作用和IP数据包的TTL类似。

    RFC793指出,MSL的值是2分钟,但是在实际的实现中,常用的值有以下三种:30秒,1分钟,2分钟。

    注意一个问题,进入TIME_WAIT状态的一般情况下是客户端,大多数服务器端一般执行被动关闭,不会进入TIME_WAIT状态,当在服务器端关闭某个服务再重新启动时,它是会进入TIME_WAIT状态的。

    举例:
    1.客户端连接服务器的80服务,这时客户端会启用一个本地的端口访问服务器的80,访问完成后关闭此连接,立刻再次访问服务器的80,这时客户端会启用另一个本地的端口,而不是刚才使用的那个本地端口。原因就是刚才的那个连接还处于TIME_WAIT状态。
    2.客户端连接服务器的80服务,这时服务器关闭80端口,立即再次重启80端口的服务,这时可能不会成功启动,原因也是服务器的连接还处于TIME_WAIT状态。

    windows

    TcpTimedWaitDelay和MaxUserPort设置
    描述:确定 TCP/IP 可释放已关闭连接并重用其资源前,必须经过的时间。
    关闭和释放之间的此时间间隔通称 TIME_WAIT 状态或两倍最大段生命周期(2MSL)状态。
    此时间期间,重新打开到客户机和服务器的连接的成本少于建立新连接。
    减少此条目的值允许 TCP/IP 更快地释放已关闭的连接,为新连接提供更多资源。如果运行的应用程序需要快速释放和创建新连接,而且由于 TIME_WAIT 中存在很多连接,导致低吞吐量,则调整此参数。
    如何查看或设置: 使用 regedit 命令访问 HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/ Services/TCPIP/Parameters 注册表子键并创建名为 TcpTimedWaitDelay 的新 REG_DWORD 值。
    将此值设置为十进制 30,其为十六进制 0x0000001e。
    该值将等待时间设置为 30 秒。
    停止并重新启动系统。 缺省值:0xF0,它将等待时间设置为 240 秒(4 分钟)。
    建议值:最小值为 0x1E,它将等待时间设置为 30 秒。
    MaxUserPort 描述:确定在应用程序从系统请求可用用户端口时,TCP/IP 可指定的最高端口号。
    如何查看或设置: 使用 regedit 命令访问 HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/ Services/TCPIP/Parameters 注册表子键并创建名为 MaxUserPort 的新 REG_DWORD 值。
    停止并重新启动系统。
    缺省值:无 建议值:至少十进制 32768。
    注:当在 Windows NT 或 Windows 2000 操作系统上调整 WebSphere Application Server 时,同时使用这两个参数。
    希望本站的知识能给您的工作、学习和生活带来方便和乐趣!

    server端tcp连接状态大量TIME_WAIT解决方法:
    在脚步中添加:
    /*保证迭代结束后关闭所有的链接。相应的函数放于下面两个函数之间,迭代后都会关闭连接。
    web_set_sockets_option(“SHUTDOWN_MODE”,“ABRUPT”);//相当于迭代重置,初始化

    web_set_sockets_option(“CLOSE_KEEPALIVE_CONNECTIONS”,“1”); //关闭连接
    */
    web_set_sockets_option(“SHUTDOWN_MODE”,“ABRUPT”);
    web_set_sockets_option(“SO_REUSE_ADDRESS”,“1”);//端口复用
    web_set_sockets_option(“OVERLAPPED_SEND”,“0”);//禁用TTFB细分,问题即可解决,但是TTFB细分图将不能再使用.

    展开全文
  • 对于服务器挂起中的CLOSE_WAIT & FIN_WAIT2 解决方案。
  • 然后被动关闭的一方,进入CLOSE_WAIT状态,主动关闭的一方等待对方关闭,则进入FIN_WAIT_2状态;此时,主动关闭的一方 等待 被动关闭一方的应用程序,调用close操作。 被动关闭的一方在完成所有数据发送后,调用...
  • CLOSE_WAIT连接过多的现象分析与处理未分类1. CLOSE_WAIT的机制和原理一.来自参考资料:从问题看本质: 研究TCP close_wait的内幕客户端主动发起 socket.close时假设我们有一个client, 一个server.当client主动发起一...
  • 因此,您将使那些CLOSE_WAIT连接处于挂起状态并声称已关闭。 要说明此行为,请查看此存储库中的示例。 简而言之,我们正在做的是: 在整个生命周期中创建一个连接管理器和一个HttpClient连接 创建15个线程以执行...
  • close_wait产生原因: close_wait产生太多原因: close_wait太多解决方法: Socket连接到底是个什么概念? 什么时候用长连接,短连接? 报文发送接收方式(同步和异步)? 由于socket是全双工的工作模式,一个...
  • tcp_fin_timeout:主动关闭方TCP保持在FIN_WAIT_2状态的时间。对方可能会一直不结束连接或不可预料的进程死亡。默认值为60秒。 修改方法: sysctl -w ...
  • 今天登陆服务器想查看一个端口的占用情况,...time_wait的作用 1 2 3 4 5 6 7 8 9 10 TIME_WAIT状态存在的理由: 1)可靠地实现TCP全双工连接的终止 ...
  • TCP四次挥手,CLOSE_WAIT和TIME_WAIT

    千次阅读 2020-03-05 09:43:38
    TCP四次挥手 由于TCP连接是全双工的,因此每个方向都必须单独进行关闭。假设终止命令由client端发起。 当客户端数据传输完成,准备...1.1. 通过调用close(socket) API。 1.3 表示Client不再会发送数据到Server...
  • 解决Linux服务器中TCP的FIN_WAIT2,CLOSE_WAIT状态连接过多的问题
  • TCP的CLOSE_WAIT和TIME_WAIT问题汇总

    千次阅读 2020-05-20 16:01:55
    导致了SLB这端的链接批量的超时,同时又由于close_wait状态不会自动消失,导致最终无法再这个端口上创建新的链接引起了停止服务 为啥明明有多个服务器承载,却几乎同时出了close_wait? 又为什么同时不能再服务?那...
  • 一、服务器有大量TIME_WAIT状态 1.1 原因 一些爬虫服务器或者WEB服务器(如果在安装的时候没有做内核参数优化的话)上经常会遇到这个问题。 对于基于TCP的HTTP协议,关闭TCP连接的是Server端,这样,Server端会...
  • nginx到tomcat有大量CLOSE_WAIT状态连接 原因总结: 资源未及时释放 数据库连接未及时释放,数据库连接池满后新的请求阻塞:https://blog.csdn.net/yu616568/article/details/44677985 httpclient创建的...
  • 1、tcp连接是三次握手,而为什么关闭连接需要四次握手? 2、当发现发起关闭的一方,有大量FIN_WAIT2状态的时候(即被关闭的一方有大量的CLOSE_WAIT),这时候的问题排查方向。
  • 特别是 HTTP 请求中,如果 connection 头部取值被设置为 close 时,基本都由服务端发起主动关闭连接 TCP 四次挥手关闭连接机制中,为了保证 ACK 重发和丢弃延迟数据,设置 time_wait 为 2 倍的 MSL(报文最大存活时间...
  • Linux服务器下查看网络连接的状态 netstat-n|awk'/^tcp/{++S[$NF]}END{for(ainS)printa,S[a]}' 它会显示例如下面的信息...常用的三个状态是:ESTABLISHED 表示正在通信,TIME_WAIT 表示主动关闭,CLOSE_WAIT ...
  • 线上大量CLOSE_WAIT的原因深入分析

    千次阅读 2021-02-15 11:30:53
    这一次重启真的无法解决问题了:一次 MySQL 主动关闭,导致服务出现大量 CLOSE_WAIT 的全流程排查过程。 近日遇到一个线上服务 socket 资源被不断打满的情况。通过各种工具分析线上问题,定位到问题代码。这里对该...
  • 此时,主机A进入FIN_WAIT_1状态;这表示主机A没有数据要发送给主机B了。 第二次挥手:主机B收到了主机A发送的FIN报文段,向主机A回一个ACK报文段,Acknowledgment Number为Sequence Number加1,主机A进入FIN_WAIT_2...
  • TCP的TIME_WAITCLOSE_WAIT

    2020-03-27 16:20:23
    TCP的time_waitclose_wait
  • 在服务器的日常维护过程中,会经常用到下面的命令:netstat -n | awk ‘/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}’其中$NF表示最后一个字段它会显示例如下面的信息:TIME_WAIT 814CLOSE_WAIT 1FIN_WAIT1 ...
  • 文章目录存在close_wait的原因和解决办法存在FIN_WAIT2的原因和解决办法存在TIME_WAIT的原因和解决办法处理这类问题的实用命令 存在close_wait的原因和解决办法 close_wait这个状态存在于服务端,当服务端发送FIN...
  • 大量的TIME_WAIT netstat ss -s netstat -n | awk '/^tcp/ {++state[$NF]} END {for(key in state) print key,"\t",state[key]}' RFC 793协议中给出的建议是两分钟,不过实际上不同的操作系统可能有不同的设置,...
  • WAIT tcp 1 0 127.0.0.1:15153 127.0.0.1:6379 CLOSE_WAIT tcp 1 0 127.0.0.1:14972 127.0.0.1:6379 CLOSE_WAIT tcp 1 0 127.0.0.1:15134 127.0.0.1:6379 CLOSE_WAIT tcp 1 0 127.0.0.1:15030 127.0.0.1:6379 CLOSE_...
  • 想一下TCP的四次挥手,客户端主动关闭连接发送一个FIN请求,服务器收到了这个FIN请求要回一个ACK,如果服务器没发送ACK,服务器(被动关闭的一方)这端将进入CLOSE_WAIT状态,而客户端进入(FIN_WAIT_2)这个状态。...
  • 然后被动关闭的一方,进入CLOSE_WAIT状态,主动关闭的一方等待对方关闭,则进入FIN_WAIT_2状态;此时,主动关闭的一方 等待 被动关闭一方的应用程序,调用close操作。 被动关闭的一方在完成所有数据发送后,调用...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 222,243
精华内容 88,897
关键字:

close_wait

友情链接: ping.zip