TCP连接中的TIME_WAIT状态

转自:http://blog.csdn.net/sunnydogzhou/article/details/6572071

1 TCP关闭时的四次握手
Tcp连接在关闭的的时候,执行的是一个四次握手的过程,下图是客户端发起的关闭时客户端和服务器的状态转换图
 
具体过程如下:
1、 客户端发送FIN报文段,进入FIN_WAIT_1状态。
2、 服务器端收到FIN报文段,发送ACK表示确认,进入CLOSE_WAIT状态。
3、 客户端收到FIN的确认报文段,进入FIN_WAIT_2状态。
4、 服务器端发送FIN报文端,进入LAST_ACK状态。
5、 客户端收到FIN报文端,发送FIN的ACK,同时进入TIME_WAIT状态,启动TIME_WAIT定时器,超时时间设为2MSL。
6、 服务器端收到FIN的ACK,进入CLOSED状态。
7、 客户端在2MSL时间内没收到对端的任何响应,TIME_WAIT超时,进入CLOSED状态。
从上图中可以看出,client在发出server 端fin的ack以后,进入了time_wait的状态,知道2MSL以后,才会关闭。先来解释下2MSL,max segment lifetime,最大生成时间。MSL的值在一般的实现中取30s,有些实现采用2分钟。在TCP的状态机中的“被动关闭”,从CLOSE_WAIT到 LAST_ACK中有一个如下的规则:当T C P执行一个主动关闭,并发回最后一个A CK,该连接必须在TIME_WAIT状态停留的时间为2倍的MSL。这样可让TCP再次发送最后的ACK以防这个ACK丢失。个规则导致一个后果就是在 这个2MSL的时间内,该地址上的链接(客户端地址、端口和服务器端的地址、端口)不能被使用。比如我们在建立一个链接后关闭链接然后迅速重启链接,那么 就会出现端口不可用的情况。
2 time_wait状态的必要性

如果不考虑报文延迟、丢失,确认延迟、丢失等情况,TIME_WAIT的确没有存在的必要。当网络在不理想的情况下通常会有报文的丢失延迟发生,让我们看下面的一个特例:
客户端进入发送收到四次握手关闭的最后一个ACK后,进入TIME_WAIT同时发送ACK,如果其不停留2MSL时间,而是马上关闭连接,销毁连接上的资源,当发送如下情况时,将不能正常的完成四次握手关闭:
客户端发送的ACK在网路上丢失,这样服务器端收不到最后的ACK,重传定时器超时,将重传FIN到客户端,由于客户端关于该连接的所有资源都释放,收到重传的FIN后,它没有关于这个FIN的任何信息,所以向服务器端发送一个RST报文端,服务器端收到RST后,认为搞连接出现了异常(而非正常关闭)。
所以,在TIME_WAIT状态下等待2MSL时间端,是为了能够正确处理第一个ACK(最长生存时间为MSL)丢失的情况下,能够收到对端重传的FIN(最长生存时间为MSL),然后重传ACK。
是否只要主动关闭方在TIME_WAIT状态下停留2MSL,四次握手关闭就一定正常完成呢?
答案是否定的?可以考虑如下的情况,
 
TIME_WAIT状态下发送的ACK丢失,LAST_ACK时刻设定的重传定时器超时,发送重传的FIN,很不幸,这个FIN也丢失,主动关闭方在TIME_WAIT状态等待2MSL没收到任何报文段,进入CLOSED状态,当此时被动关闭方并没有收到最后的ACK。所以即使要主动关闭方在TIME_WAIT状态下停留2MSL,也不一定表示四次握手关闭就一定正常完成。
结论:在TIME_WAIT下等待2MSL,只是为了尽最大努力保证四次握手正常关闭。确保老的报文段在网络中消失,不会影响新建立的连接
考虑如下的情况,主动关闭方在TIME_WAIT状态下发送的ACK由于网络延迟的原因没有按时到底(但并没有超过MSL的时间),导致被动关闭方重传FIN,在FIN重传后,延迟的ACK到达,被动关闭方进入CLOSED状态,如果主动关闭方在TIME_WAIT状态下发送ACK后马上进入CLOSED状态(也就是没有等待)2MSL时间,则上述的连接已不存在:现在考虑下面的情况,假设上述的链接的四元组为(192.201.0.80:23,192.201.0.85:5555),由于连接已关闭,我们可以马上建立一个新的连接,并且这个连接的四元组也是(192.201.0.80:23,192.201.0.85:5555),那么当上一个连接的重传FIN到达主动关闭方时,被新的连接所接受,这将导致新的连接被复位,很显然,这不是我们希望看到的事情。
新的连接要建立,必须是在主动关闭方和被动关闭方都进入到CLOSED状态之后才有可能。所以,最有可能导致旧的报文段影响新的连接的情况是:
在TIME_WAIT状态之前,主动关闭方发送的报文端在网络中延迟,但是TIME_WAIT设定为2MSL时,这些报文端必然会在网络中消失(最大生存时间为MSL)。被动关闭方最有可能影响新连接的报文段就是我们上面讨论的情况,对方ACK延迟到达,在此之前重传的FIN,这个报文端发送之后,TIME_WAIT的定时器超时时间肯定大于MSL,在1MSL时间内,这个FIN要么在网络中因为生成时间到达而消失,要么到达主动关闭方被这确的处理,不会影响新建立的连接。

