为什么syn flood攻击会让服务器持续等待握手完成
SYN Flood攻击之所以让服务器持续等待，是因为攻击者只发出握手请求却不完成最后一次确认，服务器被迫在“半连接”状态中干等超时。这种等待并非网络延迟造成，而是TCP协议自身的信任机制被利用，为了理解这个过程，你需要清楚TCP三次握手就像一次三方的电话确认，每一次交互都有严格的先后顺序。当攻击者故意在第二步“装死”时，服务器会认为对方只是网络不好，于是不断重试并预留资源,直到资源耗尽。
TCP三次握手的正常流程与“半连接”状态
正常的TCP连接建立，类似两人“互相确认身份”的过程。第一次握手，客户端发送带有SYN标志的数据包，相当于说“您好，我想建立连接”。第二次握手，服务器收到后回复SYN-ACK包，相当于说“收到，我可以连接，你那边确认一下”。第三次握手，客户端再发送ACK包，此时双方正式建立连接,开始传输数据。
服务器在发出SYN-ACK包之后、收到ACK包之前，这个连接被称为“半连接”，它会被放入一个专门的半连接队列（SYN Queue），这个队列有长度上限，这是内核参数net.ipv4.tcp_max_syn_backlog决定的，在正常业务中，半连接存在几秒钟就会因为收到ACK而消失,队列几乎不会被占满。
攻击者如何让服务器“空等”到超时
SYN Flood攻击的核心，就是让服务器一直产生这种半连接，攻击者伪造大量不存在的IP地址，向服务器发送SYN包，服务器按照协议回应SYN-ACK包后，对方永远不会有ACK回应，此时服务器不知道对方是“假地址”，只能按照TCP重传机制，等待超时后再次发送SYN-ACK。
这个等待过程会持续多久？根据Linux内核默认设置，SYN-ACK重传次数通常为5次，总等待时间约为30秒到1分钟（具体数值取决于net.ipv4.tcp_synack_retries参数），在这段时间里，每个伪造连接都占着一个半连接队列的位置，攻击者每秒发出成千上万个这样的SYN包,队列很快被填满。
行业共识认为，当半连接队列被塞满后，新来的合法用户请求根本进不了队列，服务器直接丢弃SYN包，用户看到的现象就是“网站打不开”或“浏览器一直转圈”。
服务器“持续等待”背后的资源消耗机制
等待期间服务器并非只是“发呆”,它同时消耗三类资源。
内存资源方面，每个半连接都对应一个struct tcp_request_sock结构体，占用约250字节内存，假设攻击流量为每秒10万个SYN包，即使每个连接只存活30秒，服务器就要维护300万个半连接,内存消耗轻松达到几百兆甚至几个G。
CPU资源方面，内核需要为每个SYN包分配数据结构、计算序列号、启动定时器,这部分开销在普通的单机防护中会显著提高CPU占用率。
内核锁竞争方面，大量SYN包同时到达时，多个CPU核心会争抢操作半连接队列的锁,导致服务器处理效率大幅下降。
这三项消耗叠加的结果是，原本能支撑每秒几万请求的服务器，被每秒几万SYN包就打垮了,网络吞吐能力下降到正常水平的十分之一以下。
syn flood攻击怎么防御：从半连接队列到系统参数
防御SYN Flood，传统思路是“让服务器不要等那么久”，现代思路则是“把等待过程卸载到别处”，这里给出几套可操作的方案,从轻量到重量级排列。
调整Linux内核参数：减小等待窗口
对于小型网站，调整内核参数可以在一定程度上减缓攻击影响，编辑/etc/sysctl.conf文件,加入以下内容。
net.ipv4.tcp_syncookies = 1 net.ipv4.tcp_synack_retries = 1 net.ipv4.tcp_max_syn_backlog = 2048 net.ipv4.tcp_abort_on_overflow = 1
tcp_syncookies的作用是当半连接队列满时，不占用队列位置，而是通过计算一个Cookie值直接回复客户端，如果客户端是真实的，会回传Cookie并建立连接。tcp_abort_on_overflow的作用则更直接：当队列溢出时立即重置新连接，避免服务器继续等待。
这套配置对攻击规模较小的情况有效，但如果攻击流量每分钟超过几万个包,调整参数的效果就有限了。
对比硬件防火墙与云WAF的防护差异
硬件防火墙部署在企业机房出口，通过SYN Proxy技术拦截攻击，它作为代理先与客户端完成三次握手，确认客户端真实后再与后段服务器建立连接，这种方式对于清洗大规模流量有效,价格也不便宜。
云WAF则是把防御前置到云端，所有流量先经过云节点的清洗，再回源到你的服务器，它的优势在于带宽无限，不怕大流量冲击，近年来的云防护方案中，大多数云端清洗节点可以达到T级别防护能力，这类服务按防护峰值计费,属于后付费模式。
两者相比之下，硬件防火墙适合内网部署、数据不出企业环境的场景，云WAF则更适合应对大流量攻击,且无需维护硬件设备。
使用nginx与iptables的轻量级缓解措施
在应用层，nginx可以通过限制单IP连接数来减小影响,可以在nginx配置中加入以下指令：
limit_conn_zone $binary_remote_addr zone=perip:10m;
server {
limit_conn perip 10;
}
iptables方面,可以限制SYN包的速率：
iptables -A INPUT -p tcp --syn -m limit --limit 1/s --limit-burst 3 -j ACCEPT
这些规则会丢弃超出速率的SYN包，但不能完全防御分布式攻击，因为攻击源IP是伪造的,限制单IP速率对于伪造源地址的攻击几乎无效。
企业防护成本：syn flood攻击防护多少钱才合理
企业选择防护方案时，价格是绕不开的考量因素，根据防护能力和部署方式,市场上大致可分为三个价格区间。
| 防护方式 | 防护能力 | 大致价格范围 |
|---|---|---|
| 基础版本：自建防火墙+内核调优 | 几百Mbps，适合小规模攻击 | 0成本（仅人力投入） |
| 中端版本：硬件防火墙（机架式） | 几Gbps到几十Gbps | 几万元不等 |
| 云服务：按量计费的云清洗 | 上百Gbps到T级别 | 按防护峰值每小时计费 |
云服务商的计费模式比较灵活，大多数按“防护峰值+保底带宽”组合收费，一个实用的建议是：小型企业按需购买云防护，攻击结束后立即释放资源，避免闲置费用，企业如果需要7×24小时防护，则可以购买包年套餐,费用降低幅度较大。
linux系统syn flood防御设置的实际操作路径
对于多数技术团队而言，最容易上手的方案是在Linux服务器上开启SYN Cookie并调整队列参数,整体操作步骤如下。
- 检查当前参数：执行
sysctl net.ipv4.tcp_syncookies确认状态。 - 持久化配置：编辑
/etc/sysctl.conf，写入前文提到的参数后执行sysctl -p生效。 - 监控日志：查看
/var/log/messages或dmesg中是否有“TCP: request_sock_TCP: Possible SYN flooding”提示。 - 后续观察：若攻击持续,考虑在服务器前增加云防护或硬件设备。
这套操作在多数Linux发行版（CentOS、Ubuntu、Debian）上通用。
对比购买云清洗与自建防护设备的使用场景
自建硬件设备适合企业拥有独立机房、数据不能出内网、且攻击带宽在设备能力范围内的场景，但硬件设备的带宽瓶颈是硬伤，一旦攻击流量超过设备处理能力,链路仍然会被堵死。
云端清洗的接入方式完全不同，DNS解析先指向云防护IP，云节点清洗后再通过内网回源，攻击流量再多也只打云节点,企业服务器的带宽始终处于空闲状态。
下面是一个常见的场景描述：某电商平台在春季大促当天遭遇攻击，攻击带宽高峰期达到几十Gbps，自建防火墙瞬间被打满，切换DNS到云清洗节点后，用户访问恢复正常，回源流量只有干净的业务请求。最终靠云端防护保住业务，底层原理就是“不让攻击流量靠近服务器”。
syn flood攻击防护常见问题解答
syn flood攻击会影响正常用户访问吗
会，半连接队列满后，新连接请求会被直接丢弃，正常用户发送的SYN包和攻击者的SYN包无法区分，服务器只能一视同仁地丢弃。用户侧表现为持续连接超时或页面加载失败，只有当队列释放出空间或攻击停止后,正常访问才能逐步恢复。
服务器重启可以解决syn flood攻击吗
服务器重启可以清除当前的半连接列表，但攻击流量持续到来时，新产生的半连接会在一两秒内再次占满队列。重启只适合临时应急，根本解决办法是阻断攻击源或启用防护设备，攻击源是伪造IP,而且每秒发出的SYN包数量远大于服务器处理能力。
云防护和自建WAF的防御效果有差别吗
相差主要在防护上限和运维成本，自建WAF的处理能力受限于单机性能，一般只能扛住每秒几万个请求，云防护的清洗集群可以横向扩展，防御能力高出几个量级。云防护对于大流量攻击的清洗效率较高，自建WAF则用于过滤应用层攻击比较多，业内专家指出,两者结合使用能在纵深防御上取得较好效果。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/788032.html
