TCP/IP协议中三次握手（Three-way Handshake）与四次挥手（Four-way Wave）

以下是关于TCP/IP协议中三次握手（Three-way Handshake）与四次挥手（Four-way Wave）的详细整理：

目的：建立可靠的TCP连接，确保双方同步序列号并确认通信能力。
过程（分3步）：

第一次握手（SYN请求）
- 客户端发送TCP报文，设置标志位SYN=1，随机生成初始序列号Seq=X，表示请求连接。
- 客户端进入SYN_SENT状态，等待服务器响应。
第二次握手（SYN+ACK响应）
- 服务器收到请求后，发送TCP报文：
  - 标志位SYN=1, ACK=1，确认号Ack=X+1，自身生成初始序列号Seq=Y。
- 服务器进入SYN_RCVD状态，表示已准备好连接。
第三次握手（ACK确认）
- 客户端收到服务器的响应后，发送TCP报文：
  - 标志位ACK=1，确认号Ack=Y+1，序列号Seq=X+1。
- 双方进入ESTABLISHED状态，连接正式建立，开始数据传输。

关键点：

目的：优雅关闭TCP连接，确保双方数据完全传输并释放资源。
过程（分4步）：

第一次挥手（FIN请求关闭）
- 客户端发送TCP报文，设置标志位FIN=1，序列号Seq=U，表示停止发送数据。
- 客户端进入FIN_WAIT_1状态，等待服务器确认。
第二次挥手（ACK确认关闭请求）
- 服务器收到FIN后，发送TCP报文：
  - 标志位ACK=1，确认号Ack=U+1，序列号Seq=V（当前发送数据的序列号）。
- 服务器进入CLOSE_WAIT状态，通知应用层处理关闭请求，但仍可向客户端发送剩余数据。
第三次挥手（FIN请求反向关闭）
- 服务器发送完剩余数据后，发送TCP报文：
  - 标志位FIN=1, ACK=1，确认号Ack=U+1，序列号Seq=W（可能为V+1）。
- 服务器进入LAST_ACK状态，等待客户端最终确认。
第四次挥手（ACK确认反向关闭）
- 客户端收到服务器的FIN后，发送TCP报文：
  - 标志位ACK=1，确认号Ack=W+1，序列号Seq=U+1。
- 客户端进入TIME_WAIT状态（持续2MSL时间），确认服务器收到后正式关闭。

关键点：

四次挥手而非三次：因TCP是全双工模式，双方需独立关闭数据流。
2MSL（Maximum Segment Lifetime）等待 ：
- 确保最后一个ACK可靠到达服务器，防止连接异常中断。
- 允许网络中未送达的数据包自然消亡，避免新旧连接混淆。

为什么建立连接是三次握手，而关闭是四次挥手？
- 三次握手 ：服务器收到客户端的SYN请求后，可同时发送SYN（同步序列号）和ACK（确认），因此合并为一次响应。
- 四次挥手 ：服务器收到FIN后需先确认（ACK），但可能仍有数据待发送，需延迟发送FIN，导致分两步。
TIME_WAIT状态的作用？
- 防止延迟的重复FIN或ACK干扰新连接（若立即关闭，可能误认为新连接数据是旧数据）。
- 确保网络中的旧数据包彻底消失（2MSL通常是数据包的生存周期）。

三次握手通过"请求-响应-确认"机制建立可靠连接，而四次挥手通过双向独立关闭确保数据完整性。理解这些机制是网络编程和故障排查的基础，尤其在处理连接延迟、丢包等问题时至关重要。

TCP/IP协议中的三次握手和四次挥手是确保可靠连接建立与关闭的核心机制，其步骤数量经过精心设计，不能随意增减。以下是具体原因：

全双工特性：
○ TCP连接支持双向数据传输（如客户端和服务器可同时发送数据）。
○ 关闭需独立处理两个方向的数据流：
■ 第一次挥手：客户端停止发送数据（FIN）。
■ 第三次挥手：服务器停止发送数据（FIN）。
○ 若合并为三次（如服务器收到FIN后立即发FIN+ACK）：
■ 服务器可能仍有数据未发送完，导致数据丢失。
■ 客户端无法区分FIN和ACK的合并响应，可能误判连接状态。
确保数据完整性：
○ 第二次挥手（ACK）确认客户端的关闭请求，允许服务器继续发送剩余数据。
○ 第三次挥手（FIN）通知客户端服务器已无数据发送，触发客户端进入TIME_WAIT状态等待确认。
○ 若减少步骤，可能无法保证所有数据已被传输和确认。

● 三次握手：通过三次交互确保双向通信能力和序列号同步，减少或增加步骤都会破坏可靠性或效率。

● 四次挥手：因TCP全双工特性，必须分别关闭两个方向的数据流，合并步骤可能导致数据丢失或未完成关闭。

这种设计平衡了可靠性、效率和复杂性，是TCP/IP协议核心机制的关键组成部分。