网站首页 > 教程文章正文

说说 TCP 的三次握手_分析tcp的三次握手

jxf315 2025-08-21 03:30:10 教程文章 2 ℃

一句话总结

三次握手=“我能发→你能收→我知道你能收”，两次握手保证不了双方都确认通路可用，而四次又可把“确认 + 发起”合并成一次包，因此恰好三次最经济；若任意报文丢失或主机发完 SYN 就宕机，TCP 都靠 超时重传 + 半开连接清理 机制自动收场。

1. 三次握手流程回顾

2. 为什么必须“三次”——两次 / 四次都不行？

场景	说明
两次握手	(1)C→S:SYN (2)S→C:SYN+ACK o C 已确认 S 收到自己的 SYN，但 S 无法确认 C 是否收到 SYN+ACK o 若(2)丢失，S 误以为连接已建，后续发送的数据会打水漂，造成资源浪费与“假连接”。
三次握手	第 3 包 ACK 让 S 确认“自己的 SYN+ACK 已被 C 收到”，至此双向通信能力得到验证。
四次握手	可把第 2 步拆成 “ACK（确认对方）” + “SYN（自己发起）”，但 TCP 把两包合并为一包 SYN\|ACK，节省 RTT，没有必要多一步。

结论：三次 = 两端各自确认一次 + ACK/SYN 合包，既可靠又高效。

3. 若握手报文丢失，会发生什么？

丢失的报文	状态变化 & 补救	结果
① 客户端 SYN	C 超时重传 SYN；S 无感知	连接延迟增加
② 服务器 SYN + ACK	C 等不到响应，重传 SYN；S 收到重复 SYN，再发 SYN+ACK	连接延迟增加；S 重传次数受tcp_synack_retries控制
③ 客户端最后 ACK	S 仍处SYN_RCVD，超时重发 SYN+ACK； C 已ESTABLISHED，收到后再发 ACK	最终成功；若 C 不回 ACK，S 会重传数次后丢弃半开

4. 如果主机在发送完 SYN 后宕机（半开连接）怎么办？

场景C：SYN发出 → 宕机 / 掉线S：进入SYN_RCVD，占用 backlog
服务器处理按 RTO 指数退避重发 SYN+ACK，尝试tcp_synack_retries（默认 5）次仍无 ACK → 把该条目从队列移除，资源自动释放
进一步防护SYN Cookies：backlog 满时不保存状态，只在 ACK 中反推校验，抵御 SYN Floodtcp_abort_on_overflow=1：队列溢出立刻RST，避免死占端口
客户端恢复上线的情况因未持久化 SEQ，重连时会带新 ISN，旧握手在服务器侧最终超时作废，不冲突。