TCP的三次握手和四次挥手实现过程。以及为什么需要三次握手？四次挥手？

三次握手的实现

TCP 三次握手（Three-Way Handshake）是建立 TCP 连接的核心过程，其目的是确保客户端和服务器双方的发送能力与接收能力均正常，并协商初始序列号（用于后续数据传输的有序性和完整性校验）。以下是详细过程：

三次握手的核心角色与参数

• 客户端：主动发起连接的一方（如浏览器）。
• 服务器：被动接受连接的一方（如 Web 服务器）。
• 序列号（Sequence Number，seq）：发送方为每个数据包分配的唯一编号，用于接收方确认数据顺序和完整性（避免重复或丢失）。
• 确认号（Acknowledgment Number，ack）：接收方告知发送方“已收到的最大序列号 + 1”，表示期望接收的下一个数据编号。
• 标志位：
  • SYN（Synchronize）：用于发起连接，请求同步序列号。
  • ACK（Acknowledgment）：用于确认已收到数据。

三次握手的具体步骤

第一步：客户端 → 服务器（发送 SYN 报文）

• 客户端行为：
  客户端向服务器发送一个 SYN 报文（同步请求），表示“我想和你建立连接”。
  报文中包含：

  • 标志位：SYN = 1（表示这是一个连接请求）。
  • 初始序列号：seq = x（x 是客户端随机生成的 32 位整数，如 1000）。

• 服务器状态变化：
  服务器收到 SYN 报文后，从“关闭状态”进入“同步收到状态（SYN-RCVD）”，表示“已收到连接请求，准备回应”。

第二步：服务器 → 客户端（发送 SYN+ACK 报文）

• 服务器行为：
  服务器向客户端回复一个 SYN+ACK 报文（同步 + 确认），表示“我收到了你的请求，也想和你建立连接”。
  报文中包含：

  • 标志位：SYN = 1（服务器发起自己的同步请求）、ACK = 1（确认收到客户端的请求）。
  • 服务器的初始序列号：seq = y（y 是服务器随机生成的整数，如 2000）。
  • 确认号：ack = x + 1（表示“已收到客户端序列号为 x 的报文，下一次期望接收 x+1 及以后的数据”）。

• 客户端状态变化：
  客户端收到 SYN+ACK 报文后，从“同步发送状态（SYN-SENT）”进入“建立连接状态（ESTABLISHED）”，表示“确认服务器已准备好，连接即将建立”。

第三步：客户端 → 服务器（发送 ACK 报文）

• 客户端行为：
  客户端向服务器发送一个 ACK 报文（确认），表示“我收到了你的回应，连接可以正式建立了”。
  报文中包含：

  • 标志位：ACK = 1（仅确认，无新的同步请求）。
  • 客户端的序列号：seq = x + 1（基于第一步的 x 递增，符合 TCP 序列号连续的规则）。
  • 确认号：ack = y + 1（表示“已收到服务器序列号为 y 的报文，下一次期望接收 y+1 及以后的数据”）。

• 服务器状态变化：
  服务器收到 ACK 报文后，从“同步收到状态（SYN-RCVD）”进入“建立连接状态（ESTABLISHED）”，表示“双方确认完毕，TCP 连接正式建立”。

三次握手的核心目的

1. 验证双向通信能力：

   • 第一步：客户端确认服务器“能接收”（服务器收到 SYN）。
   • 第二步：服务器确认客户端“能发送也能接收”（客户端收到 SYN+ACK）。
   • 第三步：客户端确认服务器“能发送”（服务器收到 ACK）。
     三次交互后，双方确认彼此的发送和接收功能均正常。

2. 协商初始序列号：
   客户端和服务器通过前两步交换各自的初始序列号（x 和 y），后续数据传输将基于这些序列号递增，确保数据有序且可校验（如通过序列号检测丢包或重复数据）。

为什么需要三次握手，而不是两次？

• 若仅用两次握手，服务器在发送 SYN+ACK 后就认为连接已建立，但客户端可能因网络延迟等原因未收到该报文，此时服务器会一直等待客户端发送数据，造成资源浪费。
• 三次握手的最后一步（客户端发送 ACK）确保客户端确实收到了服务器的回应，避免服务器“单方面”建立无效连接，减少资源消耗。

总结

三次握手的本质是“双向确认”：
客户端请求连接 → 服务器确认并请求连接 → 客户端确认
通过三次交互，双方验证了通信能力并协商了初始序列号，最终建立可靠的 TCP 连接，为后续数据传输奠定基础。

四次挥手的实现

在 TCP 协议中，四次挥手（Four-Way Wavehand） 是关闭 TCP 连接的过程，用于确保双方都已完成数据传输，并安全释放连接资源。与三次握手建立连接不同，四次挥手需要四次交互，核心原因是 TCP 连接是全双工的（双方可同时发送数据），关闭连接时需各自独立终止发送方向的数据流。

四次挥手的核心背景

