CC攻击防御的核心难点不在于“扛住流量”，而在于如何从海量请求中识别出哪些是攻击、哪些是正常业务。业务接口访问频率统计正是做这件事的基础数据来源。没有精确到接口级别的频率统计，防御策略就只能靠猜，要么误杀正常用户，要么漏放攻击流量。很多团队在遭遇CC攻击时第一反应是上WAF或者加验证码，但如果连哪个接口正在被高频请求、请求来源分布、请求时间规律都说不清楚，这些防护手段的配置就缺乏依据，效果自然不稳定。
接口访问频率统计需要解决三个层面的问题：统计什么、怎么统计、统计结果怎么用。统计对象至少应当包含接口路径、请求方法、来源IP、会话标识、User-Agent、请求时间戳。只统计IP维度会漏掉代理池攻击，只统计接口路径又无法区分正常高频调用和恶意循环请求。实际生产环境中，攻击者往往会针对登录、短信发送、搜索、下单回调等消耗资源较大的接口发起精确打击，这些接口的访问频率基线通常远低于静态资源或普通查询接口，因此必须按接口分别建立频率模型。
频率统计的实现方式直接影响数据可用性。常见做法是在网关层或中间件层埋点，将每次请求的元数据异步写入日志系统或时序数据库。同步计数会拖慢请求响应，异步写入又可能在高并发下丢失数据。比较稳妥的方案是本地内存聚合加定时批量上报：每个服务节点先在本地对接口请求进行分钟级聚合，再每隔几秒将聚合结果推送到中心化存储。这样既能控制写入压力，又能保留足够的统计粒度。以Nginx为例，可以通过自定义日志格式配合access_log输出接口、状态码、响应时间、请求耗时等字段，再由日志采集组件实时解析。
log_format api_freq '$remote_addr - $request_method $uri - $status - $request_time - $http_user_agent'; access_log /var/log/nginx/api_access.log api_freq;
统计频率的窗口选择也很关键。固定窗口实现简单，但存在边界问题：攻击者可以在窗口切换瞬间发起双倍流量而不触发阈值。滑动窗口更平滑，但存储和计算成本更高。实际防御中常用的是滑动窗口加指数衰减，既保留近期请求的权重，又不会让历史数据长期影响判断。例如将过去60秒的请求按10秒粒度分桶，计算加权分数，越近的桶权重越高。这样攻击流量一旦出现，分数会快速上升；攻击停止后，分数也能较快回落。
接口频率统计不能只看总量，还要看分布特征。正常业务接口的请求频率通常随时间平稳变化，白天高、夜间低，且来源IP分散。CC攻击往往表现为短时间内请求量陡增，来源IP可能集中也可能分散，但请求路径高度集中。通过统计每个接口的请求量标准差、峰值与均值的比值、独立IP数与请求数的比值，可以自动发现异常。比如一个接口平时每分钟请求量在200到400之间波动，突然连续5分钟超过2000，且独立IP数没有同步增长，基本可以判定为攻击或异常调用。
频率统计结果要能直接驱动防御动作。比较实用的做法是建立分级响应机制：当某个接口的请求频率超过基线一定倍数时，先触发告警并自动提升该接口的日志采样率；超过更高阈值时，对该接口启用限速或人机验证；如果请求量继续攀升且来源IP高度集中，则对相关IP进行临时封禁。整个过程应当自动化执行，人工介入只处理边界情况。限速策略建议按接口加IP双维度设置，避免因为单个IP的高频请求影响其他正常用户访问同一接口。
统计数据的存储设计需要兼顾查询性能和保留周期。原始请求日志量太大，不适合长期保存，通常只保留7到14天用于回溯分析。聚合后的分钟级统计数据可以保留更久，用于建立长期基线。接口维度的基线数据建议按小时粒度存储，保留至少30天，这样既能反映工作日与周末的差异，也能捕捉业务增长带来的自然流量上升。如果业务有明显的大促或活动周期，还需要单独标注这些时间段，避免将正常活动流量误判为攻击。
在实现接口访问频率统计时，有几个容易忽略的细节。第一是请求体大小和响应体大小对资源消耗的影响，有些攻击通过发送超大请求体或请求返回超大响应来消耗带宽和内存，频率统计中应当记录这两个字段。第二是HTTP状态码的分布，攻击请求往往会产生大量4xx或5xx，正常业务中4xx比例通常较低，如果某个接口的404或500比例突然升高，可能是扫描或漏洞利用行为。第三是请求耗时分布，CC攻击即使被拦截，如果拦截逻辑本身消耗资源，响应时间也会明显上升，统计请求耗时可以帮助评估防御策略自身的性能开销。
对于已经接入微服务架构的业务，接口频率统计应当下沉到服务网格或API网关层，而不是依赖每个服务自行实现。统一在网关层统计可以覆盖所有进入系统的流量，避免因个别服务漏埋点导致统计盲区。网关层的频率统计还可以与认证鉴权模块联动，在请求到达业务服务之前就完成初步的异常识别。对于使用Kong、APISIX等开源网关的团队，可以通过插件机制实现接口级别的频率统计和限流，但要注意插件本身的性能损耗，高并发场景下建议使用Redis等外部存储做计数，而不是依赖网关本地内存。
频率统计的准确性还受到代理和CDN的影响。如果业务前面有CDN或负载均衡，直接取远端地址会拿到CDN节点IP而不是真实用户IP，导致所有请求看起来都来自少数几个IP。必须正确解析X-Forwarded-For或X-Real-IP头，并且只信任来自已知代理节点的这些头部信息，否则攻击者可以伪造头部绕过IP维度的统计。同时，CDN本身可能缓存了部分接口响应，这些请求不会到达源站，源站的频率统计只能反映穿透缓存的请求量，在分析时需要明确这一点。
接口访问频率统计的价值不仅在于防御CC攻击，还能帮助发现业务逻辑问题和性能瓶颈。通过分析各接口的请求量排名和变化趋势，可以识别出哪些接口被过度调用，是否存在重复请求或前端轮询过于频繁的情况。有些业务接口被攻击者利用进行撞库或刷单时，频率特征与正常用户有明显差异，例如同一账号在极短时间内从多个IP发起请求，或者同一IP在短时间内尝试大量不同账号。这些行为通过接口频率统计结合账号维度分析，往往能比单纯看IP频率更早发现。
建立接口访问频率基线需要持续运行一段时间，通常至少一到两周，才能覆盖完整的业务周期。基线数据要按小时和星期维度分别计算，因为工作日的访问模式与周末差异很大。对于新上线的接口，可以先设置一个相对宽松的初始阈值，随着数据积累逐步收紧。阈值设置过紧会导致正常用户频繁触发限流，过松则让攻击者有可乘之机。建议采用动态阈值机制，根据最近一段时间的实际流量自动调整，而不是使用固定数值。动态阈值可以用移动平均加上若干倍标准差来计算，当实时频率偏离移动平均超过设定倍数时触发告警。
统计数据的可视化也很重要，否则运维人员很难从大量数字中快速判断当前状态。建议为每个核心业务接口建立独立的监控面板，展示实时请求量曲线、历史基线区间、独立IP数、错误率、平均响应时间等指标。当请求量曲线突破基线区间时，面板上要有明显的颜色变化提示。对于安全团队来说，能够快速看到哪个接口正在被攻击、攻击流量来自哪些IP段、攻击开始时间和持续时间，是决定后续处置策略的关键信息。
最后需要强调的是，接口访问频率统计本身并不能完全防御CC攻击，它提供的是决策依据。真正的防御效果取决于基于这些数据构建的自动化响应机制是否足够快、足够准。统计数据的实时性决定了防御的响应速度，如果统计数据延迟超过30秒，攻击者就有足够时间造成影响。因此，频率统计链路的设计要尽量缩短从请求发生到数据可用的时间差，优先保证核心接口的统计实时性。同时，统计系统自身也要具备抗压能力，不能在攻击发生时因为统计量暴增而崩溃，否则防御体系就失去了眼睛。
