`
shukuiyan
  • 浏览: 408829 次
  • 性别: Icon_minigender_1
  • 来自: 北京
社区版块
存档分类
最新评论

客户端time_wait

阅读更多

http://apps.hi.baidu.com/share/detail/21679535

 

                                 Socket中的TIME_WAIT状态
    在高并发短连接的server端,当server处理完client的请求后立刻closesocket此时会出现time_wait状态然后如果client再并发2000个连接,此时部分连接就连接不上了,用linger强制关闭可以解决此问题,但是linger会导致数据丢失,linger值为0时是强制关闭,无论并发多少多能正常连接上,如果非0会发生部分连接不上的情况!( 可调用setsockopt设置套接字的linger延时标志,同时将延时时间设置为0。
    TCP/IP的RFC文档。
    TIME_WAIT是TCP连接断开时必定会出现的状态。是无法避免掉的,这是TCP协议实现的一部分。在WINDOWS下,可以修改注册表让这个时间变短一些.time_wait的时间为2msl,默认为4min.你可以通过改变这个变量:TcpTimedWaitDelay 把它缩短到30s.
    TCP要保证在所有可能的情况下使得所有的数据都能够被投递。当你关闭一个socket时,主动关闭一端的socket将进入TIME_WAIT状态,而被动关闭一方则转入CLOSED状态,这的确能够保证所有的数据都被传输。当一个socket关闭的时候,是通过两端互发信息的四次握手过程完成的,当一端调用close()时,就说明本端没有数据再要发送了。这好似看来在握手完成以后,socket就都应该处于关闭CLOSED状态了。但这有两个问题,首先,我们没有任何机制保证最后的一个ACK能够正常传输,第二,网络上仍然有可能有残余的数据包(wandering duplicates),我们也必须能够正常处理。
通过正确的状态机,我们知道双方的关闭过程如下

                                                 图

    假设最后一个ACK丢失了,服务器会重发它发送的最后一个FIN,所以客户端必须维持一个状态信息,以便能够重发ACK;如果不维持这种状态,客户端在接收到FIN后将会响应一个RST,服务器端接收到RST后会认为这是一个错误。如果TCP协议能够正常完成必要的操作而终止双方的数据流传输,就必须完全正确的传输四次握手的四个节,不能有任何的丢失。这就是为什么socket在关闭后,仍然处于 TIME_WAIT状态,因为他要等待以便重发ACK。

    如果目前连接的通信双方都已经调用了close(),假定双方都到达CLOSED状态,而没有TIME_WAIT状态时,就会出现如下的情况。现在有一个新的连接被建立起来,使用的IP地址与端口与先前的完全相同,后建立的连接又称作是原先连接的一个化身。还假定原先的连接中有数据报残存于网络之中,这样新的连接收到的数据报中有可能是先前连接的数据报。为了防止这一点,TCP不允许从处于TIME_WAIT状态的socket建立一个连接。处于TIME_WAIT状态的socket在等待两倍的MSL时间以后(之所以是两倍的MSL,是由于MSL是一个数据报在网络中单向发出到认定丢失的时间,一个数据报有可能在发送图中或是其响应过程中成为残余数据报,确认一个数据报及其响应的丢弃的需要两倍的MSL),将会转变为CLOSED状态。这就意味着,一个成功建立的连接,必然使得先前网络中残余的数据报都丢失了。

    由于TIME_WAIT状态所带来的相关问题,我们可以通过设置SO_LINGER标志来避免socket进入TIME_WAIT状态,这可以通过发送RST而取代正常的TCP四次握手的终止方式。但这并不是一个很好的主意,TIME_WAIT对于我们来说往往是有利的。

客户端与服务器端建立TCP/IP连接后关闭SOCKET后,服务器端连接的端口状态为TIME_WAIT,是不是所有执行主动关闭的socket都会进入TIME_WAIT状态呢?有没有什么情况使主动关闭的socket直接进入CLOSED状态呢?
主动关闭的一方在发送最后一个 ack 后,就会进入 TIME_WAIT 状态 停留2MSL(max segment lifetime)时间,这个是TCP/IP必不可少的,也就是“解决”不了的。

也就是TCP/IP设计者本来是这么设计的
主要有两个原因
1。防止上一次连接中的包,迷路后重新出现,影响新连接
   (经过2MSL,上一次连接中所有的重复包都会消失)
2。可靠的关闭TCP连接
   在主动关闭方发送的最后一个 ack(fin) ,有可能丢失,这时被动方会重新发
   fin, 如果这时主动方处于 CLOSED 状态 ,就会响应 rst 而不是 ack。所以
   主动方要处于 TIME_WAIT 状态,而不能是 CLOSED 。

TIME_WAIT 并不会占用很大资源的,除非受到攻击。

还有,如果一方 send 或 recv 超时,就会直接进入 CLOSED 状态
分享到:
评论

相关推荐

    解决mysql出现大量TIME_WAIT

    解决mysql出现大量TIME_WAIT

    减少Linux服务器过多的TIME_WAIT

    减少Linux服务器过多的TIME_WAIT TIME_WAIT状态的意义: 客户端与服务器端建立TCP/IP连接后关闭SOCKET后,服务器端连接的端口 状态为TIME_WAIT 是不是所有执行主动关闭的socket都会进入TIME_WAIT状态呢? 有...

    [线上问题] “服务端长连接与客户端短连接引起Nginx产生大量\"TIME_WAIT\"状态的线程”的问题分析解决

    NULL 博文链接:https://bert82503.iteye.com/blog/2147899

    tcp短连接TIME_WAIT问题解决方法

    tcp连接是网络编程中最基础的概念,基于不同的使用场景,我们一般区分为“长连接”和“短...长短连接的优点和缺点这里就不详细展开了,有心的同学直接去google查询,本文主要关注如何解决tcp短连接的TIME_WAIT问题。

    测试解决TCP TIME-WAIT状态导致多链接失败问题.rar

    如果大量的 Time_wait ...使用 TCP Keepalive:TCP Keepalive 可以在服务器端和客户端之间建立持久连接,避免连接断开后导致的 TIME_WAIT 状态。 使用传输层网关:传输层网关可以代替服务器端和客户端之间的直接连接,

    c++《网络编程》服务器

    导致客户TCP发送一个FIN给服务器,服务器则以一个ACK响应,此时服务器处于CLOSE_WAIT状态,客户端处于FIN_WAIT_2状态。服务器接收到FIN,子进程中止。子进程中止内核关闭所有子进程打开的描述符导致服务器向客户端...

    MySQL中interactive_timeout和wait_timeout的区别

    在用mysql客户端对数据库进行操作时,打开终端窗口,如果一段时间没有操作,再次操作时,常常会报如下错误: ERROR 2013 (HY000): Lost ...其实,这个与interactive_timeout和wait_timeout的设置有关。 首先,看

    TCP三次握手和四次挥手

    2. `TIME_WAIT`:谁主动发起FIN,谁就进入该状态。起到的效果就是最后一次ACK提供重传的机会。表面看起来A发送ACK之后就没有A的事情了,按理来说A应该销毁释放资源。但是并没有直接释放而是进入`TIMT_WAIT`状态。该...

    详谈python http长连接客户端

    每一条日志都是一次请求发送给api,短连接产生大量time_wait状态,占用了大量端口 这种高并发导致的大量time_wait状态内核调优基本是没用的,后来改为长连接解决问题 第一版短连接版本关键代码如下 因涉及具体业务...

    【Linux】TCP三次握手,四次挥手的过程

    TIME_WAIT这个状态是保护谁?? 关于以上的问题,下面都会详细讲解到。 TCP三次握手的过程 TCP的面向连接特性: ** 双方通信之前需要建立连接** TCP是一种有状态的协议,必须确定双方在线且准备就绪之后才可以进

    LWIP死机问题解决办法

    LWIP做客户端或服务端集合使用会出现死循环bug,for(pcb = tcp_active_pcbs; pcb != NULL; pcb = pcb->next),即pcb 块申请和释放的时候出错了,pcb->net指向自己本身了,本人想到了一个修改最少最简便的方法来解决...

    腾讯通RTX 2010 完整版

    严重问题修改解决SDK同步大量用户数据时出错(time_wait错误)。解决选中多个文件右键菜单打开弹出RTX选择联系人窗口问题。解决插件嵌入"第三方设置",在Win7下无法启动插件问题。解决RCAServer堆栈溢出问题。解决RTX...

    TCP-IP详解卷3:TCP事务协议

    4.2 客户的端口号和TIME_WAIT状态 43 4.3 设置TIME_WAIT状态的目的 45 4.4 TIME_WAIT状态的截断 48 4.5 利用TAO跳过三次握手 51 4.6 小结 55 第5章 T/TCP协议的实现:插口层 56 5.1 概述 56 5.2 常量 56 5.3 sosend...

    TCPIP协议详解卷三.rar

    4.2 客户的端口号和TIME_WAIT状态 43 4.3 设置TIME_WAIT状态的目的 45 4.4 TIME_WAIT状态的截断 48 4.5 利用TAO跳过三次握手 51 4.6 小结 55 第5章 T/TCP协议的实现:插口层 56 5.1 概述 56 5.2 常量 56 5.3 sosend...

    TCP-IP详解卷三:TCP事务协议,HTTP,NNTP和UNIX域协议——高清文字(china-pub经典系列)

    4.2 客户的端口号和TIME_WAIT状态 43 4.3 设置TIME_WAIT状态的目的 45 4.4 TIME_WAIT状态的截断 48 4.5 利用TAO跳过三次握手 51 4.6 小结 55 第5章 T/TCP协议的实现:插口层 56 5.1 概述 56 5.2 常量 56 5.3 sosend...

    TCP-IP详解卷3:TCP事务协议,HTTP,NNTP和UNIX域协议.rar

    4.2 客户的端口号和TIME_WAIT状态 43 4.3 设置TIME_WAIT状态的目的 45 4.4 TIME_WAIT状态的截断 48 4.5 利用TAO跳过三次握手 51 4.6 小结 55 第5章 T/TCP协议的实现:插口层 56 5.1 概述 56 5.2 常量 56 5.3 sosend...

    TCPIP协议详解卷二:实现

    4.2 客户的端口号和TIME_WAIT状态 43 4.3 设置TIME_WAIT状态的目的 45 4.4 TIME_WAIT状态的截断 48 4.5 利用TAO跳过三次握手 51 4.6 小结 55 第5章 T/TCP协议的实现:插口层 56 5.1 概述 56 5.2 常量 56 5.3 sosend...

    TCP-IP详解卷三

    4.2 客户的端口号和TIME_WAIT状态 43 4.3 设置TIME_WAIT状态的目的 45 4.4 TIME_WAIT状态的截断 48 4.5 利用TAO跳过三次握手 51 4.6 小结 55 第5章 T/TCP协议的实现:插口层 56 5.1 概述 56 5.2 常量 56 5.3 sosend...

Global site tag (gtag.js) - Google Analytics