防护CC攻击业务接口限流粒度设计

防护CC攻击时，业务接口限流粒度的设计往往决定了防御效果和误伤率之间的平衡。很多团队一上来就按IP限流，结果要么被大规模代理池绕过，要么把正常的企业出口流量误封。真正有效的做法是把限流粒度拆成多个维度，从全局、接口、用户标识、设备指纹到行为特征逐层收敛，而不是指望单一维度解决所有问题。下面直接讲具体的设计思路和落地方法。

CC攻击的本质是消耗服务器资源，尤其是那些高消耗接口，比如涉及数据库查询、复杂计算、验证码发送、短信下发、文件导出等操作。攻击者会模拟正常请求，但频率远超真实用户。因此限流粒度的第一层应该放在“接口级别”，而不是全局级别。全局限流容易造成一个接口被攻击时，其他正常接口也受到影响。接口级别的限流阈值要根据该接口的真实承载能力来设定，比如一个验证码发送接口，正常业务下每秒可能只有几十次请求，那么阈值就设为每秒100次左右；而一个静态资源查询接口，可能每秒能承受几千次，阈值可以放宽到5000次。这样攻击者即使打满某个接口，也不会拖垮整个服务。

单纯按IP限流在IPv4环境下还有一定效果，但IPv6普及后，攻击者可以轻松使用海量地址，按IP限流基本失效。更现实的做法是把IP作为基础维度，但阈值要设置得相对宽松，避免误伤企业NAT出口或移动网络共享出口。例如，一个IP在10秒内对某个接口请求超过200次才触发限制，而不是一上来就限制每秒10次。同时，IP限流要区分“软限制”和“硬限制”。软限制是触发后人机验证或延迟响应，硬限制才是直接丢弃请求或返回429状态码。很多业务场景下，软限制能有效过滤掉自动化脚本，同时保留真实用户的访问能力。

如果业务有登录态，那么用户ID、手机号、邮箱、设备ID等唯一标识是最值得依赖的限流维度。攻击者可以更换IP，但很难批量伪造大量有效的用户标识。设计时要注意，用户标识限流不能只看“请求次数”，还要结合“行为序列”。比如同一个用户ID在1分钟内请求了50次验证码接口，这显然不正常，但如果这50次请求分散在不同的业务操作中，比如浏览商品、查看订单、修改资料，那么就不应该被简单限制。因此用户标识限流最好是按“接口+时间窗口+行为类型”组合来判定。对于未登录用户，可以用设备指纹或浏览器指纹作为临时标识，虽然指纹可以被伪造，但配合其他维度仍然有不错的识别率。

很多CC攻击工具是脚本化的，它们的HTTP头、TLS指纹、JavaScript执行环境往往和真实浏览器有差异。通过采集这些特征生成设备指纹，可以在不依赖IP和用户标识的情况下识别出大量自动化流量。具体做法是在业务接口前部署一层轻量级的指纹采集脚本，将指纹作为限流键的一部分。例如，同一个设备指纹在5分钟内对某个接口请求超过30次，就触发限制。这个维度的优势在于，攻击者即使更换IP和用户标识，只要设备指纹不变，依然会被识别。需要注意的是，设备指纹的生成逻辑要定期更新，因为攻击者也会分析指纹算法并尝试绕过。

有些CC攻击不是高频请求，而是模拟真实用户的节奏，比如每5秒请求一次，但攻击者控制了数千个节点同时发起，整体压力依然很大。这种情况下，单纯的频率限流很难触发。此时需要引入行为特征分析，比如请求间隔的规律性、请求路径的跳转逻辑、鼠标移动轨迹、页面停留时间等。一个真实用户在页面上的操作是随机的、有思考时间的，而脚本的请求间隔往往过于均匀。可以在服务端记录每个会话的请求时间戳，计算间隔的方差，如果方差极小，说明很可能是自动化工具。这种维度适合作为“加分项”，而不是独立限流依据，因为它需要一定的数据积累才能做出判断。

