SYN Cookie是一种无状态握手校验机制，通过在内核协议栈中临时接管TCP握手的第二次握手逻辑，让服务器在SYN泛洪期间不分配任何资源即可完成连接校验，从而从根本上消除半连接队列被耗尽的风险。
作为Linux内核在网络层对抗SYN Flood最成熟的防护手段之一，SYN Cookie的生效逻辑并不复杂，但很多运维人员对它的理解停留在“开启syncookies=1就安全了”的层面，实际情况是，SYN Cookie的触发条件、生效时机以及防御边界都藏着不少细节，今天就用把SYN Cookie当做一个“守门员”的视角，把它的工作流程拆开揉碎讲清楚。
SYN Cookie防SYN泛洪攻击的基本原理是什么
要理解SYN Cookie，先看正常的TCP三次握手：客户端发SYN，服务器分配一块内存放进半连接队列（SYN Queue），回SYN+ACK，等待客户端的ACK，这个半连接队列有长度上限，当攻击者伪造海量IP地址发SYN但从不回ACK时，队列被占满，正常用户的SYN包直接被丢弃这就是SYN Flood的基本打法。
半连接队列的困境
服务器处理每个SYN包,需要为潜在连接分配传输控制块（TCB），包括接收缓冲区、发送缓冲区等内存资源，在四核8GB的典型云服务器配置下，千兆网卡每秒可收到数万个SYN包，一旦半连接队列满员，Linux内核默认策略是直接丢包，行业共识认为，绝大多数DDoS攻击中SYN Flood占比曾长期位居前列，这种攻击的精髓就是让服务器资源耗在“半途而废”的连接上。
无状态校验的破局思路
SYN Cookie的核心思想是：既然我没有资源追踪你，那我就在SYN+ACK包里塞一个“加密凭证”，这个凭证由源IP、源端口、目的IP、目的端口、时间戳和一个密钥共同计算得出，是一个32位整数，服务器收到客户端回传的ACK时，取出这个号码校验合法性，合法则真正创建连接，非法则直接丢弃。
举个例子,正常的握手流程是“登记-核对-放行”，启用SYN Cookie后变成“发卡-验票-放行”，服务器不再登记每一个SYN，而是计算出票据（Cookie）发出去，等客户端拿着票据回来才处理，这样一来，SYN泛洪期间服务器几乎零内存消耗，因为每个SYN包只需要计算一个哈希值然后丢掉，不维护任何状态。
系统自动触发还是手动开启？Linux服务器SYN Cookie防护配置
Linux内核从2.0.4版本开始内置SYN Cookie机制，但默认状态下不是随时开启的，内核参数
net.ipv4.tcp_syncookies有三个取值：0表示关闭，1表示仅当半连接队列溢出时开启，2表示无条件开启。
推荐配置路径
在/etc/sysctl.conf中加入以下配置：
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syn_retries = 2
net.ipv4.tcp_max_syn_backlog = 4096执行sysctl -p生效，这里把tcp_syncookies设为1而不是2，是因为让系统在队列刚满时才自动介入，避免极端场景下合法握手被Cookie机制误伤。
验证生产环境是否触发
内核触发SYN Cookie时会打印日志，查看方式：
dmesg | grep -i "SYN cookies"输出中出现Possible SYN flooding on port 80. Sending cookies.，说明此刻攻击确实发生了，且系统已经切换至Cookie模式，也可以通过ss -s查看当前半连接队列占有率，如果Send-Q持续大于Recv-Q，基本可以断定遭受了SYN类攻击。
SYN Cookie和SYN Proxy两种防护方式怎么选
高防IP、WAF、云清洗产品背后往往运行着SYN Proxy，这就引出一个选型问题：SYN Cookie和SYN Proxy有什么区别，自己搭服务器该用哪个？
工作位置的本质差异
SYN Cookie运行在真实服务器的内核协议栈内部，SYN Proxy则运行在流量转发路径上的中间设备（如负载均衡器、防火墙或专属防护设备）中，SYN Proxy的工作方式是：中间设备代替真实服务器完成三次握手，确认客户端是真实的，再与后端服务器建立连接，将两条连接拼接起来。
两者对比如下：
| 对比维度 | SYN Cookie | SYN Proxy |
|---|---|---|
| 部署位置 | 被保护服务器内核 | 网络链路中间设备 |
| 是否持有连接状态 | 否，无状态校验 | 是，持有完整连接状态 |
| 对合法用户的延迟影响 | 极小（毫秒级计算） | 额外一跳RTT（往返时延） |
| 防护强度 | 能保服务器不死 | 能过滤大部分攻击流量 |
| 适用场景 | 单机防护、中小规模攻击 | 大规模DDoS、大型集群 |
场景化的选择建议
如果是单台游戏服务器或业务API,且预算不买高防IP，开启SYN Cookie是最简单有效的方案零成本、无额外延迟、内核自带，如果业务本身就架在Nginx或LVS后面，利用前置负载均衡的SYN Proxy能力更为合理，因为攻击流量在到达真实服务器之前就被清洗掉了，后端连压力都感受不到。
深入拆解SYN Cookie的合成与校验
Linux内核中,syncookie.c文件实现了整个流程，Cookie的计算过程相当精妙，虽然我们不需要重写内核，但了解校验逻辑有助于排查问题。
Cookie的四位段结构
一个服务端发出的SYN+ACK包中，序号字段承载的就是Cookie值，这个32位数按位划分：
- 高24位：由四元组哈希、服务端密钥、时间戳按特定算法混合生成，这里的密钥是每次启动时随机生成的，因此攻击者无法提前离线计算出合法Cookie。
- 低8位：编码了服务端接收到SYN时自身的MSS（最大报文段大小）索引值，客户端在ACK包里回传该号时，服务器可以复原MSS参数。
超时机制与时间窗限制
Cookie中编码了精确到64秒粒度的分钟级时间戳，服务器收到ACK时，用当前时间反推校验，如果差值超过4分钟，直接判定失效，这带来一个副产品：SYN Cookie模式下，连接一旦建立就必须走完全部数据交互，没有重传半开连接的机制，因为服务器根本没存SYN信息，客户端丢了ACK就整个重来。
换句话说,SYN Cookie保证了在面对恶意SYN风暴时系统不宕机，但也要接受极端拥塞时可能出现少量正常握手失败的现实。
实战中SYN Cookie能防多大流量？边界与局限
开启SYN Cookie之后是不是就高枕无忧了？远非如此，它的设计目标只是保住内核协议栈不被拖垮，但攻击流量本身照样耗费带宽、CPU和网卡中断资源。
CPU消耗的隐忧
计算每个SYN的Cookie值需要两次MD5级别的散列运算,在百万级PPS（每秒数据包数）的攻击下，多核CPU也吃不消，尤其命中攻击的网卡会把所有中断都抛给同一个CPU核心也就是网卡队列绑定的那个核，出现单核100%而其余核心空闲的典型现象。
应对思路之「前置吸收」策略
实践经验是：SYN Cookie适合作为纵深防御的最后一环，而前置防护还是要靠流量清洗，接入BGP高防IP，云厂商的DDoS清洗中心会先把攻击流量引流走，源站开启SYN Cookie做兜底，对于预算有限的小团队，可以购买按量付费的云高防服务，日常无攻击不收费，攻击时才计费。
应用层业务的配合调整
个别高交互场景中,客户端与服务端的RTT（往返时延）较大时，开启SYN Cookie会导致握手成功率下降，比如一个在欧美部署应用的电商站，国内用户平均RTT达到200ms以上，需要把tcp_max_syn_backlog适当调大、配合tcp_syncookies=1自动触发模式，而非强制开启。
结论与操作复盘
SYN Cookie的生效逻辑本质上是用CPU算力换内存资源，在攻击发生时自动切换至无状态校验模式，让服务器在攻击下保持可用，单独用它做不到拦截所有攻击流量，但作为内核级最后防线，它能保证攻击期间正常业务不中断。
下面把本次要点整理成一份快速回顾列表：
- 系统默认
tcp_syncookies=1，半连接队列溢出时自动触发，日常不影响正常握手。 - 触发后每个SYN包仅做一次哈希计算,不分配任何内存资源。
- 攻击停止后内核自动恢复全状态连接管理,无需人工干预。
- 生产环境务必配套调优
tcp_max_syn_backlog和tcp_synack_retries提升抗压上限。 - 大规模攻击场景下,SYN Cookie需要与云清洗、SYN Proxy配合使用。
常见问题速览：SYN Cookie相关的三个高频疑问
开启SYN Cookie后正常用户访问会变慢吗？
不会,只有当半连接队列溢出时，系统才进入Cookie模式，正常请求在队列未满时走标准三次握手路径，响应速度不受影响，攻击期间，合法用户会有一个额外的ACK校验过程，这个校验是纯计算操作，耗时在微秒级，远小于网络传输本身的毫秒级时延。
服务器如何判断SYN Cookie是否生效？
查看系统日志中是否出现Possible SYN flooding on port 80. Sending cookies.字样，或者运行nstat -az | grep Syncookies查看SyncookiesSent和SyncookiesRecv两个计数器的增量，两个计数器持续增长，说明系统正在持续的SYN Flood攻击中以Cookie模式正常运转。
内核日志显示syn flooding但业务为何没有中断？
多数情况下这正是SYN Cookie发挥作用的结果，攻击被隔离在网络层握手阶段，应用进程无需感知攻击的存在，连接请求仍然按正常速率完成，即便持续攻击数小时，业务请求成功率依然可以维持在99%以上，代价仅是CPU的少量额外开销。