H5W3
当前位置:H5W3 > 其他技术问题 > 正文

HTTP的三次握手四次挥手

原博客:baijiahao.baidu.com/s?id=165422… and 神三元的博客文档

位码即tcp标志位,有6种标示:SYN(synchronous建立联机) ACK(acknowledgement 确认) PSH(push传送) FIN(finish结束) RST(reset重置) URG(urgent紧急)Sequence number(顺序号码) Acknowledge number(确认号码)

seq(消息序号):第一次请求时,随机生成一个值,而后每次+1

ack(确认序号,注意是小写):接收上一条信息的seq+1

ACK:确认序号有效。

SYN:发起一个新连接。

PSH:接收方应该尽快将这个报文交给应用层。

RST:重置连接。

FIN:释放一个连接。

tcp建立连接需要三次握手.SYN是发送标志位(请求连接),ACK是确认标志位.1为是,0为否,就是收到同步和确认信号

不要将确认序号Ack与标志位中的ACK搞混了。确认方Ack=发起方Seq+1,两端配对。

1.”三次握手”的详解

所谓的三次握手即TCP连接的建立。这个连接必须是一方主动打开,另一方被动打开的。以下为客户端主动发起连接的图解:

第一次握手:SYN=1,ACK=0,seq=x;
第二次握手:SYN=1,ACK=1,ack=x+1,seq=y;
第三次握手:SYN=0,ACK=1,,ack=y+1,seq=x+1
第一次握手:B只可以确认自己可以接受A发送的报文段、:SYN=1的报文段不能携带数据,但消耗一个序号
第二次握手:A可以确认 B收到了自己发送的报文段,并且可以确认 自己可以接受B发送的报文段、:二次握手时分配服务器端的资源
第三次握手:B可以确认A收到了自己发送的报文段:ACK报文段可以携带数据,不携带数据则不消耗序号。三次握手时分配客户端的资源
TCP协议建立连接的三次握手过程中,带有SYN标志的过程包是不可以携带数据的,只有第三次握手允许携带数据。
第一次握手:主机A发送位码为syn=1,随机产生seq number=1234567的数据包到服务器,主机B由SYN=1知道,A要求建立联机;
第二次握手:主机B收到请求后要确认联机信息,向A发送ack number=(主机A的seq+1),syn=1,ack=1,随机产生seq=7654321的包;
第三次握手:主机A收到后检查ack number是否正确,即第一次发送的seq number+1,以及位码ack是否为1,若正确,主机A会再发送ack number=(主机B的seq+1),ack=1,主机B收到后确认seq值与ack=1则连接建立成功。
 

抓包验证

下面是用抓包工具抓到的一些数据包,可用来分析TCP的三次握手:

图中显示的就是完整的TCP连接的”三次握手”过程。在52528 -> 80中,52528是本地(客户端)端口,80是服务器的端口。80端口和52528端口之间的三次来回就是”三次握手”过程。

注意到”第一次握手”客户端发送的TCP报文中以[SYN]作为标志位,并且客户端序号Seq=0;

接下来”第二次握手”服务器返回的TCP报文中以[SYN,ACK]作为标志位;并且服务器端序号Seq=0;确认号Ack=1(“第一次握手”中客户端序号Seq的值+1);

最后”第三次握手”客户端再向服务器端发送的TCP报文中以[ACK]作为标志位;

其中客户端序号Seq=1(“第二次握手”中服务器端确认号Ack的值);确认号Ack=1(“第二次握手”中服务器端序号Seq的值+1)。

这就完成了”三次握手”的过程,符合前面分析的结果。

“四次挥手”的详解

所谓的四次挥手即TCP连接的释放(解除)。连接的释放必须是一方主动释放,另一方被动释放。以下为客户端主动发起释放连接的图解:

挥手之前主动释放连接的客户端结束ESTABLISHED阶段。随后开始“四次挥手”:

(1)首先客户端想要释放连接,向服务器端发送一段TCP报文,其中:

