服务器遭遇SYN Flood时，攻击者用海量伪造源地址的SYN包在几秒到几十秒内把TCP半连接队列填满，正常用户的新连接请求被内核直接丢弃，表现为网站无法打开或端口连接超时。
高并发Web服务器被SYN Flood攻击时，连接表怎么被塞满？
服务器对外提供Web服务时,内核会为每个新连接维护状态，SYN Flood专门攻击TCP握手的第一阶段，让服务器把资源消耗在大量“半成品”连接上，连接表被迅速占满，不是带宽不够，而是内核里那张固定的半连接表被塞爆了。
TCP握手第一步就被“卡住”：半连接队列是什么？
TCP建立连接需要三次握手,客户端先发SYN包，服务器收到后回复SYN-ACK，同时把这条连接放进半连接队列，此时连接还没建立完成，服务器需要等客户端回ACK，如果ACK不来，这条记录会一直占用队列，直到超时释放。
- 半连接队列大小由
net.ipv4.tcp_max_syn_backlog和net.core.somaxconn共同决定。 - 队列写满后,新的SYN包默认会被内核直接丢弃。
- 正常高并发下队列也可能满,但SYN Flood让它从“偶尔满”变成“持续满载”。
攻击包像洪水一样冲进来：从第一个SYN到队列爆掉
SYN Flood的攻击逻辑非常简单，但效果极快。
- 攻击者操控大量肉鸡,向目标服务器80或443端口发送SYN包。
- 源IP被随机伪造,有些根本不存在，有些属于不回应SYN-ACK的主机。
- 服务器每收到一个SYN,就创建一个半连接条目，并回复SYN-ACK。
- 由于源端不会回ACK,这些半连接条目一直占用，直到超时。
- 当攻击速率超过条目释放速率,队列占用持续上升。
- 几秒到几十秒后,半连接队列接近满载，后续SYN被直接丢弃。
运维人员可以在排查时执行：
watch -n1 'netstat -ant | grep SYN_RECV | wc -l'
如果SYN_RECV数量接近tcp_max_syn_backlog，说明半连接队列已经被塞满。
正常用户视角：连接表满了以后会发生什么？
正常用户访问网站时,同样要从SYN开始，服务器半连接队列已满，内核默认会丢弃这个SYN包。
- 用户浏览器表现为转圈、连接超时、ERR_CONNECTION_TIMED_OUT。
- 部分用户可能偶尔能打开,因为队列会随超时释放少量空位。
- 已经建立的长连接可能暂时不受影响,但新的Web请求会大量失败。
- 这种“一会能上一会不能上”的现象，多数情况下不是服务器宕机，而是半连接队列在超时与攻击之间反复腾挪。
SYN Flood和CC攻击哪个危害大？对比连接表耗尽与资源耗尽
很多运维人员分不清SYN Flood和CC攻击，两者的破坏路径完全不同。
SYN Flood吃的不是带宽，是连接表
SYN Flood的包非常小，可能只有几十字节，总流量不一定高，有些攻击甚至只有几十Mbps，但已经足够把半连接队列打满。
| 攻击类型 | 主要消耗资源 | 流量特征 | 服务器表现 | 常用防御 |
|---|---|---|---|---|
| SYN Flood | TCP半连接队列 | 包小，带宽占用不一定高 | 新连接超时，已建立连接可能正常 | SYN Cookie、高防清洗 |
| CC攻击 | 业务线程、CPU、数据库连接 | HTTP请求正常，但请求量大 | 页面变慢、502/503、CPU飙高 | 频率限制、WAF、验证码 |
CC攻击消耗的是业务线程和CPU，路径不同
CC攻击会先完成TCP握手,再发送大量HTTP请求，它不针对半连接队列，而是消耗Web服务器、应用进程和数据库连接，如果服务器只是半连接队列满、CPU和内存正常，基本可以优先怀疑SYN Flood。
服务器遭遇SYN Flood怎么防御？从内核参数到高防IP实操
防御SYN Flood不能只靠重启服务，重启反而会清空已建立的正常连接，正确做法是先调整内核参数，再根据攻击量级决定是否上高防。
先打开SYN Cookie：一条命令缓解半连接队列压力
Linux内核自带SYN Cookie机制，半连接队列满时，服务器不再为每个SYN分配存储，而是把连接信息编码进SYN-ACK的序列号，收到合法ACK后再还原连接。
sysctl -w net.ipv4.tcp_syncookies=1
永久生效：
echo "net.ipv4.tcp_syncookies=1" >> /etc/sysctl.conf sysctl -p
SYN Cookie会丢弃部分TCP选项，比如窗口缩放，高并发业务开启后性能会有一定损耗，但在攻击期间能明显缓解半连接队列压力。
调整半连接队列和重试次数，给正常请求留出空间
默认的半连接队列通常较小,重试次数也偏高，可以适当调大队列，缩短SYN-ACK重试时间。
sysctl -w net.ipv4.tcp_max_syn_backlog=8192 sysctl -w net.core.somaxconn=8192 sysctl -w net.ipv4.tcp_synack_retries=2
tcp_max_syn_backlog：提高半连接队列上限。somaxconn：提高应用层accept队列上限，需配合Nginx等应用的backlog参数。tcp_synack_retries：减少SYN-ACK重试次数，让无效半连接更快释放。
这些参数只能提高“容错空间”，不能根治大规模攻击，攻击速率远超队列容量时，仍需外部清洗。
北京服务器被SYN Flood攻击时，为什么建议接入高防服务？
北京机房带宽资源紧张,单台服务器能扛的攻击流量有限，SYN Flood一旦超过物理带宽出口，内核参数调得再好也没用，因为流量根本到不了服务器。
- 高防服务通过BGP牵引,把流量先引入清洗中心。
- 清洗中心识别并丢弃伪造SYN包,只把正常流量回注到源站。
- 北京地域的高防节点延迟相对较低,适合北方用户访问。
行业共识认为,单靠服务器内核参数无法对抗大规模SYN Flood，必须在网络边界进行清洗。
抗SYN Flood攻击服务费用一般多少？和自建防火墙的成本对比
抗SYN Flood攻击服务费用一般多少，主要看防护峰值和地域，高防IP通常按套餐计费，防护峰值越高，价格越高。
- 商业高防服务每月费用通常从几百元到数千元不等,具体取决于防护峰值、线路质量和清洗能力。
- 北京等高防节点由于带宽成本较高,价格可能略高于其他地域。
- 自建方案需要采购硬件防火墙、增加带宽、安排专人运维，初期投入较大，适合预算充足且攻击频率高的业务。
对于多数中小企业,先开启SYN Cookie和调大队列，再按需购买高防服务，是成本相对可控的路径。
连接表被迅速占满后，怎么确认是SYN Flood攻击？
三条命令快速判断
服务器连不上时,先别着急重启，用三条命令确认状态。
netstat -ant | awk '{print $6}' | sort | uniq -c | sort -nr
如果SYN_RECV数量特别高,说明大量连接停在半连接状态。
ss -s
查看synrecv计数是否异常偏高。
tcpdump -i eth0 -nn 'tcp[tcpflags] & tcp-syn != 0'
观察SYN包源IP是否随机分散,SYN Flood的源IP通常来自大量不同地址，而不是固定少数IP。
临时处理：不要急着重启服务器
服务器重启会清空半连接队列,也会断开所有已建立连接，正常业务可能因此全部中断。
- 先开启SYN Cookie，让内核进入抗半连接队列耗尽模式。
- 再调大
tcp_max_syn_backlog，给正常请求留出余量。 - 如果已经购买高防服务,立即联系服务商切换到清洗模式。
- 没有高防时,可通过iptables限制单IP新建连接频率，但伪造源IP攻击下效果有限。
SYN Flood的核心杀伤力在于用极小的包填满固定的半连接表，让服务器无法接受新连接，防御时要先开SYN Cookie、调内核参数，再根据攻击规模接入高防清洗，连接表被迅速占满时，不要盲目重启，先确认状态再分层处理，才能最大程度保住正常业务。
Q&A：服务器遭遇SYN Flood攻击常见问题
Q1：服务器遭遇SYN Flood攻击时连接表一般多久会被占满？
取决于攻击速率和半连接队列大小,攻击速率高时，几秒到几十秒就能把默认队列打满，低速率攻击可能需要几分钟，开启SYN Cookie后，队列不再成为主要瓶颈，攻击者就需要付出更大成本才能造成影响。
Q2：抗SYN Flood攻击服务费用一般多少？免费方案有没有用？
免费方案可以先开启SYN Cookie、调大tcp_max_syn_backlog、缩短tcp_synack_retries，这些能在小规模攻击下起到明显作用，商业高防服务通常按防护峰值和地域计费，每月从几百元到数千元不等，北京等一线城市节点价格可能略高，免费方案解决单机问题，高防服务解决带宽和清洗问题。
Q3：SYN Flood和CC攻击哪个危害大？资源有限先防哪个？
看业务表现,如果服务器频繁出现新连接超时、SYN_RECV状态堆积、已建立连接基本正常，优先处理SYN Flood，如果连接能建立，但页面变慢、CPU和数据库连接打满、出现502或503，优先处理CC攻击，两者常混合出现，需要分层防御。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/637472.html
