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序号
以上是 HTTP的三次握手四次挥手 的全部内容， 来源链接： utcz.com/a/24460.html