标记位为FIN,表示“请求释放连接“;
序号为Seq=U;
随后客户端进入FIN-WAIT-1阶段,即半关闭阶段。并且停止在客户端到服务器端方向上发送数据,但是客户端仍然能接收从服务器端传输过来的数据。

注意:这里不发送的是正常连接时传输的数据(非确认报文),而不是一切数据,所以客户端仍然能发送ACK确认报文。

(2)服务器端接收到从客户端发出的TCP报文之后,确认了客户端想要释放连接,随后服务器端结束ESTABLISHED阶段,进入CLOSE-WAIT阶段(半关闭状态)并返回一段TCP报文,其中:

标记位为ACK,表示“接收到客户端发送的释放连接的请求”;

序号为Seq=V;

确认号为Ack=U+1,表示是在收到客户端报文的基础上,将其序号Seq值加1作为本段报文确认号Ack的值;

随后服务器端开始准备释放服务器端到客户端方向上的连接。

客户端收到从服务器端发出的TCP报文之后,确认了服务器收到了客户端发出的释放连接请求,随后客户端结束FIN-WAIT-1阶段,进入FIN-WAIT-2阶段

前”两次挥手”既让服务器端知道了客户端想要释放连接,也让客户端知道了服务器端了解了自己想要释放连接的请求。于是,可以确认关闭客户端到服务器端方向上的连接了

(3)服务器端自从发出ACK确认报文之后,经过CLOSED-WAIT阶段,做好了释放服务器端到客户端方向上的连接准备,再次向客户端发出一段TCP报文,其中:

标记位为FIN,ACK,表示“已经准备好释放连接了”。注意:这里的ACK并不是确认收到服务器端报文的确认报文。

序号为Seq=W;

确认号为Ack=U+1;表示是在收到客户端报文的基础上,将其序号Seq值加1作为本段报文确认号Ack的值。

随后服务器端结束CLOSE-WAIT阶段,进入LAST-ACK阶段。并且停止在服务器端到客户端的方向上发送数据,但是服务器端仍然能够接收从客户端传输过来的数据。

(4)客户端收到从服务器端发出的TCP报文,确认了服务器端已做好释放连接的准备,结束FIN-WAIT-2阶段,进入TIME-WAIT阶段,并向服务器端发送一段报文,其中:

标记位为ACK,表示“接收到服务器准备好释放连接的信号”。

序号为Seq=U+1;表示是在收到了服务器端报文的基础上,将其确认号Ack值作为本段报文序号的值。

确认号为Ack=W+1;表示是在收到了服务器端报文的基础上,将其序号Seq值作为本段报文确认号的值。

随后客户端开始在TIME-WAIT阶段等待2MSL

注意了,这个时候,客户端需要等待足够长的时间,具体来说,是 2 个 MSL(Maximum Segment Lifetime,报文最大生存时间), 在这段时间内如果客户端没有收到服务端的重发请求,那么表示 ACK 成功到达,挥手结束,否则客户端重发 ACK

等待2MSL(报文最大生存时间)的意义

如果不等待,客户端直接跑路,当服务端还有很多数据包要给客户端发,且还在路上的时候,若客户端的端口此时刚好被新的应用占用,那么就接收到了无用数据包,造成数据包混乱。所以,最保险的做法是等服务器发来的数据包都死翘翘再启动新的应用。

那,照这样说一个 MSL 不就不够了吗,为什么要等待 2 MSL?

1 个 MSL 确保四次挥手中主动关闭方最后的 ACK 报文最终能达到对端

1 个 MSL 确保对端没有收到 ACK 重传的 FIN 报文可以到达

这就是等待 2MSL 的意义

ack和seq的总结

如果收到了上家发过来的序号seq,那么自己发过去的确认序号ack=seq+1

如果收到了上家发过来的确认序号ack,那么自己发过去的序号seq=ack,否则自己重新生成一个随机的seq序号

本文地址:H5W3 » HTTP的三次握手四次挥手

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址