2026/7/23大约 3 分钟
TCP 的三次握手（Three-way Handshake）是建立可靠连接的关键过程。它的核心目的不仅是确认对方“在不在”，更重要的是同步双方的序列号（ISN）并确认双方的收发能力均正常。
我们可以把这个过程类比为两个人通过对讲机通话前的测试。
1. 三次握手的详细过程
第一步：客户端发送请求 (SYN)
- 动作：客户端（Client）向服务端（Server）发送一个 SYN（Synchronize）报文段。
- 关键参数：设置标志位
SYN=1，并随机生成一个初始序列号seq=x。 - 状态：客户端进入
SYN-SENT（同步已发送）状态。 - 含义：“你好，我想和你建立连接，这是我的初始序列号 x。”
第二步：服务端确认并回放 (SYN + ACK)
- 动作：服务端收到后，如果同意连接，则回复一个 SYN+ACK 报文段。
- 关键参数：设置
SYN=1，ACK=1。同时生成自己的序列号seq=y，并将确认号设置为ack=x+1（表示收到了客户端的 x）。 - 状态：服务端进入
SYN-RCVD（同步已收到）状态。 - 含义：“收到！我同意连接。这是我的序列号 y，我也确认收到了你的 x。你能听到我说话吗？”
第三步：客户端最终确认 (ACK)
- 动作：客户端收到服务端的回复后，再发送一个 ACK 报文段。
- 关键参数：设置
ACK=1，确认号ack=y+1，自己的序列号变为seq=x+1。 - 状态：客户端发送后立即进入
ESTABLISHED（已建立连接）状态，服务端收到后也进入该状态。 - 含义：“听到了！我也确认收到了你的 y。现在我们可以开始传数据了！”
2. 为什么要“三次”？两次不行吗？
这是面试中最经典的问题。答案主要有两点：
- 确认双向收发能力：
- 第一次：服务端确认了“客户端发能力正常”和“自己收能力正常”。
- 第二次：客户端确认了“服务端收、发能力正常”和“自己收、发能力正常”。
- 第三次：服务端通过客户端的回应，最终确认了“客户端收能力正常”。
如果只有两次，服务端无法确定客户端是否收到了自己的回馈，此时建立连接是单向且不可靠的。
- 防止旧的连接请求突然到达（致命原因）：
假设客户端发出的第一个 SYN 包在网络中“迷路”了（延迟）。客户端等不及了又发了第二个 SYN 并完成了通信。等通信结束后，那个迷路的第一个 SYN 突然传到了服务端。
- 如果是两次握手：服务端会直接建立连接并干等，造成资源浪费。
- 如果是三次握手：服务端回发 SYN+ACK，但客户端知道这是一个过时的请求，于是拒绝回应（发送 RST），连接就不会建立。
3. 三次握手期间的常见攻击：SYN Flood
攻击者伪造大量的 IP 地址向服务器发送 SYN 包，但从不进行第三次 ACK 确认。这会导致服务器的半连接队列（SYN Queue）被占满，导致正常用户无法连接。
应对方案：通常使用 SYN Cookie 技术，在不分配资源的情况下回发包，只有等到合法的第三次 ACK 到达时才真正分配内存。