应对CC攻击的5种请求频率限制方法对比

面对CC攻击，单纯封禁少量来源地址往往不够。攻击者可以更换出口、伪装访问路径，或让大量请求集中消耗连接数、查询资源和应用线程。更稳妥的做法是围绕CC请求频率限制建立分层规则：先识别请求对象，再按来源、账号、会话、接口和全局资源设置不同阈值。

下面比较五种常见方案。实际部署时，应以响应时间、错误率、连接数和业务转化情况共同判断，而不是只看请求数量。

一、五种CC请求频率限制方法对比

二、固定窗口：成本最低的第一道规则

固定窗口把时间切成连续区间，例如按10秒或1分钟计数。请求达到阈值后，可以返回429、暂时排队，或要求完成额外验证。它适合静态资源之外的普通查询接口，也适合在攻击初期快速启用CC请求频率限制。

执行步骤

1. 确定统计维度，例如来源地址、账号、接口路径或来源地址与账号的组合。
2. 选定窗口长度和上限。公开查询接口可从较宽松的区间开始，登录、搜索和提交接口应分别设定。
3. 连续观察拒绝率、平均响应时间和正常用户投诉，再调整窗口或阈值。

它的缺点是边界效应：请求可能在一个窗口结束和下一个窗口开始时集中出现。因此，固定窗口适合作为基础拦截，不宜单独保护高价值、重计算接口。

三、滑动窗口：减少边界突发

滑动窗口会查看“最近一段时间”内的请求，而不是只看当前固定区间。例如系统持续统计最近30秒的访问量，窗口随时间向前移动。相比固定窗口，它对突发流量的判断更连续，误放行概率通常更低。

实现时可以使用Redis等集中式存储记录时间戳或分段计数。多节点应用尤其需要共享计数，否则同一来源分散到不同节点后，整体限制可能失效。滑动窗口的代价是读写次数和内存占用较高，适合重点接口，不必对所有图片、样式文件采用同样精细的记录方式。

四、令牌桶：允许合理突发，但控制长期速率

令牌桶以固定速率生成令牌，请求消耗令牌；桶中预先积累的令牌则允许短时间突发。它适合新闻发布、商品详情或搜索等存在正常峰值的业务，但应把资源消耗较大的接口单独分组。

配置时先设定长期速率，再设定桶容量。长期速率决定平均允许量，桶容量决定瞬时突发量。若桶容量过大，攻击流量仍可能在短时间内压垮应用；若过小，正常用户在页面集中加载时也容易被拦截。令牌桶通常比固定窗口更灵活，是常见的CC请求频率限制方案。

五、漏桶：优先保护下游处理能力

漏桶把进入的请求放入队列，并以相对稳定的速率交给应用处理。它能削弱瞬间洪峰，适合生成文件、复杂搜索、图像处理等耗时任务。若队列已满，应尽快拒绝新请求，而不是无限等待。

漏桶不适合所有实时接口。对于需要即时返回的查询，过长排队会让用户体验变差；对于异步任务，则可以返回任务编号，让客户端稍后查询结果。部署时应同时设置队列长度、最大等待时间和失败后的重试规则，避免客户端无间隔重试形成新的压力。

六、并发数限制：防止重接口占满资源

请求频率高不一定是唯一问题。有些接口每秒请求不多，但每次都会执行复杂数据库查询或长时间占用连接。并发限制直接控制“正在处理的请求数”，因此适合导出、上传、全文检索和支付状态查询等资源敏感操作。

推荐配置流程

1. 按接口测出正常请求的平均耗时和峰值并发，区分匿名用户、登录用户与内部任务。
2. 为单个来源、单个账号和全局服务分别设置上限，避免一个维度失控。
3. 超过上限时优先返回明确的稍后重试提示；对可异步化任务，改用队列。
4. 监控等待时间、超时数和数据库连接使用情况，确认限制确实保护了下游资源。

七、怎样组合五种方法

较稳妥的组合是：边缘层使用固定窗口或滑动窗口，应用网关使用令牌桶，重接口再增加并发数限制，异步任务使用漏桶队列。规则维度不要只依赖单一来源地址，还应结合账号、会话、接口和全局资源。

上线前先以记录或告警模式运行，收集正常流量的分布；确认规则不会大量拦截正常请求后，再启用阻断。对搜索、登录和提交类接口分别配置，通常比所有路径共用一条阈值更可靠。必要时可结合验证码、身份认证和缓存，但验证码不能替代CC请求频率限制。

常见问题

1. 只限制来源地址是否足够？

通常不够。来源地址可能被代理或共享，建议同时考虑账号、会话、接口和全局并发。

2. 五种方法必须全部使用吗？

不必。普通站点可先用固定窗口加并发限制；流量复杂或接口较多时，再引入滑动窗口和令牌桶。

3. 被限制的请求应该返回什么？

短时超限通常返回429，并提供合理的重试提示；高风险流量则可以进入验证或直接丢弃。

4. 如何减少误拦截？

先观察模式运行，按接口区分阈值，并结合响应时间、错误率和业务日志持续校准。

总的来说，CC请求频率限制没有一套适用于所有系统的固定数字。固定窗口便于快速部署，滑动窗口更平滑，令牌桶适合合理突发，漏桶擅长削峰，并发数限制则直接保护重资源接口。根据业务特征组合使用，通常比单一封禁策略更可靠。