DDoS 攻击：类型、症状与防护

2026年2月17日 • 2 min read

DDoS 并不是新现象，但它已经变得更容易、更便宜，也更容易规模化。过去，少量配置不当的服务器或一个小型 botnet 就足以让服务中断。如今我们经常看到攻击在几分之一秒内就能把链路打满、压垮防火墙，或者用看起来“正常”的请求把应用拖垮。

本文不是为了制造恐慌，而是为了把概念讲清楚：DDoS 到底是什么、哪些攻击类别在现实中最常见、生产环境里如何识别，以及哪些对策真正值得投入。

什么是 (D)DoS？

在 Denial-of-Service (DoS) 攻击中，攻击者试图让服务不可用，不是通过窃取数据，而是通过 压垮服务 或耗尽资源。目标是可用性：网站打不开、API 超时、VPN 网关不再接受会话、DNS 解析器跟不上等。

Distributed 中的 “D” 表示流量不是来自单一来源，而是来自许多来源。它可能来自被攻陷设备组成的 botnet，也可能来自合法基础设施（reflection/amplification），或两者的组合。对运营者来说，结果看起来都一样：你面对的不是一个攻击者，而是分布式的流量洪峰。

动机：为什么要发起 DDoS？

动机往往不复杂，但很有效：

勒索：“付钱，否则我们再打一次。”
行动/政治：制造关注、传递信息、造成中断。
干扰：用 DDoS 牵制团队，同时进行其他攻击。
竞争/破坏：在关键时刻（票务、发布、上线）哪怕短暂中断也很致命。
成本打击：并非所有攻击都追求彻底宕机，有时目的就是抬高云成本、支持成本或运营压力。

关键层级（以及为什么重要）

DDoS 经常按层（Layer）来描述，因为层级决定了要看哪些信号，以及能做哪些防御。

Layer 3 (IP)：从哪里来，到哪里去。
Layer 4 (TCP/UDP)：端口、连接、握手、状态（state）。
Layer 7 (Application)：HTTP(S) 请求、API、业务端点。
“Layer 8”（业务逻辑）：不是正式层，但很真实：应用里“昂贵”的逻辑容易被滥用。

关键结论：Layer 3/4 上看起来完美的防护，仍可能被 Layer 7 攻击绕过，因为请求表面上很“合法”，真正的成本发生在应用内部。

攻击类别 1：流量规模与放大（通常是 UDP）

体量型攻击的目标是压垮带宽或 包处理能力（pps）。经典方式是 reflection/amplification：

攻击者向公开可达的服务器发送很小的请求（例如开放的 DNS resolver）。
伪造源地址（spoofing），把受害者 IP 作为 “source”。
这些服务器向受害者返回更大的响应。

如果 100 字节的请求触发 1,000 字节的响应，放大因子就是 10。根据协议和 payload，因子可能更高。棘手之处在于：从受害者视角看，流量来自“正常服务”，你往往不想轻易封掉。

重要点：放大攻击通常依赖源 IP 伪造。正因为如此，ingress filtering (BCP 38) 非常关键。运营商若能在边缘一致性地丢弃伪造源地址，这类攻击会难得多。

攻击类别 2：协议与状态耗尽（TCP/Layer 4）

并非所有 DDoS 都追求最大带宽。很多时候，更高效的做法是不断制造 state，直到表项或资源耗尽。

经典例子是 TCP 的 SYN flood：

正常情况下，TCP 通过 three-way handshake 建立连接（SYN -> SYN/ACK -> ACK）。
SYN flood 会发送大量 SYN，但最后的 ACK 不会到来。
服务器要维护大量半开连接（state），并在超时前不断重试。

这会消耗内存和 CPU，也可能影响出站带宽。即便带宽很大：会话跟踪表一满，服务就很接近不可用了。

相近的一类是 low and slow：攻击者建立真实连接，然后用极少数据把连接“吊着”，直到 Web 服务器或负载均衡达到连接上限。相比带宽尖峰，这种攻击更不显眼。

攻击类别 3：Layer 7 与 “Layer 8”（HTTP、API、昂贵端点）

Layer 7 攻击常常最让人头疼，因为它更难与正常流量区分。比如：

HTTP flood：大量请求打到动态页面、搜索端点或登录流程。
Slowloris/slow headers：通过极慢发送 header/body 来保持连接不释放。
“昂贵”的业务逻辑：触发数据库查询、外部 API 调用、PDF 生成、加密计算，甚至 AI/agent 工作流的端点。

诀窍不一定是“更多流量”，而是 每个请求带来更多计算工作。少量但精准的请求可能比大量缓存的静态 GET 更昂贵。

生产环境如何识别 DDoS？

