CC防护中根据用户登录状态给予不同的限流权重

在CC防护（Challenge Collapsar）体系中，根据用户登录状态给予不同的限流权重，本质上就是对"已认证用户"和"未认证匿名用户"执行差异化的访问频率控制策略。具体做法是：已登录用户享受较高的请求配额（比如每秒20次），而未登录的匿名访问者则被压缩到极低的配额（比如每秒2-3次），甚至直接触发人机验证。这种策略的核心逻辑很简单——真实用户的行为模式通常是低频、有节奏的，而CC攻击的特征是高频、无规律的批量请求，且攻击者绝大多数情况下不会携带有效的登录态。把限流权重和登录态挂钩，能在不影响正常用户体验的前提下，大幅提升对恶意流量的拦截效率。

很多人在做CC防护时，习惯用"一刀切"的限流规则，比如统一设定每IP每秒10次请求。这种方式看似公平，但实际上会误伤正常用户（尤其是多人共享出口IP的场景），同时对分布式CC攻击几乎没有效果。而引入登录态作为权重因子后，防护策略就有了"智能分层"的能力，这才是现代WAF和应用层防护应该具备的基本素质。

CC攻击的本质是利用大量请求耗尽目标服务器的连接资源或计算资源。攻击者为了规避传统的IP限流，通常会采用以下手段：分布式肉鸡、IP轮换、请求头伪装等。在这种情况下，单纯基于IP的限流很容易被绕过。

但有一个事实是攻击者很难模拟的——有效的用户登录态。登录态通常绑定了Session、Token、Cookie等凭证，这些凭证的获取需要真实的账号体系支撑。攻击者如果要为每个请求都携带有效登录态，成本会急剧上升。因此，把登录态作为限流权重的判断依据，相当于给防护系统增加了一道"身份验证层"。

从业务角度看，已登录用户往往是平台的核心价值用户，他们的访问体验直接影响留存和转化。对这部分用户放宽限流，既是技术策略，也是业务策略。而未登录用户中，很大比例可能是爬虫、扫描器或者攻击流量，对他们收紧限制，几乎不会造成业务损失。

要根据登录状态做差异化限流，第一步是准确识别用户是否处于登录态。常见的识别方式有以下几种：

第一种是Cookie/Session检测。用户登录后，服务器会下发SessionID或Token，后续请求携带这些凭证即可判定为已登录。这是最传统也最可靠的方式。

第二种是JWT Token解析。现代前后端分离架构中，登录后会返回一个JWT，前端在请求头中携带Authorization字段。防护层解析这个Token的有效性和过期时间，即可判断登录状态。

第三种是行为特征辅助判断。有些场景下用户可能未携带明确的登录凭证（比如API调用），这时可以结合请求频率、访问路径、User-Agent等特征做辅助判断，但这种方式精度较低，适合作为补充手段。

// 示例：基于登录态的限流权重判断逻辑（伪代码）
function getRateLimitWeight(request) {
    if (hasValidSession(request) || hasValidToken(request)) {
        return {
            weight: 1.0,      // 满权重
            maxRequests: 20,  // 每秒20次
            burst: 40         // 突发40次
        };
    } else {
        return {
            weight: 0.15,     // 15%权重
            maxRequests: 3,   // 每秒3次
            burst: 5          // 突发5次
        };
    }
}

有了登录态识别能力之后，接下来就是设计具体的权重策略。这里给出一套经过实践验证的分层方案：

第一层：已登录活跃用户（权重1.0）

这类用户指的是在过去30分钟内有过有效交互行为的登录用户。他们的限流阈值设为正常水平，比如每秒15-25次请求（根据业务类型调整）。同时允许一定的突发流量，比如短时间内可以到正常阈值的2倍，避免用户快速操作时被误拦。

第二层：已登录但长时间未活跃用户（权重0.5）

这类用户虽然有登录态，但很久没有操作了（比如超过2小时未活动）。可能是账号被盗用，也可能是用户遗忘了登录状态。对这类用户适当降低权重，比如限制到每秒8-10次，同时触发二次验证（短信验证码或滑块验证）。

第三层：未登录但携带部分凭证的用户（权重0.3）

