“三次握手”经常被记成固定口诀，却容易漏掉它真正建立的共识：通信双方都确认了对方的发送与接收能力，并同步了本次连接使用的初始序列号。
三个报文分别确认什么
客户端首先发送带有初始序列号 x 的 SYN。服务端收到后，知道客户端到服务端的方向可达；它返回 SYN-ACK，同时确认 x + 1 并公布自己的初始序列号 y。客户端最后发送 ACK，确认 y + 1。
Client Server
| -------- SYN, seq=x -------> |
| <--- SYN-ACK, seq=y, ack=x+1 |
| -------- ACK, ack=y+1 ------> |
完成后，双方都持有对方序列号的确认。之后的数据字节便能依靠序列号排序、重传和去重。
为什么两次不够
如果服务端发送 SYN-ACK 后就直接认定连接建立，它还不知道客户端是否真正收到了自己的序列号。网络中延迟很久的旧 SYN 也可能突然到达，令服务端为一个客户端并不期待的连接分配状态。
第三次 ACK 给服务端一个关键证据：客户端收到了本次服务端选择的序列号，并愿意继续这条连接。它不能消除所有拒绝服务风险，却让连接状态建立在双向确认之上。
序列号为什么重要
IP 只负责尽力传递数据包，不保证到达顺序，也不保证不重复。TCP 把应用数据视为连续字节流，用序列号标记位置。初始序列号必须在连接开始时交换，否则双方无法正确解释后续 ACK 所确认的数据范围。
序列号也帮助区分不同时间出现的连接实例，降低旧报文被误认为当前连接数据的可能性。
与端口扫描的关系
最基础的 TCP connect 扫描会尝试完成这套握手。连接成功意味着目标端口当时接受了 TCP 建连；收到 RST 通常表示端口关闭；没有及时响应则可能是过滤、丢包、目标不可达或单纯延迟。
因此，“超时”不是一种精确服务状态。扫描工具应避免把所有非成功结果都解释为关闭。
握手没有保证什么
握手成功不保证应用服务健康，也不提供机密性或身份认证。TLS 会在 TCP 连接之上继续协商加密与身份；HTTP、SSH 等应用协议也要在连接建立后才开始交换自己的消息。
三次握手解决的是运输层的连接共识，而不是整个网络安全问题。把层次分清，许多端口、超时和连接状态的现象就会更容易解释。