TCP协议三次握手，四次挥手_四次挥手断开连接可以保证a发送的最后一个确认报文段到b-CSDN博客

本文链接：https://blog.csdn.net/qq_18864907/article/details/90258922

TCP协议三次握手，四次挥手

TCP位码

SYN，同步位，表示是否建立连接
FIN，终止位，表示是否关闭连接
ACK，确认位，表示响应，确认接收到了相应序号的数据包
seq 是自己数据包本身的序号；ack是期望对方继续发送的那个数据包的序号。
MSL是Maximum Segment Lifetime英文的缩写，中文可以译为“报文最大生存时间”，他是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。

三次握手（客户端主动打开）

三次握手：由客户端A主动打开连接请求连接服务端B，代表运输连接的三个阶段：连接建立、数据传送、连接释放。

1. A 发送 SYN = 1，seq = x；表示客户端 A 发送 SYN 信号请求与服务端 B 握手同步，同时选择一个初始序号 x（随机的序号）

2. B 接受到 A 的连接请求报文，发送 SYN = 1，ACK = 1，seq = y，ack = x+1；表示服务端同意建立连接，把 SYN 位和 ACK 位都置 1，发送确认号 ack = seq + 1 = x + 1, 同时为自己也选择一个初始序号 seq = y（随机的序号）

3. A 接受到 B 的确认报文，发送 ACK = 1，ack = y+1，seq = x+1，TCP 客户A 收到 B 的确认后，还要向 B 给出确认，ACK 位置 1，携带自己的序号 seq = x + 1, 确认 B 的序列号，ack = y + 1

TCP 规定 SYN 报文段即使不携带数据，但是要消耗掉一个序号

四次挥手（客户端、服务端均可主动关闭）

数据传输结束后，通信的双方都可以释放连接。这里假设客户端主动发起关闭请求。

第一次挥手：客户端发送终止报文，报文中把 FIN 置1，seq=u（已传送过的数据最后一个字节序号+1），传送给服务端，客户端进入中止等待1状态(FIN-WAIT-1)。客户端主动发起终止连接的报文，并发送自己当前的序列号，然后开始等待 B 的确认。
第二次挥手：服务端发送确认报文，报文中把 ACK 置1，seq=v，ack=u+1给客户端，客户端进入中止等待2状态（FIN-WAIT-2），服务器进入关闭等待状态 close-wait。服务端 B 此时确认收到客户端 A 发送的终止报文，此时的 TCP 连接处于半关闭状态，即 A 已经没有数据要发送了，但是此时如果 B 若发送数据，A 仍要接收。
第三次挥手：服务端确认没有消息要发送后，最终发送终止确认报文。报文中 FIN=1，ACK=1,seq=w,ack=u+1，w 有可能等于 v 也有可能大于 v，取决于 B 在确认与终止之间是否又发送了一些数据。
第四次挥手：客户端发送确认报文 ACK=1，seq=u+1,ack=w+1 发送给服务器，服务器收到 ACK 报文段后立即关闭，客户端等待2MSL时间后关闭。

TCP 规定 FIN 报文段即使不携带数据，也要消耗掉一个序号。

在TCP三次握手中，为什么客户端最后还要发送一次确认呢？

如果只有两次确认，可能发生在客户端发送了第一次请求没有响应之后，客户端又发送了第二次同步请求，服务端与客户端的第二次同步请求建立连接完成后释放。
经过一段时间客户端的第一次请求并没有丢失，而是在一个节点长时间滞留了，现在又到了服务端，此时服务端又发送一个确认同步请求，此时由于客户端没有第三次握手确认，不会响应请求。服务端单方面认为已经与客户端建立了连接，并苦苦等待客户端发来的数据，造成服务端资源的白白浪费。

在TCP四次挥手中的第三挥手服务端为什么不直接释放连接，而是要先确认一次第二次才释放？

TCP是全双工模式，这就意味着，当主机A发出FIN报文段时，只是表示主机A已经没有数据要发送了，主机A告诉主机B，它的数据已经全部发送完毕了。但是，这个时候主机A还是可以接受来自主机B的数据，因为主机B有可能还有数据没有发送完成。当主机B返回ACK报文段时，表示它已经知道主机A没有数据发送了，但是主机B还是可以发送数据到主机A的。当主机B也发送了FIN报文段时，这个时候就表示主机B也没有数据要发送了，就会告诉主机A，我也没有数据要发送了，之后彼此就会愉快的中断这次TCP连接。