TCP连接释放：四次握手（每次握手发的字段及字段值的解释）

字段内容 ：FIN=1，ACK=0（默认，若之前有数据会带 ACK，但这里是第一次挥手，主要发 FIN ），seq=u，ack=任意（因为还没收到 B 新数据，ack 无意义）
为啥发这些？
- FIN=1：告诉 B "我（A）没数据要发了，请求关闭 A→B 方向的连接"。
- seq=u：A 本次发送的 "序列号"，是 A 之前数据序列号的延续（比如 A 之前发数据的最后 seq 是 u-1，现在发 FIN 用 seq=u，占一个序列号）。
- ACK=0：这里主要是发 FIN，没有需要确认的新数据（如果之前有未确认的数据，ACK 会置 1 并带 ack 号，但第一次挥手时，假设之前数据已确认，所以 ACK 可置 0 或 1，不影响核心逻辑，实际实现可能默认带 ACK=1，需看具体场景）。

字段内容 ：ACK=1，ack=u+1，seq=v，FIN=0
为啥发这些？
- ACK=1：告诉 A "我（B）确认收到你的 FIN 报文了"。
- ack=u+1：B 期望 A 下一个序列号是 u+1（因为 B 收到了 A 的 seq=u，所以确认号是 u+1，表示 "我收到了 seq≤u 的所有数据，下一个要 u+1"）。
- seq=v：B 自己的 "序列号"，延续 B 之前发送数据的 seq（比如 B 之前最后发的 seq 是 v-1，现在发 ACK 用 seq=v，即使没带数据，序列号也要递增，因为 TCP 是面向字节流的，每个报文（包括控制报文）都占序列号）。
- FIN=0：B 还没准备好关闭 B→A 方向的连接（因为可能还有数据要发），所以 FIN 置 0。

字段内容 ：FIN=1，ACK=1，ack=u+1，seq=w
为啥发这些？
- FIN=1：告诉 A "我（B）也没数据要发了，请求关闭 B→A 方向的连接"。
- ACK=1：继续确认 A 的 FIN（因为 TCP 要求，只要发确认，ACK 就置 1，这里同时确认之前的 ack=u+1）。
- ack=u+1：和第二步一样，确认 A 的 seq=u，保持确认号不变（因为 A 没有新数据发送，确认号一直是 u+1，直到 A 有新动作）。
- seq=w：B 发送 FIN 报文的序列号，延续 B 之前的 seq（比如 B 第二步发的 seq=v，处理完数据后，现在发 FIN 用 seq=w，w 是 v 之后的序列号，因为 B 可能在第二步和第三步之间发了数据，seq 会递增；如果没发数据，w = v + 1，因为 ACK 报文虽然没带数据，但占了序列号 v，所以下一个 seq 是 v + 1）。

字段内容 ：ACK=1，ack=w+1，seq=u+1，FIN=0
为啥发这些？
- ACK=1：告诉 B "我（A）确认收到你的 FIN 报文了"。
- ack=w+1：A 期望 B 下一个序列号是 w+1（因为 A 收到了 B 的 seq=w，所以确认号是 w+1）。
- seq=u+1：A 发送 ACK 报文的序列号，延续 A 之前的 seq（A 第一步发的 seq=u，第二步收到 B 的 ACK 后，A 的 seq 不需要递增，因为 A 没有新数据发送；但第四步发 ACK 时，seq 是 u+1，因为 A 第一步的 FIN 占了 seq=u，所以下一个 seq 是 u+1，即使没带数据，序列号也要推进）。
- FIN=0：A 已经发过 FIN 了，这里只是确认 B 的 FIN，所以 FIN 置 0。

序列号（seq）：
- TCP 是 面向字节流 的协议，每个字节都有编号，seq 标识 "本端发送的当前报文的第一个字节的序号"。
- 即使是控制报文（如 FIN、ACK），也会占用序列号（因为要保证 "有序性" 和 "不丢包"）。所以每次发报文（不管有没有数据），seq 都会递增，延续之前的序列。
确认号（ack）：
- ack 是 "期望对方下一个发送的序列号"，规则是 ack = 收到的 seq + 1。
- 作用是告诉对方："我已经收到了 seq 及之前的所有数据，你下次发 seq + 1 吧"，保证数据不重复、不丢失。
FIN 与 ACK 标记：
- FIN 是 "关闭连接请求"，置 1 表示 "本端没数据要发了，请求关闭方向"。
- ACK 是 "确认有效"，置 1 表示 "本端确认收到了对方的报文（通过 ack 号体现）"。
- 四次挥手中，ACK 几乎全程置 1（除了第一步可能置 0，但实际实现常带 ACK=1），因为每次回应都需要确认对方的报文；FIN 则在需要关闭方向时置 1。