tcp_syncookies能零内存开销防syn flood，因其不为每个syn分配request_sock，而是将握手信息哈希进syn+ack序列号，仅合法ack才触发内存分配；需同步调大tcp_max_syn_backlog和somaxconn，并配合iptables限速与synack_retries调优。

启用 tcp_syncookies 是 Linux 内核应对 SYN-Flood 最核心的无状态防御机制，它不依赖额外内存分配来保存半连接状态，因此天然规避内存耗尽问题。

为什么 tcp_syncookies 能零内存开销防 SYN Flood

SYN Flood 的本质是填满服务端的「半连接队列」（SYN Queue），让合法连接无法入队。传统流程中，每个收到的 SYN 都需在内存中创建并维护一个 request_sock 结构体，直到完成三次握手或超时释放——攻击者正是利用这点大量伪造源 IP 占用内存。

tcp_syncookies 开启后，内核不再为每个 SYN 分配内存。它把关键握手信息（MSS、时间戳、SACK 支持等）加密哈希进 SYN+ACK 的初始序列号（即 cookie），发给客户端。只有当客户端返回正确的 ACK（确认号 = cookie + 1）时，内核才真正分配 socket 资源。伪造 IP 不会回 ACK，也就永远不会触发内存分配。

Zynq Linux Hardware Debug

Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。

下载

• 内核 ≥3.7 默认启用带时间戳的 SYN Cookies，tcp_timestamps 和 tcp_sack 不会被禁用（旧版可能受限，但当前主流发行版已无此问题）
• 设为 1 表示“检测到队列溢出时自动启用”，这是最稳妥模式；设为 2 强制始终启用，反而掩盖真实压力，不推荐
• 它和 tcp_tw_reuse 完全不冲突，但和 tcp_tw_recycle 无关——后者已在 4.12+ 内核中被彻底移除，配置即报错

必须同步调大的两个队列参数，否则 syncookies 压根不触发

很多人开了 tcp_syncookies=1 却仍被打挂，根本原因是：syncookies 只在 tcp_max_syn_backlog 或 somaxconn 真正溢出时才启动。如果这两个值太小（如默认 128 或 1024），攻击包在到达 syncookies 逻辑前就被内核静默丢弃了。

• net.ipv4.tcp_max_syn_backlog：控制半连接队列长度，建议设为 4096～65535，视并发压力调整
• net.core.somaxconn：控制全连接队列长度，必须 ≥ 应用 listen() 的 backlog 参数（如 Nginx 的 listen ... backlog=4096），生产环境统一设为 65535 更稳妥
• 改完后需重载服务（如 systemctl reload nginx），否则新值对监听进程无效

配合缩短重试等待，加速队列周转

tcp_synack_retries 决定服务器发完 SYN+ACK 后，最多重试几次才放弃。默认值 5 意味着最长等待约 63 秒（指数退避：1s, 3s, 7s, 15s, 31s）。攻击者就靠这个空窗期卡住队列条目。

• 设为 2 → 最长等待约 1.5 秒；设为 3 → 约 3 秒；效果显著，且不影响高延迟用户（三次握手本身不依赖重试）
• 不要设为 0：首次 SYN+ACK 发送失败即丢弃，某些云厂商 LB 或弱网路径下易导致建连失败
• tcp_syn_retries 是客户端参数，服务器上修改无意义，无需碰

iptables 做前置限速，减轻内核压力

syncookies 是兜底机制，iptables 是第一道过滤。目标不是封死所有高频 IP，而是拦截「只发 SYN、从不回 ACK」的异常行为，避免无效包进入 TCP 栈。

• 新建自定义链，规则放在 INPUT 靠前位置：
  iptables -N syn-flood
iptables -A INPUT -p tcp --syn -j syn-flood
iptables -A syn-flood -m limit --limit 50/s --limit-burst 10 -j RETURN
iptables -A syn-flood -j DROP
• --limit-burst 10 是信用池，允许突发；--limit 50/s 是长期速率，按业务正常峰值微调（API 服务可设为 20/s）
• 避免用 recent 模块封 IP：高并发下性能差，且 NAT 后用户易被误伤