TCP 三次握手与四次挥手深度解析（面试高频）

一、三次握手详解

问题：为什么必须是三次握手？两次或四次会有什么问题？
三次握手流程：

Client Server SYN=1, seq=x (我想连接) SYN=1, ACK=1, seq=y, ack=x+1 (我准备好了，你呢？) ACK=1, seq=x+1, ack=y+1 (我也好了，可以传输啦~) Client Server

为什么不能是两次握手？

历史连接问题：
如果客户端发送的SYN因网络延迟超时重传，旧的SYN可能在新连接建立后到达服务端。
两次握手时，服务端直接进入连接状态，会错误接受过期请求。
三次握手通过客户端的最终ACK确认当前连接的时效性。
资源浪费风险：
服务端在收到SYN后立即分配资源（如连接缓冲区），若客户端不回应ACK，会导致资源长期占用。
攻击者可利用此发起SYN Flood攻击。
双向通信能力验证：
第三次握手确认客户端的接收能力和服务端的发送能力均正常。

为什么不需要四次握手？

第三次握手已能同时携带数据（如HTTP请求），额外握手会增加延迟而无实际收益。

二、四次挥手详解

问题：为什么需要四次挥手？能否合并为三次？

Client Server FIN=1, seq=u (我要关闭-第一次挥手) ACK=1, ack=u+1 (知道了-第二次挥手) FIN=1, seq=v, ack=u+1 (我也要关闭-第三次挥手) ACK=1, ack=v+1 (好的,关闭完成-第四次挥手) Client Server

为什么需要四次挥手？

半关闭状态（Half-Close）：

• TCP允许单向关闭。当客户端发送FIN后，服务端可能仍有数据需要发送（如服务器未响应的剩余HTTP数据）。
• 第二次挥手（ACK）仅确认收到FIN，不表示服务端立即关闭。

数据完整性保证：

• 服务端在第三次挥手（FIN）前会确保所有数据已发送完毕。
• 若合并第二次和第三次挥手，可能导致数据丢失。

能否合并为三次挥手？

可以，但有限制：
当服务端没有待发数据时，其第二次挥手（ACK）和第三次挥手（FIN）可合并为一个报文（称为延迟确认）。

Client Server FIN ACK+FIN (合并报文) ACK Client Server