SYN Flood 是什么：服务器半连接队列耗尽的原理与影响

SYN Flood 是一种利用 TCP（传输控制协议）三次握手机制消耗服务器半连接队列资源的 DDoS（分布式拒绝服务攻击）方式。攻击端持续发送大量 SYN（同步）请求，却不完成后续 ACK（确认）响应，使服务器在等待连接完成时保留连接状态；当半连接队列被占满，正常用户的新连接可能被延迟、丢弃或无法建立。理解它的价值在于：SYN Flood 并不一定直接打满带宽（网络传输容量），却可能通过耗尽内核连接状态影响 Web、游戏、API、邮件等服务的可用性。

定义

在 TCP（传输控制协议）连接建立过程中，客户端先发送 SYN（同步）包，服务器返回 SYN-ACK（同步确认）包，客户端再返回 ACK（确认）包，连接才进入已建立状态。SYN Flood 的核心做法，是大量制造第一步请求，同时让第三步长期缺失。服务器为了等待握手完成，会把这些未完成连接放入半连接队列；队列容量、超时时间和重传策略共同决定了服务器能承受多少未完成握手。

半连接队列并不是应用程序自己维护的普通列表，而是操作系统网络栈中的连接状态资源。对于公开暴露在互联网的 Web 服务，攻击流量可能集中打向 80、443、25、3306 或游戏端口等常见入口。与应用层 CC 攻击相比，SYN Flood 更靠近传输层，应用日志里未必能看到完整请求，因此排查时需要同时观察内核连接状态、防火墙计数和上游清洗设备记录。

工作原理

SYN Flood 依赖 TCP（传输控制协议）握手过程中的状态不对称。客户端发送一个 SYN（同步）包成本很低，但服务器收到后要分配内核状态、记录源地址和端口、准备重传 SYN-ACK（同步确认）包，并等待最终 ACK（确认）。如果大量请求来自伪造源地址、僵尸主机或被放大的流量源，服务器会不断保存“可能即将完成”的连接。

可把攻击过程拆成三个阶段：攻击端制造大量新建连接请求；服务器把未完成握手放入半连接队列；队列被填满后，新的正常连接排队失败或等待超时。Linux 系统中常见观测点包括 SYN_RECV 状态数量、监听端口的 accept backlog、内核参数 net.ipv4.tcp_max_syn_backlog、net.ipv4.tcp_synack_retries 以及是否启用 net.ipv4.tcp_syncookies。

对服务器可用性的影响

SYN Flood 的直接影响是新连接建立失败，而不是已建立连接必然断开。一个已登录的 SSH（安全外壳协议）会话、已经建立的数据库连接池或保持长连接的客户端，可能在短时间内继续工作；但新用户访问网站、API 客户端重新连接、邮件服务器接收新投递时，会更容易出现连接超时。

从服务表现看，常见症状包括页面首次打开慢、TLS（传输层安全协议）握手前就断开、负载均衡器后端健康检查失败、监控显示连接错误率升高。由于攻击可能不需要占满链路，带宽（网络传输容量）图表看起来未必异常；如果只看 CPU、内存和磁盘，也可能误判为应用程序偶发故障。

如何判断是否出现 SYN Flood

判断 SYN Flood 时，应避免只凭单个指标下结论。较稳妥的方法是同时看连接状态、包速率和业务症状。例如 Linux 服务器可通过 ss -ant state syn-recv 查看处于半连接状态的 TCP（传输控制协议）连接数量，也可在防火墙或边界设备上统计目标端口的 SYN（同步）包速率。若 SYN_RECV 长时间显著高于历史基线，同时新连接失败集中出现，SYN Flood 的可能性会明显增加。

ss -ant state syn-recv | wc -l
sysctl net.ipv4.tcp_max_syn_backlog
sysctl net.ipv4.tcp_syncookies

这些命令只适合作为初步观测。生产环境还需要结合负载均衡器、WAF（Web 应用防火墙）、高防清洗平台或上游运营商提供的流量统计。若流量源地址大量随机、国家或自治系统分布异常、单个目标端口每秒 SYN（同步）包远超日常峰值，则更接近攻击行为；若异常只来自少量合法客户端，也可能是客户端重试、NAT 网关故障或应用连接池配置错误。

