tcp四次挥手为什么要等待2MSL

  之前所说了解有两个原因:

  1、防止客户端最后一次发给服务器的确认在网络中丢失以至于客户端关闭,而服务端并未关闭,导致资源的浪费。

  2、等待最大的2msl可以让本次连接的所有的网络包在链路上消失,以防造成不必要的干扰。

  但对于第二条造成不必要的干扰之前没有做过多的解读,今天在网上查了下,顺便给大家分享下:

  如果client直接closed,然后又向server发起了一个新连接,我们不能保证这个新连接和刚关闭的连接的端口号是不同的。假设新连接和已经关闭的老端口号是一样的,如果前一次滞留的某些数据仍然在网络中,这些延迟数据会在新连接建立后到达Server,所以socket就认为那个延迟的数据是属于新连接的,数据包就会发生混淆。所以client要在TIME_WAIT状态等待2倍的MSL,这样保证本次连接的所有数据都从网络中消失。

原文地址:https://www.cnblogs.com/leonandyou/p/11296793.html

时间: 2024-10-07 17:17:01

tcp四次挥手为什么要等待2MSL的相关文章

TCP为什么是三次握手,为什么不是两次或者四次 && TCP四次挥手

这是一个很有意思的问题~ 首先,我们要知道TCP是全双工的,即客户端在给服务器端发送信息的同时,服务器端也可以给客户端发送信息.而半双工的意思是A可以给B发,B也可以给A发,但是A在给B发的时候,B不能给A发,即不同时,为半双工. 单工为只能A给B发,B不能给A发: 或者是只能B给A发,不能A给B发. 我们假设A和B是通信的双方.我理解的握手实际上就是通信,发一次信息就是进行一次握手. 第一次握手: A给B打电话说,你可以听到我说话吗? 第二次握手: B收到了A的信息,然后对A说: 我可以听得到

TCP四次挥手

tcp四次挥手详解: 挥手之前,客户端和服务器端都处于建立连接状态,客户端是主动关闭,服务器是被动关闭 (1)首先客户端发送连接释放报文FIN=1,seq=u,主动关闭连接,并不在发送数据.TCP规定FIN报文不能携带数据,但是消耗一个序号,这时A进入FIN_WAIT_1(终止等待1) (2)服务器收到连接释放报文后,发送确认,ACK=1,seq=v,ack=u+1(因为上面消耗了一个序号),这个之后服务器进入了close_wait状态,并通知高层应用程序,因此从可客户端到服务器发送的这个连接就

TCP四次挥手断开连接详解

TCP四次挥手. 数据传输结束后,通信的双方都可释放连接.现在A和B都处于ESTABLISHED状态.A的应用程序先向TCP发出连接释放报文段,主动关闭TCP连接.A把连接释放报文段的首部FIN置为1,序号seq=u,它等于前面已传送过的数据的最后一个字节的序号加1.这时A进入FIN-WAIT-1状态,等待B的确认. B收到连接释放报文段后即发出确认,确认号是ack=u+1,而这个报文段自己的序号是v,等于B前面已传送过的数据的最后一个字节的序号加1.然后B就进入CLOSE-WAIT状态.TCP

TCP四次挥手及原因

一.TCP四次挥手 MSL是TCP报文里面最大生存时间,它是任何报文段被丢弃前在网络内的最长时间. 第一次挥手:A->B,A向B发出释放连接请求的报文,其中FIN(终止位) = 1,seq(序列号)=u:在A发送完之后,A的TCP客户端进入FIN-WAIT-1(终止等待1)状态.此时A还是可以进行收数据的 第二次挥手:B->A:B在收到A的连接释放请求后,随即向A发送确认报文.其中ACK=1,seq=v,ack(确认号) = u +1;在B发送完毕后,B的服务器端进入CLOSE_WAIT(关闭

计算机网络(五),TCP四次挥手

目录 1.TCP四次挥手详情 2.为什么会有TIME-WAIT状态 3.为什么需要四次握手才能断开连接 4.服务器出现大量CLOSE_WAIT的原因 五.TCP四次挥手 1.TCP四次挥手详情 (1)一开始双方都属于已连接状态 (2)客户端发送一个报文段:FIN=1,seq=u.FIN表示连接关闭请求,seq是之前最后一个发送的数据的标号+1.客户端进入关闭等待状态1(FIN-WAIT-1) (3)服务端接收到关闭连接请求之后,通知程序需要关闭连接,然后返回一个报文段:ACK=1,seq=v,a

TCP四步挥手的各种状态转换图

对于TCP四步挥手时的各种状态转换,网上有很多资料.但是有很多描述不是很容易理解,甚至是描述错误,不如这篇文章里http://www.cnblogs.com/Jessy/p/3535612.html#3428191 说: 对此我表示不以为然.而且很容易误导初学者.在这里我贴出一个网上画的比较好的TCP四步挥手时的状态转换图:

TCP四次挥手客户端关闭链接为什么要等待2倍MSL

最长报文寿命 在TCP协议中,当发送方发送释放连接报文收到确认报文后,只是在一个方向上断开了TCP连接,然后,接收方发送释放连接的报文,发送方回复确认.此时,连接还没有释放,发送方要等待2MSL(maximum segment lifetime——最大的生命周期)后关闭连接. 问题 主动发起关闭连接的操作的一方将达到TIME_WAIT状态,而且这个状态要保持Maximum Segment Lifetime的两倍时间.为什么要这样做而不是直接进入CLOSED状态? 原因: 保证TCP协议的全双工连

TCP四次挥手时TIME_WAIT状态以及端口号的分类

TIME_WAIT(时间等待计时器)状态是什么? 简单来说,TIME_WAIT状态是四次挥手中服务器向客户端发送FIN终止连接后进入的状态. 四次挥手的过程: 可以看到TIME_WAIT状态存在于客户端收到服务器FIN并返回ACK时的状态. 当处于TIME_WAIT状态时,我们无法创建新的连接,因为端口被占用. 2. 为什么会有TIME_WAIT状态? 原因如下两点: <1> 可靠的终止TCP连接 若处于TIME_WAIT的客户端发送给服务器确认报文段丢失的话,服务器将在此重新发送FIN报文

TCP三次握手连接和TCP四次挥手及大量TIME_WAIT解决方法:

1.TCP建立连接,三次握手 建立的TCP连接可靠的连接,必须经过三次握手建立连接才能正式通信彼此传输数数据. 客户端请求服务端建立连接 第一次握手:客户给服务发送一个请求报文SYN, 客户端的状态置SYN_SENT状态 第二次握手:服务端在收到客户端发过来的SYN请求报文后,开始给客户端发送ACK报文和SYN报文,状态置为SYN_RECE 第三次握手:客户端口收到服务端口过来的SYN报文和ACK报文后,状态由原来的SYN_SENT状态变为ESTABLISHED:并且给服务发送一个ACK报文告知