TCP中的TIME_WAIT状态

TIME_WAIT的存在有两大理由

1.可靠地实现TCP全双工连接的终止

2.允许老的可重复分节在网络中消失。

对于理由1,我们知道TCP结束需要四次挥手,若最后一次的客户端的挥手ACK丢失(假设是客户端发起断开TCP连接),服务器将重新发送它的最后那个FIN,因此客户必须维护状态信息,以允许它重新发送那个ACK(见下方例图1)。要是客户端不维护状态信息,它将响应一个RST(另一种类型的TCP分节),该分节将被服务器解释成一个错误。如果TCP打算执行所有必要的工作以彻底终止某个链接上两个方向的数据流,那么它必须正确处理连接终止序列4个分节中任何一个分节丢失的情况。这个例子也说明了为什么执行主动关闭的一端是处于TIME_WAIT状态的那一端:因为不得不重传最终ACK的就是那一端。

                 图1

对于第二个理由,我们假设在192.168.1.20的1500端口和46.19.0.201的21端口之间有一个TCP连接。我们关闭这个连接,过一段时间后在相同的IP和端口之间建立另一个连接。后一个连接称为前一个连接的化身,因为它们的IP地址和端口号都相同。TCP必须防止来自某个连接的老的重复分组在该连接已终止后再现,被误认为属于同一个连接的某个新的化身。为做到这一点,TCP将不给处于TIEM_WAIT状态的连接发起新的化身。既然TIEM_WAIT状态的持续时间是MSL的两倍,这足以让某个方向上的分组最多存活MSL秒即被丢弃,另一个方向上的应答最多存活MSL秒也被丢弃,通过实施这样的规则,我们就可以保证每次成功建立一个连接时,来自该连接先前化身的老的重复的分组都已经在网络中消逝了。

MSL(maximum segment lifetime): 最长分节生命期。

TCP无法仅仅通过查看目的端口号来分离外来的分节到不同的端点,它必须查看 套接字对 的4个元素(本地IP地址,本地TCP端口号,外地IP地址,外地TCP端口号)才能确认由哪个端点接受某个到达的分节。

原文地址:https://www.cnblogs.com/area-h-p/p/11971475.html

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

TCP中的TIME_WAIT状态的相关文章

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/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/sunnydogzhou/article/details/6572071 1 TCP关闭时的四次握手Tcp连接在关闭的的时候,执行的是一个四次握手的过程,下图是客户端发起的关闭时客户端和服务器的状态转换图 具体过程如下:1. 客户端发送FIN报文段,进入FIN_WAIT_1状态.2. 服务器端收到FIN报文段,发送ACK表示确认,进入CLOSE_WAIT状态.3. 客户端收到FIN的确认报文段,进入FIN_WAIT_2状态.4. 服务器端发送FIN

TCP协议(二)——TIME_WAIT状态

当TCP主动关闭套接字时,采用四步握手机制来彻底关闭连接.如图: 客户端主动关闭连接,发送FIN段到服务端.TCP状态由ESTABLISHED(连接状态)转为FIN_WAIT1(表示,发送的FIN需要确认). 服务端接受FIN后,服务端的TCP状态由ESTABLISHED转为CLOSE_WAIT,并且回送ACK. 客户端接受确认ACK后,TCP状态由FIN_WAIT1转化为FIN_WAIT2(表示已经确认FIN,等待来自服务端的FIN请求). 服务端发送FIN,TCP状态CLOSE_WAIT转为

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 -

TIME_WAIT状态原理

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

TCP/IP中TIME_WAIT状态详解

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

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

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

网络编程Socket之TCP之TIME_WAIT状态详解

下面我们用最简单的一对一的客户服务器模型来重现编程中遇到的一些问题: 初学socket的时候在编写socket程序的时候会遇到很多莫名其妙的问题,比如说bind函数返回的常见错误是EADDRINUSE 使用下面的程序重现这个状态: client: int main(int argc, const char * argv[]) { struct sockaddr_in serverAdd; bzero(&serverAdd, sizeof(serverAdd)); serverAdd.sin_fa