net.ipv4.tcp_max_tw_buckets是time_wait socket的全局硬上限，达限时内核静默丢弃新syn包；它不防御syn flood，因后者压垮的是半连接队列，需同步调优tcp_syncookies、tcp_max_syn_backlog和somaxconn。
net.ipv4.tcp_max_tw_buckets 不是“TCP最大等待数”，它专指系统允许同时存在的 TIME_WAIT socket 数量上限；而 SYN 洪水防御的核心参数是 tcp_syncookies、tcp_max_syn_backlog 和 somaxconn。二者作用对象、触发时机、错误表现完全不同，混用会导致调优失效甚至服务不可达。
为什么改了 tcp_max_tw_buckets 却挡不住 SYN Flood
因为 tcp_max_tw_buckets 管的是连接关闭后的残留状态，而 SYN Flood 攻击压垮的是尚未完成三次握手的半连接队列（SYN Queue）。两者在内核中完全隔离：
- 当攻击流量涌入，
tcp_max_syn_backlog溢出 → 内核静默丢弃新 SYN 包 → 客户端超时重传或直接失败 - 此时
tcp_max_tw_buckets可能还空着 90%，根本不会被触发 - 反过来，若只调大
tcp_max_tw_buckets却不碰tcp_max_syn_backlog，SYN 队列几秒就满，连建立连接的机会都没有，TIME_WAIT根本没机会产生
真正该调的三个 SYN 防御参数
必须同步调整以下三项，缺一不可：
-
net.ipv4.tcp_syncookies = 1：启用后，队列满时不再丢包，而是用加密序列号“赊账”发 SYN+ACK，收到 ACK 才分配内存。这是保命机制，不是可选项 -
net.ipv4.tcp_max_syn_backlog = 65535：半连接队列容量。默认常为 128 或 1024，高并发下 1 秒就满。设为 65535 是生产常用值，但需确认应用未硬编码小listen()backlog -
net.core.somaxconn = 65535：全连接队列上限。若此值小于应用listen(fd, 1024)的参数，内核会默默截断——哪怕tcp_max_syn_backlog再大也白搭
改完必须执行 sysctl -p，且多数服务（如 Nginx）需重载配置或重启才能感知新 somaxconn 值。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
tcp_synack_retries 要设成 2 还是 3
该参数控制服务端重发 SYN+ACK 的次数，默认 5 次，最长等待约 31 秒。攻击者伪造 IP 根本不会回 ACK，这 31 秒纯属浪费队列条目：
- 设为
3→ 最长等待约 3 秒，平衡兼容性与释放速度，适合大多数场景 - 设为
2→ 最长等待约 1.5 秒，对高延迟网络（如跨洋、卫星链路）可能误杀合法连接 - 不要设为
0或1：会导致极低概率下正常客户端因丢包收不到 SYN+ACK，连接直接失败
配套建议：把 net.ipv4.tcp_syn_retries（客户端侧）保持默认或设为 3，便于通过客户端日志判断是否遭遇攻击而非网络问题。
iptables 规则必须放在 conntrack 后面才有效
很多文档写的 iptables -A INPUT -p tcp --syn -m limit --limit 10/sec -j ACCEPT 看似合理，但若系统启用了 nf_conntrack，且规则顺序不对，就会出现“限速没生效”的假象：
- conntrack 模块会在 netfilter 的 PREROUTING 链早期建立连接跟踪，SYN 包可能已被标记为 INVALID 或 ESTABLISHED，绕过后续 limit 规则
- 正确做法：在 raw 表中提前处理，或确保所有限速规则位于
CONNTRACK相关模块加载之后，并使用-m state --state NEW显式匹配新建连接 - 更稳妥的写法：
iptables -A INPUT -p tcp --syn -m connlimit --connlimit-above 50 -j DROP，它依赖连接跟踪状态，与 conntrack 天然协同
最容易被忽略的一点：所有 iptables 规则在重启后丢失，必须用 iptables-save > /etc/iptables/rules.v4（Debian/Ubuntu）或 service iptables save（CentOS）持久化，否则半夜攻击来了，规则早没了。
