CC防护中针对低频慢速攻击的积压请求淘汰策略，核心就是在请求队列中设置合理的超时淘汰机制和动态权重评分体系，把那些看似正常但实际上在缓慢消耗服务器资源的请求识别出来并主动丢弃。低频慢速攻击不同于传统的高频CC，它每个请求的速率很低，可能每隔几秒甚至几十秒才发一个请求，但每个请求都会占用一个连接或线程，长时间积压下来就会把服务器的并发池撑满。解决这个问题不能只靠单一的频率阈值，必须从请求生命周期管理、动态评分、资源占用监控三个维度来构建淘汰策略。
什么是低频慢速攻击以及为什么传统CC防护容易漏掉它
低频慢速攻击是一种伪装性极强的CC攻击变种。攻击者不会像传统CC那样每秒发送几百上千个请求，而是把请求频率控制在每分钟几次到十几次的水平。比如每隔10秒发一个HTTP请求，每个请求都带着完整的Header、Cookie，甚至模拟正常用户的浏览行为。这种攻击的目的不是瞬间打垮服务器，而是通过长时间的连接占用，让服务器的线程池、连接池逐渐被耗尽。传统的CC防护规则通常基于"单位时间内请求次数超过阈值就拦截"的逻辑，比如每秒超过50次就触发防护。但低频慢速攻击的频率远低于这个阈值，所以很容易绕过检测。
更棘手的是，这类攻击往往会配合慢速读取请求体、慢速发送POST数据等手法。一个请求建立连接后，攻击者以极慢的速度发送数据，服务器就必须一直保持这个连接处于等待状态。如果有几千个这样的连接同时存在，服务器的可用连接数很快就会被占满，正常用户的请求就进不来了。
积压请求队列的核心淘汰机制设计
要对付低频慢速攻击，首先要在CC防护系统中建立一个积压请求管理队列。这个队列不是简单的FIFO先进先出，而是一个带有多维评分的优先级队列。每个进入队列的请求都会被赋予一个动态分数，分数由以下几个维度决定：请求频率历史、连接持续时间、数据传输速率、请求路径权重、客户端行为特征。当队列中的请求总数超过设定的容量上限时，系统会按照分数从低到高淘汰请求，分数最低的那些就是最可疑的低频慢速请求。
具体的淘汰策略可以分为三层：
第一层是时间维度淘汰。任何一个请求如果在队列中等待超过设定的最大等待时间（比如30秒），并且还没有被处理，就直接标记为可疑并淘汰。正常用户的请求通常在几百毫秒内就会被处理，而低频慢速攻击的请求往往会故意拖延。
第二层是资源占用维度淘汰。系统实时监控每个连接的资源消耗情况，包括CPU占用、内存占用、文件描述符占用。如果某个连接在很长时间内持续占用资源但几乎没有数据产出，就说明这个连接大概率是恶意的，应该被优先淘汰。
第三层是行为模式维度淘汰。通过分析请求的时间间隔规律、请求路径的重复性、Header的一致性等特征，给每个IP或Session打一个行为分数。行为分数持续偏低的请求会被逐步降低优先级，最终被淘汰。
动态评分算法的实现细节
动态评分是整个淘汰策略的核心引擎。一个实用的评分公式可以这样设计：
score = w1 * freq_score + w2 * duration_score + w3 * throughput_score + w4 * path_score + w5 * behavior_score
其中freq_score是频率得分，根据该IP过去一段时间内的请求频率计算，频率过低或过高都会降低得分。duration_score是持续时间得分，连接保持时间越长且没有实质性数据交互，得分越低。throughput_score是吞吐量得分，单位时间内的数据传输量越低，得分越低。path_score是路径权重得分，访问高价值路径（比如登录、支付接口）的请求权重更高。behavior_score是行为得分，综合多个行为指标计算。
权重系数w1到w5需要根据实际业务场景进行调优。一般来说，duration_score和throughput_score在对抗低频慢速攻击时权重应该更高，因为这两个维度最能区分正常用户和慢速攻击者。建议初始权重设置为w1=0.15, w2=0.3, w3=0.25, w4=0.15, w5=0.15，然后根据线上效果持续调整。
请求队列容量控制与分级处理
积压请求队列的容量设置非常关键。容量太小，正常的流量高峰也会触发大量淘汰，影响用户体验；容量太大，又起不到防护效果。建议采用分级队列的方式：设置一个主队列和多个子队列。主队列的容量根据服务器的最大并发连接数来设定，比如服务器最大支持10000个连接，主队列容量设为8000。当主队列快满时，新进来的请求进入子队列，子队列有更严格的淘汰策略和更短的超时时间。
分级处理的逻辑如下：主队列中的请求享有正常的处理优先级和较长的超时时间（比如60秒）；子队列中的请求超时时间缩短到15秒，并且评分阈值更低，更容易被淘汰；如果子队列也满了，就启动紧急淘汰模式，直接按照评分从低到高批量丢弃，确保系统不会被压垮。
针对不同协议的差异化淘汰策略
低频慢速攻击不仅仅发生在HTTP协议上，HTTPS、WebSocket、甚至一些自定义TCP协议都可能被利用。针对不同协议，淘汰策略需要做差异化处理。
对于HTTP/HTTPS请求，重点监控的是请求头完整接收后的等待时间和请求体的传输速率。如果一个请求的Header已经完整接收超过20秒但请求体还没有传完，或者请求体以低于100字节/秒的速度传输，就应该触发淘汰。
对于WebSocket连接，重点监控的是连接建立后的消息交互频率。正常的WebSocket连接会有定期的心跳包或数据交互，如果一个连接建立后超过30秒没有任何数据收发，就应该被标记为可疑。
对于TCP层面的慢速攻击，需要在更底层做监控，比如SYN包发送后不完成握手、或者握手完成后不发送任何数据。这类情况可以通过内核层面的TCP参数调优和连接跟踪表来配合处理。
实际部署中的关键参数调优建议
在实际生产环境中，以下几个参数需要重点关注和持续调优：
最大队列容量：建议设置为服务器最大并发连接数的70%-80%，留出余量给正常突发流量。
单请求最大等待时间：建议初始设为30秒，根据业务响应时间的P99值来调整，不能设得比正常业务响应时间还短。
评分刷新周期：建议每5秒刷新一次评分，太频繁会增加计算开销，太慢会导致反应滞后。
淘汰批量大小：每次淘汰不建议一次性丢弃太多请求，建议每次淘汰队列中分数最低的5%-10%，避免误杀正常用户。
IP级别的累计惩罚：如果同一个IP在短时间内被淘汰多次，应该直接将该IP加入临时黑名单，而不是继续让它的请求进入队列。
与其他防护手段的协同配合
积压请求淘汰策略不能孤立使用，必须和其他CC防护手段形成组合拳。比如在流量入口处做IP信誉检测，把已知的恶意IP直接在队列之外就拦截掉，减轻队列压力。在应用层做请求指纹识别，通过分析请求的指纹特征（比如TLS指纹、HTTP/2指纹等）来辅助判断。在系统层做内核参数优化，比如调整tcp_syn_retries、tcp_keepalive_time等参数，从底层减少慢速连接的影响。
另外，建议建立一套实时监控大盘，把队列容量使用率、淘汰请求数量、各维度评分分布、被淘汰IP的地理分布等指标可视化展示出来。运营人员可以通过这些数据快速判断当前是否正在遭受低频慢速攻击，以及淘汰策略的效果如何。
常见误区和注意事项
很多团队在实施积压请求淘汰策略时容易犯几个错误。第一个是把超时时间设得太短，导致正常用户在网络稍微慢一点的情况下就被误杀。第二个是只看单一维度，比如只看请求频率，忽略了连接持续时间和数据传输速率，结果低频慢速攻击还是能混进来。第三个是淘汰策略太激进，一次性丢弃大量请求，导致服务出现抖动。正确的做法是渐进式淘汰，先降低优先级，再缩短超时，最后才丢弃，给系统一个缓冲的过程。
还有一点很重要，淘汰策略需要定期复盘和更新。攻击者的手法也在不断进化，今天有效的参数和权重，明天可能就不够用了。建议至少每周 review 一次淘汰策略的效果数据，每月做一次全面的参数调优。
总结
CC防护中针对低频慢速攻击的积压请求淘汰策略，本质上是一套基于多维评分的智能队列管理系统。它通过时间、资源、行为三个维度的综合评估，把那些伪装成正常用户但实际上在缓慢消耗服务器资源的请求识别出来并主动淘汰。关键在于动态评分算法的合理性、队列容量的科学设置、分级处理机制的灵活性，以及与其他防护手段的协同配合。只有把这些环节都做到位，才能真正有效地抵御低频慢速CC攻击，同时又不影响正常用户的访问体验。
