TCP协议(二)——TIME_WAIT状态

  当TCP主动关闭套接字时,采用四步握手机制来彻底关闭连接。如图:

  

  1. 客户端主动关闭连接,发送FIN段到服务端。TCP状态由ESTABLISHED(连接状态)转为FIN_WAIT1(表示,发送的FIN需要确认)。
  2. 服务端接受FIN后,服务端的TCP状态由ESTABLISHED转为CLOSE_WAIT,并且回送ACK。
  3. 客户端接受确认ACK后,TCP状态由FIN_WAIT1转化为FIN_WAIT2(表示已经确认FIN,等待来自服务端的FIN请求)。
  4. 服务端发送FIN,TCP状态CLOSE_WAIT转为LAST_ACK(表示服务器在等待客户端的ACK)
  5. 结束到FIN后,客户端发送ACK并且将状态转会为TIME_WAIT
  6. 服务器接受ACK,TCP状态转为CLOSED(关闭)。过一段时间,客户端有TIME_WAIT转为CLOSED

  发送主动关闭的一方在最终转换消息时经历了一个TIME_WAIT状态,并且保持这个状态一段时间。TIME_WAIT状态存在打作用是什么?

  1. 确认对等端收到了最后的ACK。最后的ACK可能意外丢失,导致对等端认为FIN丢失,进而重传FIN。因此,这个状态可以对重传作出回应。
  2. 服务器发起主动关闭但不进入TIME_WAIT状态,而这时客户端崩溃重启,重启后立即发起重新连接。重连时使用上次端口号进行连接,两端通信时,所使用的序列号恰好与上次相同,这样当上次连接残留在路由器中的数据到达服务器(延时数据段),进行数据整合时出现混乱。 当存在TIME_WAIT状态时,服务器会拒绝客户端的连接请求,这样确保不会使用处于TIME_WAIT状态的TCP连接端口号来与客户端连接。
  3. 客户端发起主动关闭,而不处于TIME_WAIT状态。在这种情况下可能发起连接时重用以前的端口号,这样产生相同的问题。
  4. TIME_WAIT状态存在,意味着两端的连接依然存在,意味着在TIME_WAIT状态时依然保留四元组(源IP,源端口,目的IP,目的端口),两端不得使用这些端口建立连接。    

  TIME_WAIT状态主要用于:重传机制,避免相同序列号导致与上次延迟数据发生混,。

时间: 2024-10-10 21:55:36

TCP协议(二)——TIME_WAIT状态的相关文章

TCP协议11种状态集!

TCP协议的11种状态集 ### tcp协议11种状态集转换"三次握手5种状态,四次挥手6种状态"服务端:closed-listen-syn_rcvd-established-close_wait-last_ack-close客户端:closed-syn_send-established-fin_wait1-fin_wait2-time_wait-close1. tcp三次握手状态集转换:服务端:(1)closed-listen(开启相应服务),只有在listen状态服务端才可能建立请

TCP/IP中TIME_WAIT状态详解

TIME_WAIT状态原理: 通信双方建立连接后,主动关闭连接的一方就会进入TIME_WAIT状态. 客户端主动关闭连接时,会发送最后一个ACK确认,然后就会进入TIME_WAIT状态,再停留2MSL,就会进入CLOSED状态. 接下来我们看一张图,来说明这一过程: 上图是TCP"四次挥手"的过程,相信你们都会很了解,下面我们来说说为什么要存在TIME_WAIT状态 TIME_WAIT状态存在的理由如下: (1)可靠地实现TCP全双工连接的终止 TCP协议在关闭连接的四次挥手中,最终的

jmeter测试接口-打开很多TCP的连接数TIME_WAIT状态(Linux环境)导致报错的解决方法

一 发现问题: 服务器是Linux系统,用jmeter测试接口,发现打开很多的TCP连接,[[email protected] bin]# ulimit -n 65535用这个命令设置了总的连接数:进行压测的时候,连接数可能达到50000以上,很容易报错:查看各个状态的TCP个数:netstat -an | awk '/^tcp/ {++s[$NF]} END {for(a in s) print a,s[a]}',发现连接状态TIME_WAIT的状态很多,(统计80端口连接数netstat -

