SYN Flood攻击之所以能让服务器“一打就瘫”，根源在于半连接队列容量有限：攻击者用大量伪造源地址的SYN包把队列塞满后，正常用户的第三次握手ACK根本排不上队，新连接自然全部超时。 下面从TCP握手机制讲起，把成因、排查和解决方案一次说清。
半连接队列是TCP握手的“前台等候区”
TCP三次握手的过程，就像客人拜访一座办公楼，客户端发送SYN包，等于客人按了门铃，服务器收到后回复SYN-ACK，相当于前台开门，让客人先到等候区坐下，同时把客人的来访信息登记在册，客户端最后回复ACK，客人才真正进入办公区，这个“等候区”就是半连接队列,也叫SYN队列。
- net.ipv4.tcp_max_syn_backlog：内核允许的半连接条目上限。
- net.core.somaxconn：应用层listen时backlog的上限,实际取两者较小值。
- net.ipv4.tcp_synack_retries：SYN-ACK重试次数,直接影响条目滞留时间。
- net.ipv4.tcp_syncookies：是否启用SYN Cookie,默认在部分系统上开启。
半连接队列的容量默认值通常只有几百到几千条，每个SYN包进来后，条目会一直占位，直到收到ACK或者重试超时，如果重试次数设得较高，单个条目能滞留接近1-2分钟，这种设计在正常网络下够用，但遇到故意不完成握手的流量,队列就会迅速耗尽。
SYN Flood攻击如何导致服务器半连接队列占满
SYN Flood的成因链条非常直接，攻击者不指望完成握手，只做一件事：疯狂发送源IP伪造的SYN包。
- 攻击者用工具批量发送伪造源IP的SYN包,源地址往往是随机或不存在的。
- 服务器收到每个SYN包，都会分配一个半连接条目，并回复SYN-ACK到伪造地址。
- 伪造地址不会回应,条目只能等待超时。
- 重传机制让等待时间被拉长,条目进一步堆积。
- 半连接队列被占满,新的正常SYN包被直接丢弃。
行业共识认为，SYN Flood是最难防御的DDoS类型之一，因为它利用的是TCP协议设计上的信任特性服务器默认客户端会完成握手，攻击成本极低，一个SYN包只有几十字节，却能消耗服务器一个半连接条目，当队列满了之后，网站表现为新用户打不开页面、SSH连接超时、小程序接口无响应，已经建立的连接往往不受影响，因为老连接走的是已完成队列，不占半连接资源，这就是为什么有时候运维看到“网站部分用户正常，新用户进不来”的典型现象。
半连接队列满了网站打不开怎么解决？下一节直接给可执行路径。
半连接队列满了网站打不开怎么解决？从参数到内核的实操路径
临时恢复优先级最高，先解决“能不能访问”，再考虑“防不防得住”,下面按操作顺序列出。
第一步：开启SYN Cookie
SYN Cookie在半连接队列满时，不回绝新SYN，而是用加密算法把连接信息编码进SYN-ACK的序列号里，客户端回ACK时，服务器校验序列号合法性，通过就直接建立连接,不占用半连接条目。
sysctl -w net.ipv4.tcp_syncookies=1
这条命令几秒内生效,多数情况下能马上缓解服务不可用。
第二步：临时扩容并降低重传次数
sysctl -w net.ipv4.tcp_max_syn_backlog=4096 sysctl -w net.core.somaxconn=4096 sysctl -w net.ipv4.tcp_synack_retries=2
应用侧listen的backlog参数也要同步调大，降低重传次数能让半连接条目更快释放，减少占位时间，完整配置写入/etc/sysctl.conf并执行sysctl -p持久化。
第三步：用iptables限制SYN速率
iptables -A INPUT -p tcp --syn -m limit --limit 50/s --limit-burst 100 -j ACCEPT iptables -A INPUT -p tcp --syn -j DROP
命令把全局SYN速率限制在每秒50个，突发100个，超出直接丢弃,对于小型网站足够应急。
方案对比
| 措施 | 作用速度 | 对业务影响 | 抗攻击上限 |
|---|---|---|---|
| 开启SYN Cookie | 极快 | 小，可能丢失部分TCP选项 | 中 |
| 增大backlog | 快 | 无 | 低，只能延缓打满 |
| 降低重传次数 | 快 | 小 | 低 |
| iptables限速 | 快 | 可能误伤突发流量 | 中 |
防SYN Flood攻击的几种方案对比：内核参数、SYN Cookie、高防IP
内核参数调优属于“应急止血”，但攻击流量足够大时，本机修改参数依然扛不住,需要把防线外移。
内核参数与SYN Cookie
- 优点：零成本，部署快,几秒钟生效。
- 缺点：SYN Cookie会丢弃窗口缩放、SACK等TCP选项，大文件传输场景下吞吐可能下降；单纯增大队列只是延缓打满时间。
专业防火墙与高防IP
高防IP把攻击流量先引到清洗中心，过滤后再回源，北京服务器防SYN Flood攻击配置通常会把域名解析到高防IP，源站只允许高防回源IP访问,这样半连接队列的压力从源站转移到了清洗节点。
- 优点：防护能力强，能抗大流量攻击,不占用源站性能。
- 缺点：有带宽成本，延迟略有增加,回源规则配置较复杂。
高防IP价格一般多少
高防IP价格一般从几百元到数千元每月不等，具体取决于防护峰值、业务带宽和地域，华北、华东主要城市的BGP高防资源通常比单线机房贵一些，基础套餐大多覆盖20G到50G的攻击流量，更高防护需要定制，对于日均访问量不大的企业站，基础套餐足够；金融、游戏类业务则需要百G以上防护。
方案横向对比
| 方案 | 部署难度 | 防护能力 | 成本区间 | 适用场景 |
|---|---|---|---|---|
| 内核参数调优 | 低 | 防小流量 | 零成本 | 个人站、小企业应急 |
| SYN Cookie | 低 | 防中流量 | 零成本 | 突发攻击临时缓解 |
| iptables限速 | 中 | 防中小流量 | 零成本 | 小型API服务 |
| 高防IP | 中高 | 防大流量 | 几百到数千元/月 | 商业网站、游戏、金融 |
从监控到响应：半连接队列被打满后的排查步骤
半连接队列被打满时，不能只靠猜,下面给出可验证的排查命令和路径。
查看队列溢出迹象
netstat -s | grep -i syn
重点看SYNs to LISTEN sockets dropped、syncookies sent等计数，计数快速增长说明有SYN Flood。
ss -lnt
看监听端口的
Send-Q和Recv-Q，半连接队列满时，部分系统会显示Recv-Q长期接近上限。
抓包确认攻击特征
tcpdump -nn -i eth0 'tcp[tcpflags] & tcp-syn != 0'
观察SYN包源地址是否大量随机、是否针对固定端口，如果源地址来自同一网段或同一地域，可以临时封禁，如果是分布式伪造源,封禁意义不大。
内核日志
dmesg | grep -i syn
部分系统会输出possible SYN flooding on port 80日志,这是半连接队列溢出的直接证据。
快速止损动作
- 执行
sysctl -w net.ipv4.tcp_syncookies=1。 - 按业务承受能力限制SYN速率。
- 若攻击源IP集中在某个地域,临时在边界设备丢弃该地域入站SYN包。
- 联系运营商或高防服务商做流量清洗。
TCP半连接队列被SYN Flood占满，本质上是攻击者利用了服务器对未完成握手的过度信任，修复思路从来不是单纯把队列调到无限大，而是让队列要么不轻易满，要么满了也不影响正常握手，SYN Cookie是最直接的兜底机制，高防IP则把压力顶在更前一层，两条路结合,才能让服务在攻击期间保持可用。
Q&A：SYN Flood半连接队列被占满后服务不可用相关疑问
SYN Flood半连接队列被占满后服务不可用会持续多久？
取决于攻击持续时间和清理速度，攻击停止后，滞留的半连接条目会按各自超时时间逐步失效，通常几秒到几分钟内恢复，如果攻击持续且没有清洗措施，服务会一直不可用,直到队列被释放出空间。
半连接队列满了网站打不开怎么解决最快？
最快执行三条命令：sysctl -w net.ipv4.tcp_syncookies=1开启SYN Cookie；sysctl -w net.ipv4.tcp_synack_retries=2降低重传次数；配合iptables限制SYN速率，几秒内生效,能迅速恢复新连接的接入能力。
SYN Cookie和增大半连接队列哪种更有效？
增大半连接队列只能延缓被占满的时间，攻击流量超过新容量后依然会耗尽，SYN Cookie在队列满时用加密验证绕过半连接资源，对SYN Flood的防护更彻底，但SYN Cookie会丢弃部分TCP选项,高并发大文件传输场景需要结合高防IP或专业防火墙一起使用。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/637479.html
