TCP 三次握手宕机影响分析

在 TCP 三次握手过程中，如果发送 SYN 后某一方宕机，具体结果取决于宕机发生的时机和角色（客户端或服务器）。以下是详细分析：

1. 客户端发送 SYN 后宕机（未收到 SYN-ACK）

• 场景：客户端发送 SYN 后宕机，服务器尚未收到 SYN 或未响应 SYN-ACK。
• 结果：
  • 服务器未收到 SYN：客户端宕机可能导致 SYN 未到达服务器，服务器无任何响应。客户端若恢复后，会因超时重传 SYN，但若宕机期间未恢复，连接直接失败。
  • 服务器收到 SYN 但未响应：若服务器在接收 SYN 前宕机，客户端会因未收到 SYN-ACK 而持续重传 SYN（通常重试 3-6 次，间隔指数增长），最终超时返回 Connection timed out 错误。

2. 客户端发送 SYN 后宕机（服务器已回复 SYN-ACK）

• 场景：服务器收到 SYN 并回复 SYN-ACK，但客户端在回复 ACK 前宕机。
• 结果：
  • 服务器会等待客户端的 ACK，进入 SYN-RECEIVED 状态，并启动超时重传机制（重传 SYN-ACK，次数和间隔由系统配置决定，如 Linux 默认重试 5 次，总耗时约 180 秒）。
  • 若客户端始终未回复 ACK，服务器最终会关闭半连接，释放资源。

3. 服务器发送 SYN-ACK 后宕机

• 场景：服务器发送 SYN-ACK 后宕机，客户端收到 SYN-ACK 但无法发送 ACK。
• 结果：
  • 客户端会认为连接已建立（进入 ESTABLISHED 状态），但服务器因宕机未记录连接状态。
  • 当客户端尝试发送数据时，服务器因无连接记录会回复 RST 报文，强制关闭连接。

关键机制与注意事项

1. 超时重传：

   • 双方均依赖超时重传机制（如客户端重传 SYN，服务器重传 SYN-ACK），确保短暂网络问题可恢复。
   • 超时后连接资源（如端口、内存）会被释放，避免长期占用。

2. 半连接队列：

   • 服务器将未完成握手的连接放入半连接队列（SYN Queue），若队列满可能导致新连接被丢弃（触发 SYN Flood 攻击防护）。

3. SYN Cookie 防护：

   • 若服务器启用 SYN Cookie（如应对 SYN Flood），不会立即分配资源，而是通过加密算法生成 SYN-ACK 的序列号。即使宕机，客户端后续 ACK 可通过 Cookie 验证重建连接，减少资源浪费。

4. 宕机重启的影响：

   • 重启后，系统会清除所有之前的连接状态。任何未完成的握手都会因超时或 RST 报文终止。

总结

• 客户端宕机：若在发送 SYN 后宕机，连接可能因服务器未响应或超时重传失败而终止。
• 服务器宕机：若在回复 SYN-ACK 后宕机，客户端可能误认为连接已建立，但实际通信时会收到 RST 报文重置连接。
• 最终结果：TCP 的可靠性设计（超时重传、状态管理）确保异常场景下资源最终释放，连接无法建立。

通过超时机制和状态管理，TCP 能够在握手阶段异常时优雅处理，避免系统资源耗尽或长期无效等待。