TCP 连接是“全双工”模式，即客户端和服务器可以同时向对方发送数据。因此，关闭连接时需分两步：

1. 一方先终止向对方发送数据（关闭发送通道）；
2. 另一方确认并终止自己的发送通道。
   这一过程需要四次交互来完成双向确认。

四次挥手的具体步骤

假设客户端主动发起关闭请求（实际中服务器也可主动发起），步骤如下：

第一步：客户端 → 服务器（发送 FIN 报文）

• 客户端行为：
  客户端完成数据发送后，向服务器发送 FIN 报文（Finish，结束），表示“我已完成数据发送，请求关闭我向你发送数据的通道”。
  报文中包含：

  • 标志位：FIN = 1（表示终止发送）。
  • 序列号：seq = u（u 是客户端已发送的最后一个字节的序列号 + 1，如客户端最后发送的序列号是 1000，则 u = 1001）。

• 客户端状态变化：
  从“建立连接状态（ESTABLISHED）”进入“终止等待 1 状态（FIN-WAIT-1）”，等待服务器确认。

第二步：服务器 → 客户端（发送 ACK 报文）

• 服务器行为：
  服务器收到 FIN 报文后，回复 ACK 报文，表示“已收到你关闭发送通道的请求，我会处理剩余数据”。
  报文中包含：

  • 标志位：ACK = 1（确认）。
  • 序列号：seq = v（服务器当前的序列号，基于自身已发送的数据）。
  • 确认号：ack = u + 1（表示“已收到序列号 u 的 FIN 报文，下一次期望接收 u+1”）。

• 服务器状态变化：
  从“ESTABLISHED”进入“关闭等待状态（CLOSE-WAIT）”，此时客户端到服务器的发送通道已半关闭（客户端不再发送数据，但服务器仍可向客户端发送数据）。

• 客户端状态变化：
  收到 ACK 后，从“FIN-WAIT-1”进入“终止等待 2 状态（FIN-WAIT-2）”，等待服务器发送自己的 FIN 报文。

第三步：服务器 → 客户端（发送 FIN 报文）

• 服务器行为：
  服务器完成所有数据发送后，向客户端发送 FIN 报文，表示“我也已完成数据发送，请求关闭我向你发送数据的通道”。
  报文中包含：

  • 标志位：FIN = 1、ACK = 1（通常同时携带确认）。
  • 序列号：seq = w（服务器最后发送的字节序列号 + 1，基于 v 递增）。
  • 确认号：ack = u + 1（与第二步的确认号一致，因未收到新数据）。

• 服务器状态变化：
  从“CLOSE-WAIT”进入“最后确认状态（LAST-ACK）”，等待客户端的最终确认。

第四步：客户端 → 服务器（发送 ACK 报文）

• 客户端行为：
  客户端收到服务器的 FIN 报文后，回复 ACK 报文，表示“已收到你关闭发送通道的请求，连接即将完全关闭”。
  报文中包含：

  • 标志位：ACK = 1。
  • 序列号：seq = u + 1（基于第一步的 u 递增）。
  • 确认号：ack = w + 1（表示“已收到序列号 w 的 FIN 报文，下一次期望接收 w+1”）。

• 客户端状态变化：
  从“FIN-WAIT-2”进入“时间等待状态（TIME-WAIT）”，并启动一个 2MSL（Maximum Segment Lifetime，报文最大生存时间，通常为 2 分钟） 的计时器。

  • 目的：确保服务器能收到最终的 ACK 报文（若服务器未收到，会重发 FIN，客户端在 2MSL 内可再次回复）。
  • 2MSL 后，客户端进入“关闭状态（CLOSED）”。

• 服务器状态变化：
  收到 ACK 后，从“LAST-ACK”直接进入“CLOSED”状态，释放连接资源。

四次挥手的核心目的

1. 确保双向数据传输完成：
   双方分别通过 FIN 报文告知对方“自己的发送已结束”，通过 ACK 确认对方已知晓，避免数据丢失。
2. 避免连接关闭后的报文干扰：
   客户端的 2MSL 等待时间，确保网络中残留的旧报文（属于当前连接）已过期，防止其干扰新连接（新连接可能使用相同的端口）。

为什么需要四次挥手，而不是三次？

• 三次握手时，服务器的 SYN 和 ACK 可合并为一次报文（第二步 SYN+ACK），因为此时服务器无需处理未完成的数据发送。
• 四次挥手时，服务器收到客户端的 FIN 后，可能还有未发送完的数据，因此需先回复 ACK 确认（第二步），待数据发送完毕后再发送 FIN（第三步），无法合并为一次报文，因此需要四次交互。

总结

四次挥手是 TCP 全双工连接关闭的必然过程：
客户端请求关闭发送通道 → 服务器确认 → 服务器请求关闭发送通道 → 客户端确认并等待
通过四次交互，双方安全终止双向数据流，并通过时间等待机制确保连接资源的彻底释放，是 TCP 可靠性的重要体现。