SYN Flood 的原理与缓解手段

TCP 建立连接要经历三次握手：客户端发 SYN，服务端回 SYN-ACK，客户端再回 ACK。SYN Flood 的思路很直接——海量伪造的 SYN 包涌向服务端，却不完成最后一步，让服务端的半连接队列被占满。 正常情况下，半连接队列容纳"握手进行中"的连接，等第三个包到达后转为正式连接。攻击发生时，队列里塞满永远等不到回应的假连接，真实用户的握手请求被拒之门外。表现出来就是网站打不开、SSH 连不上，而 CPU 和带宽看起来并不忙——这也是很多人误判成"程序卡死"的原因。 缓解可以先从内核参数入手。开启 syncookies 之后，服务端不再依赖队列，而是把连接信息编码进 SYN-ACK 的序列号里，收到合法的 ACK 再重建连接： sysctl -w net.ipv4.tcp_syncookies=1 sysctl -w net.ipv4.tcp_max_syn_backlog=4096 sysctl -w net.ipv4.tcp_synack_retries=2 第一行启用 syncookies，第二行调大半连接队列容量，第三行减少 SYN-ACK 的重试次数，让假连接更快释放。要让参数重启后仍生效，需写入 /etc/sysctl.conf。这组调整能扛住中小规模的攻击，属于每个运维都该做的默认项。改完之后再跑一次 ss -n state syn-recv 观察，半连接数量明显回落说明措施起效；若数值仍然居高不下，说明攻击量级已经超出单机应对范围，直接进入上游清洗环节。 攻击量级上去之后，单机参数就不够用了，因为伪造流量可能在到达服务器之前，就把机房入口的带宽占满，数据包根本轮不到内核来处理。这时需要上游清洗：服务商把目标流量牵引到清洗中心，滤掉伪造包之后把干净流量回注到源站。高防云服务器提供的正是这种能力，例如 S2 标配 60G 防御、国内 BGP 多线接入，攻击流量在清洗环节就被处理掉。 参数调优解决小规模的骚扰，专业清洗应对大规模冲击，两者配合才是完整答案。日常把参数配好，攻击真来时再谈清洗，顺序不能反。拿不准自己遇到的是哪一档，把连接状态截图交给服务商看一眼再决定，比自己试错快。