SYN Cookies 是什么？它如何缓解 SYN Flood 攻击？

简化版

SYN Flood 会发送大量 SYN 占满服务器半连接队列，使正常连接无法建立。SYN Cookies 的思路是：服务器收到 SYN 时不立即为连接保存完整状态，而是把必要信息编码进 SYN+ACK 的初始序列号里；客户端回 ACK 后，服务器再验证这个 cookie 并创建连接。它能缓解半连接队列被打满，但可能限制部分 TCP 选项能力。

详细版

正常三次握手中，服务器收到 SYN 后会创建半连接状态。攻击者伪造大量源地址只发 SYN 不回 ACK，就会消耗半连接队列。

Client -> SYN
Server -> SYN+ACK，其中 ISN 编码 cookie
Client -> ACK，ack number 带回 cookie + 1
Server 验证成功后再分配连接状态

SYN Cookies 是一种降级防护，不是完整替代所有抗 DDoS 手段。大流量攻击仍需限流、清洗、负载均衡和内核参数配合。

完整版教学

一、SYN Flood 攻击打在哪里

TCP 三次握手时，服务器收到 SYN 后会进入 SYN_RECV，并在半连接队列中记录状态。

SYN 到达
服务器分配半连接状态
回复 SYN+ACK
等待最终 ACK

攻击者如果不断发 SYN，却不完成第三次 ACK，就会让半连接队列被占满。

二、SYN Cookies 的核心思想

核心是“先不存状态，把状态编码到序列号里”。服务器回复 SYN+ACK 时，把时间、MSS 等信息通过哈希编码进初始序列号。

阶段	普通握手	SYN Cookies
收到 SYN	保存半连接状态	尽量不保存状态
回复 SYN+ACK	使用普通 ISN	ISN 中编码 cookie
收到 ACK	查半连接	验证 cookie 后建连接

关键点：SYN Cookies 把服务器状态转移到客户端必须带回的 ACK 中，降低半连接队列压力。

TCP 规则要求客户端确认服务器的 SYN：

Server SYN Seq = x
Client ACK = x + 1

如果 x 中编码了 cookie，最终 ACK 里的确认号就能让服务器恢复并验证这段信息。

四、它解决了什么问题

SYN Cookies 主要解决“半连接状态消耗”问题。攻击流量来了，服务器不为每个 SYN 都保存状态，队列不容易被伪造请求拖死。

但它不能让带宽凭空变大。如果攻击流量已经打满链路，仍然需要上游清洗和流量调度。

五、它有什么代价

因为初始序列号空间有限，能编码的信息也有限。某些 TCP 选项可能无法完整保存或协商，具体取决于内核实现。

可缓解 SYN 队列压力
可能限制部分 TCP options
不能替代上游 DDoS 防护

所以它通常作为高压下的保护机制，而不是唯一防线。

六、和 backlog 调参的关系

增大半连接队列、调重试次数、开启 SYN Cookies 都能改善连接建立阶段的抗压能力。

backlog：增加队列容量
SYN Cookies：减少未完成握手状态占用
限流/清洗：减少恶意流量进入

线上排查时要结合队列溢出、SYN_RECV 数量、连接建立失败率一起看。

七、常见误区与追问

误区：SYN Cookies 可以防住所有 DDoS。 它主要缓解半连接队列耗尽，不能解决链路被打满。
误区：开启后完全没有代价。 序列号编码空间有限，部分 TCP 选项可能受限。
误区：SYN Flood 消耗的是全连接队列。 主要目标是握手未完成的半连接状态。
追问：cookie 放在哪里？ 编码在服务器 SYN+ACK 的初始序列号中。
追问：服务器什么时候真正建连接状态？ 收到客户端 ACK 并验证 cookie 后。
追问：还需要哪些配套措施？ backlog 调整、限流、黑白名单、DDoS 清洗和负载均衡。

八、加强记忆

SYN Cookies 的一句核心是：收到 SYN 先不存状态，把验证信息塞进服务端 ISN，等客户端 ACK 带回来再建连接。它是半连接队列防护手段，不是万能 DDoS 护盾。

简化版

详细版