如果只盯着 CPU 和内存，你会错过一些信号。实践中，baseline 加上一组稳健指标会非常有帮助：

流量：边缘（router/firewall/load balancer）的 bps 与 pps。
连接指标：新连接/秒、打开的会话数、SYN backlog、TLS 握手/秒。
HTTP 指标：RPS、延迟（p95/p99）、4xx/5xx 比例、超时。
上游症状：丢包、RTT 上升、链路饱和、BGP 事件。
日志/WAF 信号：异常路径、无效 header、大量未完成请求、可疑 UA/模式。

最重要的一点很朴素：需要 baseline。 没有 baseline，一切都像“有点多”。有了 baseline，你会立刻发现“包很小”或“请求不完整”与常态差异巨大。

缓解：哪些手段真正有效？

大致有两条路：make（自建）或 buy（购买服务）。对大多数团队来说，“buy”更现实，因为 DDoS 缓解很快会变成一个无法当作副业维护的问题。

1) 在应用前面加一层：CDN/WAF/DDoS 防护服务

对网站和 API 来说，这通常最有效：

Anycast 将流量分摊到多个地点。
WAF 规则可以过滤明显的 Layer 7 模式。
Bot 管理、限速和 challenge/response 能降低“廉价攻击”。

注意：并非所有攻击都是 HTTP。如果你对外提供 VPN、VoIP、游戏服务器或其他 UDP 协议服务，防护层需要按你的架构调整。

2) 把限速与超时设置好

简单但有效（前提是配置得当）：

ICMP/“ping”：限制而不是彻底禁用（排障仍需要）。
HTTP：按 IP/token/route 限速，重点保护昂贵端点。
慢请求：对不完整的 header/body 设置硬超时。

示例（Nginx，强简化）：

limit_req_zone $binary_remote_addr zone=api_per_ip:10m rate=10r/s;

location /api/ {
  limit_req zone=api_per_ip burst=40 nodelay;
}

这不是“银弹”，但能改变攻击经济学：廉价攻击会变得更难。

3) 架构：把昂贵工作解耦

Layer 7 DDoS 往往不是打满带宽，而是打在 单个请求成本极高 的地方。正常公司系统里这种点很多：登录、搜索、PDF 导出、报表、上传、复杂查询、外部 API 调用等。

一个常见场景：客户门户有导出按钮（“账单 PDF”“生成报表”“打包 ZIP 下载”）。平时可能几分钟才有人点一次，但攻击时同一个端点会被每分钟触发数百甚至数千次。问题不是带宽，而是 CPU（渲染）、数据库（查询）和 worker 池（线程/连接）。外部表现就是“网站很慢”，内部则是超时、排队、DB 跟不上。

好消息是你不必推倒重来。很多时候，几项架构选择就能把昂贵部分从请求路径中分离，并加上刹车：

缓存（包括错误页）、合理 TTL、边缘缓存。
对昂贵任务使用异步处理（队列）：不要“立即出 PDF”，而是触发 job，稍后交付。
严格输入校验与提前终止：限制复杂度、设置硬限制。
登录/搜索/上传/导出等使用独立保护：独立限速、独立超时，必要时独立 worker 池。
“降级模式”开关（feature flags）：无需部署即可临时关闭某些功能。

4) 上游选项：过滤、scrubbing 与应急方案

如果规模非常大，就需要在流量 到达你的线路之前 进行清洗/过滤：

运营商侧过滤 / scrubbing center
临时阻断规则（例如：为什么 Web 服务器会收到 UDP？）
应急路由（例如切到“受保护”的 IP）

这只有在你事先与运营商沟通过的情况下才可行。事故中临时“现做”通常既慢又贵。

实用检查清单（没有 DDoS 专家也能做）

资产清单：哪些服务对外？HTTP、DNS、VPN、邮件、VoIP 等？
单点风险：DNS 供应商、反向代理、负载均衡、单区域部署？
可观测性：bps/pps、RPS、延迟、错误、连接数、基于 baseline 的告警。
加固默认值：超时、限制、最大 header 大小、连接上限、backpressure。
运营商预案：谁负责清洗、谁能过滤、如何升级/联系。
Runbook：发生 X 时做 Y（联系人、阈值、开关 feature flags）。
演练：受控压测与事件演练（合法、协调）。

最后：测试要合法且有价值

测试 DDoS 很敏感。任何触及公共互联网、第三方系统或未经许可的基础设施都不应进行。你可以做的是：

在自己的 staging 里压测（尤其是昂贵端点）。
对依赖做 chaos test（缓存不可用、DB 变慢、限速更严格）。
演练响应流程：告警、沟通、运营商升级、应急措施。

参考资料

下次见， Joe