三次握手与连接建立

为什么需要握手

TCP 是面向连接的协议，通信前必须确认三件事：

为什么是三次而非两次？ 两次握手存在"历史失效连接"问题：客户端发送的 SYN 因网络延迟长期滞留，待客户端已放弃后该 SYN 到达服务端，服务端会错误建立连接并分配资源，而客户端对此毫不知情，导致服务端维护大量无效连接。

客户端发送：

SYN=1, Seq=ISN_c（客户端初始序列号）
Flags: 0x002 (SYN)
选项: MSS, Window Scale, SACK Permitted, Timestamp...

客户端进入 SYN_SENT 状态。

服务端回复：

SYN=1, ACK=1
Seq=ISN_s（服务端初始序列号）
Ack=ISN_c + 1（期望收到客户端的下一个字节）
Flags: 0x012 (SYN+ACK)
选项: MSS, Window Scale, SACK Permitted, Timestamp...

服务端进入 SYN_RCVD 状态。

客户端发送：

ACK=1
Seq=ISN_c + 1（SYN 消耗了一个序列号）
Ack=ISN_s + 1（期望收到服务端的下一个字节）
Flags: 0x010 (ACK)

客户端进入 ESTABLISHED 状态；服务端收到后也进入 ESTABLISHED。

关键细节：

攻击者伪造大量源 IP，向服务端发送 SYN，但不回复最后的 ACK：

服务端为每个 SYN-RCVD 状态的连接分配资源（TCB，Transmission Control Block），半连接队列（SYN Queue）满后，正常用户的 SYN 被拒绝。

服务端收到 SYN 后，不分配 TCB，而是计算一个 Cookie 放入 SYN-ACK 的序列号中：

Cookie = Hash(客户端IP, 客户端端口, 服务端IP, 服务端端口, 时间戳, 秘密密钥)

如果客户端是合法的，会回复 ACK（Ack = Cookie + 1），服务端验证 Cookie 有效后才分配 TCB。这样半连接队列不再受攻击影响。

Linux 开启 SYN Cookie：

sysctl net.ipv4.tcp_syncookies=1

正常三次握手需要 1 个 RTT 才能发送数据。TFO 允许在首次 SYN 中携带数据，减少 1 个 RTT：

TFO Cookie 由服务端在首次连接时生成，客户端缓存后复用。对 Web 短连接（如 REST API）性能提升显著。

Wireshark 抓包观察三次握手：
- 过滤 tcp.flags.syn==1 && tcp.flags.ack==0 找第一个 SYN
- 观察 ISN、Ack、选项协商

查看 Linux 半连接队列状态：

ss -tan | grep SYN-RECV | wc -l
cat /proc/net/sockstat | grep TCP