2026 Q3 DDoS 报告里的“小而密”：短时高频攻击怎么改变检测口径

如果只用一条“峰值带宽超过某个值就告警”的规则来判断 DDoS，2026 年第三季度的数据会让这条规则显得越来越不够用。Cloudflare 在 10 月 29 日发布的第 26 期 DDoS 威胁报告里，被自动缓解的网络层攻击有 96% 在 10 分钟内结束，98% 峰值低于 1 Gbps；而同一季度，这类短时攻击的增速被单独拎出来讲。攻击的主要变化不是变大，而是变短、变密。Cloudflare DDoS Threat Report 2026 Q3

报告里的“小而密”到底指什么#

先把几个数字放在一起看，因为它们描述的是同一件事的不同侧面：

• 总量：第三季度（7、8、9 月）Cloudflare 自动缓解了约 1820 万次网络层 DDoS 攻击和 14.4 万亿次 HTTP DDoS 请求，折合约每小时 8226 次、每天约 19.74 万次，也就是平均每 0.44 秒一次；缓解流量为网络层 272.6 PB、HTTP 层 95.1 PB。
• 形状：96% 的攻击在 10 分钟内结束，98% 低于 1 Gbps。
• 大攻击：超过 1 Tbps 的超大流量攻击从第二季度的 805 次降到第三季度的 251 次，降幅接近 69%。报告把这一下降与 2026 年初针对 Aisuru、KimWolf、JackSkid、Mossad 四个大型 IoT 僵尸网络的执法行动联系起来，但用的是“可能反映”（possibly）这样的措辞。
• 字节量并未消失：Mirai 类攻击的缓解量在 8 月达到峰值 57.23 PB，占当季全部已缓解网络层字节的 46.5%，其中 8 月 16、19、23、25 日各有超过 3 PB；当季最长的一次持续攻击运行了 49.7 小时。

把这四点合起来读：事件的数量在涨，单次事件的幅度在降，但总字节仍集中在少数长时、大流量的攻击上。报告的向量变化也指向同一方向：CLDAP 反射攻击在上半年环比激增 580% 后，第三季度骤降至仅占攻击的 0.05%（环比下降 99.5%）；DNS 放大攻击增长 215%，占网络层攻击的 3.43%；其他 UDP flood 从 14.06% 升至 31.31%。反射放大的入口在换，但“小查询换大响应”的杠杆逻辑没变。

为什么单看峰值会漏掉大部分事件#

基于峰值的阈值检测有一个隐含假设：攻击的幅度会显著高于正常基线。当 98% 的攻击低于 1 Gbps 时，这个假设在很多业务上不成立——一次持续几分钟、几百 Mbps 的突发，很可能落在促销、爬虫、重试风暴造成的正常波动区间里，按幅度判断就是噪声。

但换一个维度看，信号非常清楚：每小时 8226 次意味着平均每 0.44 秒就有一次事件被判定成立。也就是说，判别信息更多存在于单位时间的事件频率和事件时长的分布里，而不是单次峰值里。这是从报告数据推出的工程判断，不是报告本身给出的检测结论——报告披露的是被缓解攻击的统计分布，没有展开检测算法怎么实现。

同时也不能走到另一个极端。251 次超过 1 Tbps 的攻击仍意味着每季度数百次、平均每天近三次的超大流量事件；Mirai 类单月 57.23 PB 说明字节压力依旧集中。合理的口径是两条轴同时看，而不是用频率替换峰值。

检测口径可以往哪几个方向调#

下面是建议，不是报告结论；是否适用取决于你自己的流量基线和误报成本。

1. 把“一次攻击事件”的定义写死。起止怎么算、两次超阈值之间静默多久算同一次、最短持续多久才计入。10 分钟这个分界线直接决定了“短时攻击”的统计结果，口径不写死，跨季度对比就没有意义。
2. 聚合维度改成受害目标，而不是源 IP。短时高频攻击常伴随源地址分散，按源聚合会把一次攻击拆成上千条低幅度记录，反而稀释信号。
3. 峰值与频率分两列记。同一时间窗内同时输出“峰值 bps”和“事件数/分钟”，前者用于触发清洗，后者用于触发限流与挑战。两条通道的响应动作不同，告警也应该分开。
4. 用短窗口滑动计数对比长窗口基线。例如 1 分钟事件数与过去 24 小时同目标的事件数中位数比较，看的是频率的相对变化，而不是绝对带宽。
5. 为已知的高频来源留白名单和发布窗口。压测、批量回源、客户端重试风暴在频率维度上和短时攻击很像，没有业务侧的上下文，误报率会明显上升。
6. 保留原始事件记录。口径一定会改，只有保留足够细的原始 flow 或访问日志，才能在改口径后回溯重算，而不是从改口径那天起重新开始积累。

一个可核对的口径骨架#

下面这段伪代码只表达结构：把峰值和事件计数分开算，事件之间用静默间隔合并。它未被执行，其中的数值均为示例占位，不构成阈值建议。

# 未执行，仅示意口径结构；参数为占位值
WINDOW    = 60      # 统计窗口，秒
MERGE_GAP = 30      # 同一目标两次超阈值间隔小于此值则合并为一次事件
DEMO_BPS  = 1e9     # 示例占位，不是推荐阈值

def on_sample(target, ts, bps, state):
    q = state.setdefault(target, [])
    q.append((ts, bps))
    while q and ts - q[0][0] > WINDOW:
        q.pop(0)
    peak = max(b for _, b in q)
    events = len(split_events(q, MERGE_GAP, DEMO_BPS))
    return {"peak_bps": peak, "events_per_window": events}

把它落到监控系统时，建议至少同时留存三张表：按分钟的目标峰值、按分钟的目标事件数、以及事件的起止时间与持续时长分布。这样季度复盘时才能回答“我们这边短时攻击占比是多少”，而不是只有一个峰值曲线。

读这份报告要留的边界#

• 样本范围：数据来自 Cloudflare 网络内被其系统自动缓解的攻击，不代表全网流量，也不等于所有未遂攻击。引用比例时应保留“在其网络内”这个限定。
• 因果措辞：1 Tbps 攻击下降与执法行动的关联，报告自己用的是“可能反映”，并且同时指出 Dysphoria、Evooo1Bot 等新变种仍在出现。把它读成“大攻击已被解决”会超出材料支持的范围。
• 208% 的口径：报告在要点部分把 208% 挂在“持续 10 分钟内、低于 1 Gbps 的短时低带宽攻击”上，正文同一节又用 208% 描述 1820 万次网络层攻击的同比增长。两处共用同一增幅，做容量规划前应回到原报告核对分母与基期。
• 未覆盖的部分：报告没有给出检测算法、阈值设定或误报率的细节。本文第二、三节的检测建议属于工程推断，需要在你自己的流量上验证后才能采用。

对以 API 对外提供服务的团队来说，实际可做的一步并不复杂：先把“一次攻击”的定义和“频率”这个指标补进现有监控，再谈阈值调到多少。攻击变短变密之后，最贵的往往不是被打穿，而是事件发生了却没能被记成一次事件。