四次挥手步骤？

本文目录导读：

1. 第一步：客户端发送 FIN 报文（挥手1）
2. 第二步：服务器回复 ACK 报文（挥手2）
3. 第三步：服务器发送 FIN 报文（挥手3）
4. 第四步：客户端回复 ACK 报文（挥手4）
5. 为什么是四次而不是三次？

“四次挥手”是TCP（传输控制协议）关闭连接时双方为保证数据可靠传输而进行的一系列交互过程，由于TCP连接是全双工的（数据可以双向同时传输），因此关闭连接时,每一端都需要独立地关闭自己的发送通道。

以下是标准的四次挥手步骤，以客户端主动关闭为例（主动方和被动方均可）：

第一步：客户端发送 FIN 报文（挥手1）

• 发送方： 客户端
• 报文标志： FIN = 1，seq = u（假设客户端已发送的最后一个字节序号为 u-1）
• 状态变化： 客户端进入 FIN_WAIT_1 状态。
• 含义： 客户端告诉服务器：“我已经没有数据要发送了，我请求关闭从客户端到服务器的数据传输通道。” 但客户端仍然可以接收数据。

第二步：服务器回复 ACK 报文（挥手2）

• 发送方： 服务器
• 报文标志： ACK = 1，seq = v（服务器已发送的最后一个字节序号为 v-1），ack = u + 1（确认收到客户端的 FIN）
• 状态变化： 服务器进入 CLOSE_WAIT 状态；客户端收到 ACK 后进入 FIN_WAIT_2 状态。
• 含义： 服务器确认收到了客户端的关闭请求，服务器仍然可以继续向客户端发送数据（如果还有未发送完的数据）,但客户端不会再主动发送数据了。

第三步：服务器发送 FIN 报文（挥手3）

• 发送方： 服务器
• 时机： 当服务器处理完自己的数据,或者也决定关闭连接时。
• 报文标志： FIN = 1，ACK = 1，seq = w（在第二步之后可能又发送了一些数据），ack = u + 1（仍需确认之前客户端的 FIN）
• 状态变化： 服务器进入 LAST_ACK 状态。
• 含义： 服务器告诉客户端：“我的数据也发送完了，现在我请求关闭从服务器到客户端的数据传输通道。”

第四步：客户端回复 ACK 报文（挥手4）

• 发送方： 客户端
• 报文标志： ACK = 1，seq = u + 1，ack = w + 1
• 状态变化： 客户端收到 FIN 后进入 TIME_WAIT 状态（这是一个关键的状态），并回复 ACK，服务器收到 ACK 后进入 CLOSED 状态。
• 含义： 客户端确认收到服务器的关闭请求。
• 重要机制（TIME_WAIT）：
  • 客户端不会立即进入 CLOSED 状态，而是会等待 2 倍的最大报文段生存时间（2MSL，Maximum Segment Lifetime）。
  • 目的：
    1. 确保最后一个 ACK 到达服务器： 如果服务器没收到这个 ACK，会超时重发 FIN，客户端在 TIME_WAIT 期间能够响应。
    2. 保证旧报文段在网络中消失： 防止本次连接中延迟的报文段干扰新的连接（具有相同IP和端口的后续连接）。

为什么是四次而不是三次？

• 关键在于服务器在收到客户端的 FIN 时，可能还有数据没有发送完。
• 服务器不能像“三次握手”那样将 ACK 和 FIN 合并发送（除非数据恰好也发送完了）。
• 通常的流程是：先回复ACK（告诉客户端我收到了你的关闭请求），等数据发完后再发送FIN（告诉客户端我也要关闭了）。 这导致了至少需要四个报文段（如果服务器没有数据要发送，理论上可以合并为三次，但TCP协议标准定义的是四次交互，以区别“断开”的严肃性和对端的独立状态管理）。

标签： 步骤