实际落地时，不要只用一个维度，而是把多个维度组合起来，形成分层防御。第一层是网络层，基于IP和端口做粗粒度限制，快速丢弃明显的洪水流量；第二层是应用层，基于接口和用户标识做细粒度限制，保护高消耗接口；第三层是行为层，基于设备指纹和行为特征做智能识别，过滤掉模拟真实用户的攻击。每一层的阈值和策略要独立配置，并且支持动态调整。比如当某个接口的响应时间突然变长，或者错误率上升，就自动收紧该接口的限流阈值，同时放宽其他正常接口的限制。这种动态调整机制能有效应对攻击手法的变化。

限流粒度的实现离不开高效的计数器存储。对于单机部署，可以用内存计数器，比如Guava RateLimiter或自研的滑动窗口计数器。对于分布式部署，需要用Redis或类似的集中式存储来保证计数的一致性。Redis的INCR和EXPIRE命令可以方便地实现固定窗口计数，但固定窗口存在临界突刺问题，比如在窗口切换的瞬间，攻击者可以打出双倍流量。更好的做法是用滑动窗口或令牌桶算法。滑动窗口可以用Redis的ZSET实现，每个请求的时间戳作为score，定期清理过期数据。令牌桶则可以用Lua脚本在Redis中原子执行，避免并发问题。下面是一段基于Redis的滑动窗口限流Lua脚本示例：

-- KEYS[1] 限流键名
-- ARGV[1] 窗口大小（秒）
-- ARGV[2] 最大请求次数
-- ARGV[3] 当前时间戳（毫秒）
local key = KEYS[1]
local window = tonumber(ARGV[1])
local max_req = tonumber(ARGV[2])
local now = tonumber(ARGV[3])
local clear_before = now - window * 1000
redis.call('ZREMRANGEBYSCORE', key, 0, clear_before)
local count = redis.call('ZCARD', key)
if count < max_req then
    redis.call('ZADD', key, now, now .. '-' .. math.random())
    redis.call('PEXPIRE', key, window * 1000)
    return 1
else
    return 0
end

这段脚本能精确控制每个时间窗口内的请求数量，并且原子执行，适合高并发场景。实际使用时，限流键的命名要包含粒度维度，比如“ratelimit:api:sms:userid:12345”表示对用户12345在短信接口上的限流。

很多团队在部署限流后，发现正常用户被大量拦截，客服压力剧增。问题往往出在阈值设置过于激进，或者限流维度过于单一。控制误伤率的关键是“分级响应”和“白名单机制”。分级响应是指当触发限流时，先返回一个带有重试提示的响应，或者弹出验证码，而不是直接封禁。白名单机制则要覆盖已知的合作伙伴、内部系统、搜索引擎爬虫等合法来源。对于搜索引擎爬虫，可以通过反向DNS解析和User-Agent校验来识别，避免误伤。另外，限流策略要支持按时间段调整，比如夜间流量低，阈值可以适当放宽，白天业务高峰则收紧，但收紧幅度不能超过正常流量的两倍。

没有监控的限流等于盲人摸象。每个限流维度都要有独立的计数器，记录触发次数、拒绝次数、通过次数，并且把这些数据推送到监控系统。当某个维度的拒绝率突然升高，就要检查是攻击还是误伤。日志方面，要记录被限流请求的完整上下文，包括IP、用户标识、设备指纹、请求路径、请求参数摘要等，方便事后分析。这些日志还可以用于训练行为识别模型，进一步提升限流的精准度。一个实用的做法是每天分析被限流请求的样本，找出攻击者的新特征，然后更新限流规则。

从实际效果和落地成本来看，接口级别的限流是必须最先做的，因为它直接保护了高消耗资源。其次是用户标识维度，这是最精准的粒度。IP维度作为辅助，设备指纹和行为特征作为进阶手段。所有维度要联动，而不是各自为战。限流策略要支持动态调整，并且要有完善的监控和日志体系。最后，任何限流方案都要经过压测和灰度验证，确保在真实攻击下能有效拦截，同时不影响正常业务。