固定阈值与动态策略的CC请求频率限制差异

CC请求频率限制的核心，不是单纯把每个来源的请求数压到某个数字以下，而是在保护服务可用性的同时，尽量保留正常访问。固定阈值与动态策略的差异，主要体现在判断依据、响应速度、误伤概率和维护成本上。小型站点通常更重视部署简单，大型或流量波动明显的系统则需要更有弹性的控制方式。

固定阈值：规则清楚，但适应性有限

固定阈值通常按固定窗口统计请求，例如规定某个来源在1分钟内最多访问60次，超过后返回限流响应、延迟处理或暂时拒绝。实现上，Nginx的请求限制模块、网关中的固定窗口计数器，都可以承担这类工作。

固定阈值的优点是容易解释。例如，公开查询接口可以先按客户端地址设置每分钟几十次的基础限制，管理后台则采用更严格的账号与来源组合规则。缺点也很明显：同一阈值可能无法区分脚本重复请求、移动网络共享出口和多个真实用户共用的企业网关。

动态策略不只看请求数量，还会综合请求间隔、路径变化、响应结果、并发占用和当前资源压力。系统可以在正常时保持较宽松的额度，在出现连续重复访问、异常路径遍历或上游排队增长时，逐步收紧CC请求频率限制。

常见实现包括滑动窗口、令牌桶和漏桶。滑动窗口更接近最近一段时间的真实访问量；令牌桶允许短时突发，但会限制长期平均速率；漏桶则强调以较稳定的速度向后端放行。它们并非谁绝对更好：需要容纳短暂峰值时，令牌桶通常更合适；后端处理能力固定、希望平滑流量时，漏桶更容易控制。

动态策略可以把访问者分为正常、观察和限制三档，而不是首次超限就立即封禁。观察档可返回较短的冷却时间，限制档再延长等待或要求完成验证。这样能降低共享出口、校园网络和移动运营商地址被整体误伤的风险。

固定方案的关键风险是“阈值刚好卡在业务高峰附近”。例如，票务开售、成绩查询或公共服务预约时，真实用户可能在短时间内重复刷新。若额度过低，正常访问会被拒绝；若额度过高，攻击请求又可能占满连接和带宽。动态方案能缓和这种冲突，但不能替代容量规划，也不能保证自动判断永远正确。

先拆分请求类型。不要把静态资源、数据查询、文件生成和状态变更放在同一条规则里。高成本操作应有独立额度，低成本缓存内容可以采用较宽的上限。
确定识别维度。可以组合客户端地址、账号、会话标识、接口路径和设备特征。对于共享出口较多的服务，不宜只按地址做长期封禁。
选择计数方式。固定窗口适合快速上线；需要减少窗口边界突刺时，优先考虑滑动窗口；需要允许短暂峰值时，可使用令牌桶，并设置有限容量。
设计分级动作。第一次达到警戒线时记录并延迟，持续异常时降低额度，只有在行为和系统压力同时恶化时才暂时拒绝。每一级都应设置冷却时间。
进行小范围验证。先对一类低风险请求启用规则，观察至少一个完整高峰周期。重点看排队长度、上游超时、带宽占用、缓存回源次数和正常请求完成比例，再调整上下限。
保留人工回退。动态策略出现误判时，应能切换到保守的固定阈值，并保留规则版本、触发原因和解除时间，便于追溯。

如果服务规模较小、请求模式稳定，固定阈值往往已经足够。建议按接口类别设置不同额度，而不是全站共用一个数字。如果业务存在明显峰谷、访问来源复杂，或后端资源对并发特别敏感，可以采用“固定底线加动态收紧”的组合：固定底线负责防止单一来源无限消耗，动态部分负责根据行为和负载改变处置强度。

无论采用哪种CC请求频率限制，都应明确放行、延迟、验证和拒绝的边界。规则数量并非越多越好，真正重要的是每条规则都有对应的业务理由、观察指标和回退方案。

不一定。只要按请求类型和识别维度拆分，并为正常峰值预留空间，固定方案也能稳定运行；误伤通常来自全站共用阈值或只按地址判断。

不必须。滑动窗口、令牌桶、分级冷却和负载联动，都属于可解释的动态策略，通常足以覆盖常见场景。

没有统一周期。流量稳定的系统可按月或按版本复核；活动频繁的系统应在每次业务高峰后检查，并根据实际压力调整。

应同时观察被拦请求、正常请求完成比例、上游超时、队列变化和用户反馈。单看拒绝数量，无法证明CC请求频率限制真正改善了服务。