61°

TCP协议“三次握手”与“四次挥手”详解(下)

  “三次握手”,参考:https://www.cnblogs.com/KongJetLin/p/13063394.html


 

  前面进行“三次握手”建立连接后,当客户端的数据发送完毕,它就会要求与服务器端断开连接,那么就要进行“四次挥手”进行连接的释放。

  注意,此处所谓的“客户端”与“服务器端”,只是为了方便标识连接的双方,即确认哪一方是“要求断开连接”的主动方,哪一方是“要求断开连接”的被动方。事实上任何一方都可能在发送完数据后要求与另一方断开连接。

1、“四次挥手”过程

  如下图:

 

 

 

 

   “四次挥手”的具体过程如下:

1)“第一次挥手”:首先,客户端已经发送完数据,想要释放连接(客户端是释放连接的主动方),向服务器端发送一段TCP报文,其中:

  i)标记位 FIN=1:表示这个TCP请求是“请求释放连接”;

  ii)报文的序号 seq=u:u 等于前面客户端已经传送的数据的最后一个字节的序号加1;

  iii)客户端由“ESTABLISHED”连接建立状态,进入“FIN-WAIT-1”终止等待状态1。此时客户端不会再向服务器端发送数据。

需要注意,FIN报文虽然不携带数据,但是但是它会消耗一个字节序号。即客户端第一次发送的FIN报文 seq=u,报文会消耗一个序号,那么客户端下次发送的报文应该从 seq=u+1 开始发送。

 

2)“第二次挥手”:服务器端接收到从客户端发出的TCP报文之后,确认了客户端想要释放连接,会发送回一个TCP报文,其中:

  i)标记位为ACK=1:表示“服务器端告知客户端,自己已经接收到客户端发送的释放连接的请求”;

  ii)报文序号 seq=v:服务器端到客户端的连接还没有关闭,服务器端还会向客户端发送数据包,这个报文序号为 v;

  iii)确认号ack = u+1:表示希望客户端下一个报文的序号是 u+1,即希望客户端下一个报文从序号为 u+1 的字节开始发送。我们知道客户端第一个报文 seq=u,且该报文为FIN报文,占一个序号,那么客户端下一个报文就应该从 u+1 开始发送。

  iv)服务器端结束 “ESTABLISHED” 连接阶段,进入“CLOSE-WAIT” 关闭等待状态;

此时从 客户端到服务器端 这个方向的连接就被释放,TCP连接处于“半关闭状态” 。 此时客户端不会再向服务器端发送数据,但是服务器端可能还会想客户端发送数据。

  v)客户端收到从服务器端发出的TCP报文之后,确认了服务器端收到了客户端发出的释放连接请求,随后客户端结束“FIN-WAIT-1”终止等待状态1,进入“FIN-WAIT-2”终止等待状态2。

总结:前两次挥手,既让服务器端知道了客户端想要释放连接,也让客户端知道了服务器端知道了自己想要释放连接。

 

3)“第三次挥手”:客户端经过 “ClOSE-WAIT” 关闭等待 状态后,它要发送给服务器端的数据也发送完毕,即它做好了释放服务器端到客户端连接的准备,就会想客户端发送一段FIN的TCP报文:

  i)标记位 FIN=1,ACK=1:表示“服务器端告知客户端,自己已经做好释放连接的准备”;

  ii)报文序号 seq=w:关闭等待阶段,服务器端可能又向客户端发送了数据,因此此时 seq 不是v,而是最新的数据 w;

  iii)确认号 ack=u+1:还是希望客户端下一次发送的报文序号为 u+1;

  iv)发送“第三次挥手”报文后,服务器端进入“LAST-ACK” 最后确认阶段。此后,服务器端再也无法向客户端发送数据。

注意,第三次挥手发送的是FIN的报文,没有数据但是会占一个序号,即下一次服务器端发送的报文序号 seq=w+1。

 