TCP/IP详解--TCP连接中TIME_WAIT状态过多

转载自http://blog.csdn.net/yusiguyuan/article/details/21445883 TIMEWAIT状态本身和应用层的客户端或者服务器是没有关系的.仅仅是主动关闭的一方,在使用FIN|ACK|FIN|ACK四分组正常关闭TCP连接的时候会出现这个TIMEWAIT.服务器在处理客户端请求的时候,如果你的程序设计为服务器主动关闭,那么你才有可能需要关注这个TIMEWAIT状态过多的问题.如果你的服务器设计为被动关闭,那么你首先要关注的是CLOSE_WAIT. 原则

TCP中的TIME_WAIT状态

TIME_WAIT的存在有两大理由 1.可靠地实现TCP全双工连接的终止 2.允许老的可重复分节在网络中消失. 对于理由1,我们知道TCP结束需要四次挥手,若最后一次的客户端的挥手ACK丢失(假设是客户端发起断开TCP连接),服务器将重新发送它的最后那个FIN,因此客户必须维护状态信息,以允许它重新发送那个ACK(见下方例图1).要是客户端不维护状态信息,它将响应一个RST(另一种类型的TCP分节),该分节将被服务器解释成一个错误.如果TCP打算执行所有必要的工作以彻底终止某个链接上两个方向的数

TCP/IP协议--TIME_WAIT状态存在的原因

1. 实际问题         初步查看发现,无法对外新建TCP连接时,线上服务器存在大量处于TIME_WAIT状态的TCP连接(最多的一次为单机10w+,其中引起报警的那个模块产生的TIME_WAIT约2w),导致其无法跟下游模块建立新TCP连接. TIME_WAIT涉及到TCP释放连接过程中的状态迁移,也涉及到具体的socket api对TCP状态的影响,下面开始逐步介绍这些概念. 2. TCP状态迁移        面向连接的TCP协议要求每次peer间通信前建立一条TCP连接,该连接可抽

TCP协议详解(下)

 TCP协议详解 TCP状态转移 TCP连接的任意一端在任一时刻都处于某种状态,当前状态可以通过netstat命令查看,这里我们主要讨论TCP连接葱白建立到关闭的整个过程中通信两端状态的变化.如图是TCP状态转移过程. 图中,粗虚线表示典型的服务器连接的状态转移:粗实线显示典型的客户端连接的状态转移. TCP状态转移总图 服务器转移过程,这里我们说的连接状态指定是该连接的服务器状态. 服务器通过listen系统调用进入LISTEN状态,被动等待客户端连接,因此执行的是所谓的被动打开.服务器一

TCP协议的那些事(总结篇)

传输层概述 传输层概述 TCP协议特点:面向连接.字节流.可靠传输 面向链接: 1.使用TCP协议的双方必须先建立连接,并且双方都必须分配相应的内核资源.TCP的连接是全双工的,也就是说双方可以根据一个连接进行读写操作. 字节流: 1.当发送方应用多次进行写操作的时候,TCP发送模块会先把数据放在发送缓冲区中,当TCP发送模块真正发送的时候,这些在发送缓冲区中的数据才可能被封装成一个或多个报文段发出.所有根据以上结论,应用程序执行的写操作的次数和TCP发送的报文段个数没有对应的数量关系. 2.当

TCP连接中time_wait在开发中的影响-搜人以鱼不如授之以渔

根据TCP协议定义的3次握手断开连接规定,发起socket主动关闭的一方socket将进入TIME_WAIT状态,TIME_WAIT状态将持续2个MSL(Max Segment Lifetime),TIME_WAIT状态下的socket不能被回收使用. 具体现象是对于一个处理大量短连接的服务器,如果是由服务器主动关闭客户端的连接,将导致服务器端存在大量的处于TIME_WAIT状态的socket, 甚至比处于Established状态下的socket多的多,严重影响服务器的处理能力,甚至耗尽可用的