有些请求可能携带了过期的Token或者不完整的Cookie。这类请求不能直接判定为攻击，但也不能给予高权重。建议限制到每秒5次，并引导用户重新登录。

第四层：完全匿名未登录用户（权重0.1）

没有任何登录凭证的请求，直接给予最低权重。每秒限制2-3次，超过则直接返回429状态码或者触发人机验证页面。如果短时间内同一IP段出现大量此类请求，直接加入临时黑名单。

在落地这套策略时，有几个坑必须提前规避：

第一，不要把登录态作为唯一判断依据。有些正常用户可能因为网络问题丢失了Cookie，或者使用了隐私模式浏览。如果仅凭登录态就一刀切地限流，会造成大量误杀。建议设置"降级通道"——当用户触发低权重限流时，提供人机验证作为解锁方式。

第二，注意共享IP场景。公司网络、学校网络、运营商NAT等场景下，大量用户共享同一个出口IP。如果这些用户都未登录（比如访问公开页面），会被集体限流。解决办法是结合指纹识别（浏览器指纹、设备指纹）做更细粒度的区分，而不是单纯依赖IP+登录态。

第三，权重值需要动态调整。不同业务场景的正常请求频率差异很大。电商大促期间，已登录用户的请求频率可能是平时的5-10倍，如果权重不动态调整，正常用户也会被误拦。建议建立基线监控，根据历史数据自动调整各层级的阈值。

// 示例：动态权重调整逻辑（伪代码）
function adjustWeightByBaseline(userType, currentLoad) {
    let baseWeight = getBaseWeight(userType);
    let loadFactor = currentLoad / normalLoad;
    
    if (loadFactor > 2.0) {
        // 高负载时适当收紧
        return baseWeight * 0.8;
    } else if (loadFactor < 0.5) {
        // 低负载时适当放宽
        return baseWeight * 1.2;
    }
    return baseWeight;
}

第四，做好日志和告警。每一次限流决策都应该记录日志，包括用户标识（脱敏后）、请求时间、判定结果、触发的权重层级等。这些数据不仅用于事后分析，更是优化策略的核心依据。如果发现某个权重层级的误杀率偏高，就需要及时调整。

登录态差异化限流不是孤立存在的，它需要和其他CC防护手段形成组合拳：

首先是IP信誉库。结合第三方IP情报数据，对已知的恶意IP段直接拦截，不需要走登录态判断流程，节省计算资源。

其次是请求特征分析。对请求的URI模式、参数结构、Header组合做规则匹配，识别典型的CC攻击特征（比如大量请求同一个接口、参数高度相似等）。

再次是JS挑战页。对于触发低权重限流的未登录请求，可以返回一段JavaScript挑战代码，要求客户端执行后才能继续访问。这能有效过滤掉大部分自动化攻击工具。

最后是分布式限流协调。如果你的服务部署在多个节点上，每个节点独立做限流会导致整体策略不一致。需要通过Redis等中间件实现全局计数器，确保权重策略在集群层面统一执行。

这套策略上线后，需要重点关注三个指标：

一是误杀率。统计被限流的请求中，最终通过人机验证确认为正常用户的比例。如果超过5%，说明权重设置过于激进，需要回调。

二是拦截率。统计被限流或拦截的请求中，确认为攻击流量的比例。如果低于60%，说明策略可能被攻击者摸透了，需要增加随机因子或调整规则。

三是用户体验指标。重点监控已登录用户的请求响应时间和成功率，确保放宽限流没有带来性能问题。同时关注未登录用户的页面加载速度，避免因为过度限流导致SEO受影响。

建议每周做一次策略复盘，根据最新的攻击样本和业务数据迭代权重参数。CC攻击的手法在不断进化，防护策略也必须保持动态更新。

根据用户登录状态给予不同的限流权重，是CC防护从"粗放型"走向"精细化"的关键一步。它的核心价值在于：用身份认证作为信任锚点，把有限的防护资源优先分配给高价值用户，同时对低信任流量进行强力压制。落地时要注意避免单一维度判断、关注共享IP场景、建立动态调整机制，并与IP信誉、JS挑战、分布式协调等手段协同使用。这套策略不复杂，但需要持续运营和数据驱动的优化，才能真正发挥出应有的防护效果。