常见防护思路

SYN Flood 防护通常分为主机内核、边界网络和业务架构三层。主机侧可以启用 SYN Cookies、调整半连接队列容量和重传次数；边界侧可以通过限速、连接速率控制、黑洞牵引或清洗中心过滤异常 SYN（同步）流量；业务架构侧则可把公开入口放在负载均衡、高防 IP、线路优化入口或 CDN（内容分发网络） 前面，减少源站直接暴露。

常见措施包括：

• 启用 `net.ipv4.tcp_syncookies=1`，在队列压力较高时降低半连接状态占用。
• 根据业务峰值调整 `net.ipv4.tcp_max_syn_backlog`，避免默认容量过小导致误伤。
• 在边界防火墙设置每源连接速率阈值，例如对单 IP 每秒新建连接数设置动态限制。
• 把公网 Web 入口接入 CDN（内容分发网络）或高防清洗服务，让异常流量先被上游吸收。
• 为重要 API、游戏网关和邮件服务建立独立监控，按端口记录 SYN（同步）包速率和失败率。

这些措施并非越多越好。过低的限速可能误伤秒杀、促销、更新推送等真实高并发场景；过大的队列容量也可能延长异常状态占用时间。有效防护依赖基线数据，例如日常峰值每秒 500 个新连接、活动峰值每秒 3000 个新连接，就不应使用固定的每秒 200 个连接阈值。

与其他攻击或故障的区别

SYN Flood 常被归入 DDoS（分布式拒绝服务攻击），但它与 HTTP Flood、UDP Flood、CC 攻击和普通应用故障并不相同。HTTP Flood 已完成 TCP（传输控制协议）连接，通常会在 Web 访问日志中留下请求；UDP Flood 不依赖连接状态，更多体现为链路或设备处理压力；普通应用故障则常伴随错误日志、线程池耗尽、数据库慢查询等应用层证据。

常见误解

一个常见误解是“带宽（网络传输容量）没打满就不是攻击”。SYN Flood 的目标往往是连接状态资源，较小包量也可能在短时间内占满半连接队列。另一个误解是“只要打开 SYN Cookies 就完全安全”。SYN Cookies 能缓解半连接队列压力，但无法替代上游清洗、源站隐藏和容量规划；当链路、边界设备或负载均衡器先被压垮时，主机内核参数已经来不及发挥作用。

还有一种误判是把所有 SYN_RECV 增加都视为攻击。跨国网络抖动、客户端 NAT 设备异常、移动网络丢包、健康检查配置错误，都可能让握手完成率下降。因此，判断应同时参考源地址分布、端口集中度、持续时间、业务影响范围和历史基线。

参考资料与延伸阅读

• RFC 9293：Transmission Control Protocol，定义 TCP（传输控制协议）的连接建立与状态模型。
• Linux kernel ip-sysctl 文档，说明 `tcp_syncookies`、`tcp_max_syn_backlog` 等网络栈参数。
• 美国高防服务器防御原理深度解析，可作为流量清洗、黑洞牵引与边界防护的延伸阅读。
• 域名解析 DNS（域名系统）全过程详解，有助于区分解析异常与连接层异常。
• Linux 服务器运维相关词条，可用于继续了解网络栈观测和系统排查方法。

总结

SYN Flood 的本质，是用大量未完成的 TCP（传输控制协议）握手消耗服务器半连接队列，使正常用户难以建立新连接。排查时建议从 SYN_RECV 状态、目标端口 SYN（同步）包速率、业务新连接失败率和上游清洗日志四类证据交叉确认。防护上可以考虑把内核参数、边界限速、清洗服务和架构隔离结合起来，而不是只依赖某一个开关。对于对外提供 Web、API、游戏或邮件入口的服务器，推荐提前建立连接基线和告警阈值，这样在攻击发生时才能区分真实攻击、网络抖动和应用配置问题。