tcp断开连接的四次挥手过程(TCP断开连接的过程(四次挥手))

      最后更新:2023-08-17 04:03

      TCP四次挥手过程是什么?

      tcp四次挥手,由于TCP连接是全双工的,因此每个方向都必须单独进行关闭。影响及意义:由于TCP连接是全双工的,因此每个方向都必须单独进行关闭。这个原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动,一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭,而另一方执行被动关闭。(1)客户端A发送一个FIN,用来关闭客户A到服务器B的数据传送(报文段4)。(2)服务器B收到这个FIN,它发回一个ACK,确认序号为收到的序号加1(报文段5)。和SYN一样,一个FIN将占用一个序号。(3)服务器B关闭与客户端A的连接,发送一个FIN给客户端A(报文段6)。(4)客户端A发回ACK报文确认,并将确认序号设置为收到序号加1(报文段7)。这是因为服务端的LISTEN状态下的SOCKET当收到SYN报文的建连请求后,它可以把ACK和SYN(ACK起应答作用,而SYN起同步作用)放在一个报文里来发送。但关闭连接时,当收到对方的FIN报文通知时,它仅仅表示对方没有数据发送给你了。
      TCP四次挥手过程是什么?

      TCP/IP协议的握手过程(转载)

      三次握手后会在各自内存空间中形成一个队列空间,并建立 socket 。四次挥手目的是为了安全的销毁双方的连接释放内存,之前开辟的队列空间是为了对方服务的。第一次握手:建立连接时,客户端发送syn包(syn=x)到服务器,并进入SYN_SENT状态,等待服务器确认;SYN:同步序列编号(Synchronize Sequence Numbers)。第二次握手:服务器收到syn包,必须确认客户的SYN(ack=x+1),同时自己也发送一个SYN包(syn=y),即SYN+ACK包,此时服务器进入SYN_RECV状态;第三次握手:客户端收到服务器的SYN+ACK包,向服务器发送确认包ACK(ack=y+1),此包发送完毕,客户端和服务器进入ESTABLISHED(TCP连接成功)状态,完成三次握手。答:因为当 Server 端收到 Client 端的 SYN 连接请求报文后,可以直接发送SYN+ACK报文。其中ACK报文是用来应答的,SYN报文是用来同步的。但是关闭连接时,当Server端收到FIN报文时,很可能并不会立即关闭SOCKET,所以只能先回复一个ACK报文,告诉Client端,"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了,我才能发送FIN报文,因此不能一起发送。故需要四步握手。【问题2】为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态?答:虽然按道理,四个报文都发送完毕,我们可以直接进入CLOSE状态了,但是我们必须假象网络是不可靠的,有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。在Client发送出最后的ACK回复,但该ACK可能丢失。Server如果没有收到ACK,将不断重复发送FIN片段。所以Client不能立即关闭,它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器,等待2MSL的时间。如果在该时间内再次收到FIN,那么Client会重发ACK并再次等待2MSL。所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间,2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL,Client都没有再次收到FIN,那么Client推断ACK已经被成功接收,则结束TCP连接。答:3次握手完成两个重要的功能,既要双方做好发送数据的准备工作(双方都知道彼此已准备好),也要允许双方就初始序列号进行协商,这个序列号在握手过程中被发送和确认。现在把三次握手改成仅需要两次握手,死锁是可能发生的。作为例子,考虑计算机 S 和 C 之间的通信,假定 C 给 S 发送一个连接请求分组,S 收到了这个分组,并发送了确认应答分组。按照两次握手的协定,S 认为连接已经成功地建立了,可以开始发送数据分组。可是,C 在 S 的应答分组在传输中被丢失的情况下,将不知道 S 是否已准备好,不知道 S 建立什么样的序列号,C 甚至怀疑 S 是否收到自己的连接请求分组。在这种情况下,C认为连接还未建立成功,将忽略 S 发来的任何数据分组,只等待连接确认应答分组。而 S 在发出的分组超时后,重复发送同样的分组。这样就形成了死锁。【问题4】如果已经建立了连接,但是客户端突然出现故障了怎么办?TCP 还设有一个保活计时器,显然,客户端如果出现故障,服务器不能一直等下去,白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器,时间通常是设置为 2 小时,若两小时还没有收到客户端的任何数据,服务器就会发送一个探测报文段,以后每隔 75 秒钟发送一次。若一连发送 10 个探测报文仍然没反应,服务器就认为客户端出了故障,接着就关闭连接。
      TCP/IP协议的握手过程(转载)

      (1)为什么结束FTP连接的时候需要有两次“四次挥手”的过程?

      因为TCP是全双工通信的。 第一次挥手因此当主动方发送断开连接的请求给被动方时仅仅代表主动方不会再发送数据报文了但主动方仍可以接收数据报文,第二次挥手被动方此时有可能还有相应的数据报文需要发送因此需要先发送ACK报文告知主动方“我知道你想断开连接的请求了这样主动方便不会因为没有收到应答而继续发送断开连接的请求,第三次挥手被动方在处理完数据报文后便发送给主动方FIN报文这样可以保证数据通信正常可地完成发送完FIN报文后被动方进入LASTACK阶段,第四挥手如果主动方及时发送ACK报文进行连接中断的确认这时被动方就直接释放连接进入状态。
      (1)为什么结束FTP连接的时候需要有两次“四次挥手”的过程?

      简述TCP连接三次握手四次挥手

      1.第一次握手:A的TCP客户进程向B发出连接请求报文段(首部的同步位SYN=1,初始序号seq=x,SYN=1的报文段不能携带数据,但要消耗掉一个序号),此时TCP客户进程进入SYN-SENT(同步已发送)状态。 2.第二次握手:B收到连接请求报文段后,如同意建立连接,则向A发送确认报文(SYN=1,ACK=1,确认号ack=x+1,初始序号seq=y),B进程进入SYN-RCVD(同步收到)状态,A进入ESTABLISHED(已建立连接)。3.第三次握手:A收到B的确认后,要向B发送确认收到确认的报文段(ACK=1,确认号ack=y+1,序号seq=x+1,初始为seq=x,第二个报文段所以要+1),ACK报文段可以携带数据,不携带数据则不消耗序号,TCP连接已经建立,当B收到A的确认后,也进入ESTABLISHED状态。可以看到,三次握手过程中,A的状态变化为 CLOSED->SYN-SEND->ESTABLISHED。B的状态变化为(CLOSED)LISTEN->SYNC-RECEIVED->ESTABLISHED,两者都经过3次状态变化。 为何需要最后的客户端应答(为什么需要第三次握手)?
      简述TCP连接三次握手四次挥手

      描述对tcp步骤?

      三次握手,四次挥手。 第一次握手:客户端向服务器端发送连接请求包SYN,等待服务器回应;第二次握手:服务器端收到客户端连接请求包SYN后,将客户端的请求包SYN放入到自己的未连接队列,此时服务器需要发送两个包给客户端;(1)向客户端发送确认自己收到其连接请求的确认包ACK,向客户端表明已知道了其连接请求(2)向客户端发送连接询问请求包SYN,询问客户端是否已经准备好建立连接,进行数据通信;即在第二次握手时服务器向客户端发送ACK和SYN包,此时服务器进入SYN-RCVD状态。第三次握手:客户端收到服务器的ACK和SYN包后,知道了服务器同意建立连接,此时需要发送连接已建立的消息给服务器;向服务器发送连接建立的确认包ACK,回应服务器的SYN告诉服务器,我们之间已经建立了连接,可以进行数据通信。ACK包发送完毕,服务器收到后,此时服务器与客户端进入ESTABLISHED状态,开始进行数据传送。TCP四次挥手过程断开一个tcp连接需要“四次挥手”第一次:主动关闭方发送一个FIN,用来关闭主动方到被动关闭方的数据传送,也就是主动关闭方告诉被动关闭方:我已经不会再给你发送数据了,但是,此时,主动关闭方依然可以接收数据。第二次:被动关闭方收到FIN包后,发送一个ACK给对方,确认序号为收到序号+1.第三次:被动关闭方发送一个FIN,用来关闭被动关闭方到主动关闭方的数据传送,也就是告诉主动关闭方,我已经发完了,不会再给你发数据了。 第四次:主动关闭方收到FIN后,发送一个ACK给对方,确认序号为收到序号+1,至此,四次挥手完成。
      描述对tcp步骤?

      本文由 在线网速测试 整理编辑,转载请注明出处。

          热门文章

          文章分类