4)“第四次挥手”:客户端接收到服务器端“第三次挥手”的报文后,确认服务器端已经做好断开连接的准备,会向客户端发送“第四次握手”的报文:

  i)标记位ACK=1:表示“客户端已经知道服务器端做好释放连接的准备”;

  ii)ack = w+1:将收到服务器端报文的 seq+1,作为自己的ack。表示希望服务器端下次发送的报文的序号为 w+1;

  iii)seq=u+1:将收到服务器端报文的 ack 作为自己的 seq,因为服务器端报文 ack=u+1 表示希望客户端这次发送的报文序号是 u+1,那么客户端这次发送报文的序号就设置为 u+1;

  iv)客户端发送完第四次挥手的报文后,启动等待计时器,等待2MSL后,如果没有收到服务器端新的请求,就进入“CLOSED” 连接关闭状态;

  v)服务器端在收到客户端发送的第四次挥手的报文后,进入进入“CLOSED” 连接关闭状态。

总结:后“两次挥手”既让客户端知道了服务器端准备好释放连接了,也让服务器端知道了客户端了解了自己准备好释放连接了。于是,可以确认关闭服务器端端到客户端方向上的连接了,由此完成“四次挥手”,关闭了连接。

 

2、三个关键问题

1)为什么“握手”是三次,而“挥手”却是四次?

  对于“三次握手”,在第二次握手的时候,服务器端向客户端发送的报文的标记位包含 SYN=1以及ACK=1,SYN是请求连接标志,表示服务器端同意建立连接;ACK是确认报文,表示告诉客户端,服务器端收到了它的请求报文。即“确认接收”与“同意连接”是在同一次握手中传输的。那么通过三次握手就刚刚好可以建立连接;

  对于“四次挥手”,第二次挥手的时候,服务器端可能还没有做好关闭连接的准备(它可能还有数据要发送给客户端),因此,它不会立即释放连接,会在第二次挥手先返回一个ACK=1,表示已经接受到客户端的断开连接的请求。随后,客户端处理完数据后,会发送第三次挥手报文,其中FIN=1,表示服务器端已经准备好释放连接。因此,释放连接需要经过“四次挥手”。

 

2)为什么客户端要在发送第四次挥手的报文后等待2MSL的时间才进入CLOSED状态?

  目的是为了确认服务器端会收到客户端发送的“第四次挥手”的ACK确认报文。

  MSL(Max Segment Lifetime): 最长报文段寿命,也就是一个报文在网络中存活的最长时间,一般设置为2分钟。当客户端发出最后的ACK确认报文时,并不能确定服务器端能够收到该段报文。所以客户端在发送完ACK确认报文之后,会设置一个时长为2MSL的计时器。

  在1MSL的时候,如果服务器端没有收到客户端发送的ACK确认报文,就会再次向客户端发送FIN报文,这个报文在1MSL的时间内会到达客户端,此时客户端边知道自己上一次发送的ACK确认报文没有发送到服务器端,于是客户端会再次向服务器端发送ACK确认报文,并将等待计时器重置。

  如果在2MSL的时间内没有接受到服务器端发送回来的FIN报文,说明客户端最后发送的ACK确认报文已经被服务器端接收到,可以关闭连接。因此,事实上客户端会比服务器端更晚进入CLOSED状态。

 

3)如果已经建立了连接,但是客户端出现故障了怎么办?

  如果客户端发送错误,服务器端还一直保持连接,这个连接并不会传送数据,并且占用了服务器端的资源。服务器端有一个“保活计时器”,服务器端每收到一次客户端的请求后都会重新复位这个计时器,时间通常是设置为2小时,若2小时还没有收到客户端的任何数据,客户端就会发送一个探测报文段,以后每隔75秒钟发送一次。若一连发送10个探测报文客户端仍然没反应,服务器端就认为客户端出了故障,接着就关闭连接。

 

本文转载自博客园,原文链接:https://www.cnblogs.com/KongJetLin/p/13067989.html

全部评论: 0

    我有话说: