HTTP的三次握手四次挥手

563 阅读7分钟

位码即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为否,就是收到同步和确认信号

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则连接建立成功。
为什么最后一次握手的seq = x + 1?

SYN在对端确认的时候要消耗一个序列号所以是上一次发送的seq = x,这次就是seq = x + 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序号