16
一、CC 自适应基线 v3
之前的问题
旧版基线算法将每个 IP 的请求数按固定的 60 秒时间桶取峰值，再换算成"每秒请求率"（rps），最后乘以检测窗口还原为请求数。
这个流程有一个本质性的偏差：桶大小和检测窗口不对齐。
举例来说，如果你的 CC 检测窗口设为 10 秒，但算法是在 60 秒桶里取峰值再除以 6 来估算 10 秒的量——一个用户在 10 秒内集中发送 8 次请求的突发行为，被 60 秒桶平均后变成了 1.3 次/10 秒。真实的突发访问模式在这个转换中被抹平了。
现在怎么算
v3 算法做了一个直觉上很简单但效果显著的改动：用你实际配置的检测窗口大小来切分时间桶。
具体流程：
- 取最近 3 天的访问日志
- 排除已知攻击 IP（近 24 小时被自动封禁的 + WAF 标记的攻击源）
- 排除扫描器（4xx/5xx 错误率超过 50% 的 IP）
- 按你配置的检测窗口（如 10 秒）切分时间桶
- 统计每个 IP 在所有时间桶中的最高请求数（峰值）
- 对所有 IP 的峰值取 p99 百分位
最终的 p99 含义变得非常直接：99% 的正常用户，在任意一个检测窗口内的请求数都不超过这个值。
基线 = p99 峰值 × 安全余量倍数
不再需要 rps → 请求数的来回转换，算出来就是节点直接用的阈值。
实际效果
以一个检测窗口为 10 秒的站点为例：
| 场景 | 旧算法基线 | v3 基线 |
|---|---|---|
| 正常浏览用户（偶尔集中刷新） | 可能偏低，漏放突发 | 精确捕捉 10 秒内的真实峰值 |
| API 对接方（持续稳定调用） | 基本准确 | 基本一致 |
| 低速慢速攻击（1-2 rps 持续） | 可能被 60 秒桶吸收 | 在 10 秒桶内更容易暴露 |
二、POST 泛洪基线 — 自动站点分档
之前的问题
POST 泛洪的基线算法和 CC 共用同一套参数，没有区分站点类型。这带来两个问题：
- API 站点被误伤：正常的 webhook 回调、数据提交可能达到每秒数十次 POST，但硬上限按普通网站设置，把合法流量当作异常截断
- 内容站点防护太松：博客、企业官网几乎没有 POST 流量，旧的下限值却允许每分钟 30 次 POST 不触发任何防护
现在怎么算
系统根据你在 POST 泛洪防护面板中选择的站点类型，自动匹配一组专属的防护参数：
| 站点类型 | 峰值上限 | 最低阈值 | 适用场景 |
|---|---|---|---|
| 普通网站 | 1.5 req/s | 较严格 | 企业官网、博客、CMS，POST 主要是表单提交和登录 |
| API 服务 | 5 req/s | 较宽松 | 前后端分离、小程序后端、webhook 接收 |
| 聊天室/即时通讯 | 8 req/s | 宽松 | 消息收发密集，正常 POST 频率本身就高 |
| 网盘/文件上传 | 3 req/s | 适中 | 请求频率不高但单次体积大 |
每种类型的峰值上限和最低阈值都是针对性调校的。不再用一组参数硬套所有站点。
如果你没有选择站点类型，系统会根据站点近 3 天的 POST 流量占比自动判定——但建议主动选择，比自动检测更准确。
旧版的「灵敏度」下拉（保守/平衡/敏感）已移除。站点类型比抽象的灵敏度更直观，也更准确。
实际效果
| 场景 | 旧算法 | 新算法 |
|---|---|---|
| 博客站（普通网站），正常 POST 约 1 次/分钟，检测窗口 300 秒 | 下限 150 次，攻击者可发 149 次不触发 | 下限 15 次，异常行为更快被识别 |
| API 网关（API 服务），正常客户端 POST 峰值 40 次/10 秒 | 峰值被硬上限截断为 30，导致基线偏低 | 上限自动放宽到 50，基线准确反映真实流量 |
| 聊天应用（聊天室），正常消息发送峰值 60 次/10 秒 | 被旧上限截断为 30，大量正常用户被封 | 上限放宽到 80，正常聊天不受影响 |
升级说明
- CC 基线改动已自动生效，下一次定时计算（每 24 小时）后新算法结果会自动推送到所有节点
- POST 泛洪建议在站点配置中确认「站点类型」是否正确，系统会据此适配防护参数
- 如果发现基线变化较大导致误拦截，可以在站点配置中临时切换到「手动模式」设定阈值
- POST 泛洪防护面板中的「灵敏度」选项已移除，不影响现有防护效果
壹盾安全官方
回复讨论
0
登录后可参与回复讨论。
当前还没有回复，欢迎成为第一个参与讨论的人。
文明发言，理性讨论