时间: 2024-10-20 20:55:31

TCP连接中的TIME_WAIT状态的相关文章

TCP/IP中的TIME_WAIT状态

毫无疑问,TCP中有关网络编程最不容易理解的是它的TIME_WAIT状态,TIME_WAIT状态存在于主动关闭socket连接的一方. TIME_WAIT状态存在的理由: TCP/IP协议就是这样设计的,是不可避免的.主要有两个原因: 1)可靠地实现TCP全双工连接的终止 TCP协议在关闭连接的四次握手过程中,最终的ACK是由主动关闭连接的一端(后面统称A端)发出的,如果这个ACK丢失,对方(后面统称B端)将重发出最终的FIN,因此A端必须维护状态信息(TIME_WAIT)允许它重发最终的ACK

TCP 连接中的TIME_WAIT

原文:http://blog.csdn.net/wangpengqi/article/details/17245349 这就有个细节,一次http请求,谁会先断开TCP连接?什么情况下客户端先断,什么情况下服务端先断? 百度后,找到原因,主要有http1.0和http1.1之间保持连接的差异以及http头中connection.content-length.Transfer-encoding等参数有关: 当然,在nginx中,对于http1.0与http1.1也是支持长连接的.什么是长连接呢?我

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

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

TCP连接出现大量TIME_WAIT的解决办法

一个TCP/IP连接断开以后,会通过TIME_WAIT的状态保留一段时间,时间过了才会释放这个端口,当端口接受的频繁请求数量过多的时候,就会产生大量的TIME_WAIT状态的连接,这些连接占着端口,会消耗大量的资源.面对这种情况 可以通过修改TCP/IP的内核参数,来及时的处理这些状态.netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'执行该命令如果出现了大量的 TIME_WAIT 连接数目的话,如下:FIN_

【NodeJs】Ctrl+C在Linux平台和Windows平台下的TCP连接中的不同表现

Linux平台:CentOS release 6.5 (Final) Windows平台:Windows 7 旗舰版 服务器端代码如下: var net = require('net'); var server = net.createServer(function(c){ console.log('client connected: ' + c.remoteAddress); c.setNoDelay(true); c.on('data', function(data){ console.lo

几种TCP连接中出现RST的情况

http://my.oschina.net/costaxu/blog/127394 在TCP协议中RST表示复位,用来异常的关闭连接,在TCP的设计中它是不可或缺的.发送RST包关闭连接时,不必等缓冲区的包都发出去,直接就丢弃缓存区的包发送RST包.而接收端收到RST包后,也不必发送ACK包来确认. 其实在网络编程过程中,各种RST错误其实是比较难排查和找到原因的.下面我列出几种会出现RST的情况. 1 端口未打开 服务器程序端口未打开而客户端来连接.这种情况是最为常见和好理解的一种了.去tel

几种TCP连接中出现RST的情况(转载)

TCP RST 网络 linux 目录[-] 1 端口未打开 2 请求超时 3 提前关闭 4 在一个已关闭的socket上收到数据 总结 参考文献: 应该没有人会质疑,现在是一个网络时代了.应该不少程序员在编程中需要考虑多机.局域网.广域网的各种问题.所以网络知识也是避免不了学习的.而且笔者一直觉得TCP/IP网络知识在一个程序员知识体系中必需占有一席之地的. 在TCP协议中RST表示复位,用来异常的关闭连接,在TCP的设计中它是不可或缺的.发送RST包关闭连接时,不必等缓冲区的包都发出去,直接

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打算执行所有必要的工作以彻底终止某个链接上两个方向的数