CC攻击检测算法解析：基于时间窗口与滑动窗口的异常发现
摘要：## 当你的网站突然“卡死”，可能不是人多，而是它在捣鬼：聊聊时间窗口与滑动窗口怎么揪出CC攻击 前两天跟一个做电商的朋友吃饭，他愁眉苦脸地跟我吐槽：“奇了怪了，最近一到晚上八点，网站就卡得跟幻灯片似的，后台一看，CPU和带宽也没爆啊，用户也没投诉，但就…
当你的网站突然“卡死”，可能不是人多，而是它在捣鬼：聊聊时间窗口与滑动窗口怎么揪出CC攻击
前两天跟一个做电商的朋友吃饭，他愁眉苦脸地跟我吐槽：“奇了怪了，最近一到晚上八点，网站就卡得跟幻灯片似的，后台一看，CPU和带宽也没爆啊，用户也没投诉，但就是感觉不对劲。”
我问他：“你查过访问日志吗？是不是有一堆IP，跟上班打卡似的，固定时间就来，只访问你那个促销活动的详情页，别的啥也不干？”
他一拍大腿：“还真是！你怎么知道？”
我笑了笑，没直接回答。这种场景，做网络安全的朋友应该都不陌生。这十有八九，就是碰上CC攻击了。不是什么高级黑客炫技，更像是一种“使绊子”的流氓行为——用海量的、看似正常的请求，把你的服务器活活“累死”。
很多老板觉得，上了个WAF或者高防IP就万事大吉了。说句大实话，不少防护方案，PPT上吹得天花乱坠，真遇到针对性强的CC攻击，尤其是那种模仿真人行为的，第一波可能就露馅了。问题往往不是没上防护，而是防护的“眼睛”不够亮，发现不了那些藏在正常流量里的“演员”。
今天，咱就不聊那些空泛的“多层防护”、“智能清洗”了。咱们钻到引擎盖下面，看看最核心的“眼睛”——CC攻击检测算法，尤其是最常用、也最基础的两种思路：基于时间窗口和基于滑动窗口的异常发现。说白了，就是看系统怎么判断“这家伙不对劲”。
一、时间窗口：给流量“掐表考试”
想象一下，你们公司楼下的咖啡店在做“一分钟内喝完整杯美式，免单”的活动。正常人，哪怕再渴，一分钟猛灌一杯也够呛。但如果突然来了十个人，每个人都能在55秒内精准完成，店员会不会觉得不对劲？
这就是固定时间窗口检测最朴素的逻辑。
它怎么做？
系统会设定一个固定的“考试时间”，比如1分钟。然后，它死死盯住每一个来访的IP地址，数一数这个IP在这1分钟内，向同一个页面（比如 /product/123）发送了多少次请求。
怎么算异常？ 你提前会有一个“及格线”。比如，你觉得一个真实用户再疯狂，1分钟内刷新同一个商品页面30次顶天了（这已经够闲的了）。那么，阈值就设成30。一旦某个IP在1分钟内的请求数超过30，系统警报就响了：“报告！发现一个‘咖啡狂魔’，疑似作弊！”
它的好处是啥？
简单，直接，计算量小。在三里屯的深夜，如果突然涌进来一百个IP，每个都在疯狂请求你的登录接口，这种“暴力型”CC攻击，用固定时间窗口一抓一个准。配置起来也快，在Nginx里写几条limit_req规则就能顶一阵。
但问题也很明显——太死板了。 攻击者又不傻。如果我控制着肉鸡，让每个IP每分钟只发25次请求，刚好卡在你的阈值下面，你是不是就发现不了了？这就是“低速CC攻击”，像蚊子一样嗡嗡嗡，不一下子拍死你，但让你心烦意乱，资源慢慢被耗光。
更尴尬的是，万一你的产品真搞了个“秒杀”，大量真实用户就在那一分钟里疯狂点击（想想双十一零点），你这套规则可能就把自家用户给“误杀”了。
所以，固定时间窗口像是一把尺子，能量出明显的“巨人”，但对付那些刻意保持“标准身高”的敌人，或者应对自身业务的剧烈波动，就有点力不从心了。
二、滑动窗口：给流量做“动态心电图”
那怎么办？我们需要一个更聪明的“监考老师”。它不能只看某一分钟的 snapshot（快照），而得看一段连续的表现。这就是滑动窗口。
这个比喻可能更接地气：它不像固定窗口那样，每到整点就清零重算。它更像一个持续滚动的时间条，或者一个动态的“观察走廊”。
它怎么工作？ 假设我们设定一个5分钟的“大窗口”，但这个窗口不是固定的，而是每秒都在向前滑动。同时，我们关心的是最近1分钟（一个“小窗口”）内的表现。
系统会持续不断地计算：对于任何一个IP，在当前时刻往前推的这1分钟里，它发出了多少次请求。这个1分钟的窗口，随着时间一秒一秒地滑动，永远只关注最新的情况。
它的精妙之处在哪？ 它能平滑地处理请求的突发。比如，一个真实用户可能在10秒内因为手快点错了，连续发了10个请求，但之后50秒就安静了。在滑动窗口的视角里，这10个请求只会影响它们出现之后的那1分钟，一旦时间滑过，它们就从统计中移除了，不会像固定窗口那样“背锅”背满一整分钟。
对付“卡点型”攻击有奇效。 这是滑动窗口最漂亮的地方。假设攻击者研究透了你的固定窗口（1分钟阈值30次），他就可以在0分0秒到0分59秒发25次，停1秒，然后在1分01秒到1分59秒再发25次。在固定窗口看来，每个1分钟段都没超标，平安无事。
但在滑动窗口（假设窗口1分钟）看来，当时间滑到1分30秒时，它统计的是0分30秒到1分30秒这期间的请求。攻击者第一波的后半段请求（0分30秒-0分59秒）和第二波的前半段请求（1分01秒-1分30秒）正好落在这个滑动的1分钟里，加起来就超过了30次！警报瞬间拉响。
——看明白了吗？滑动窗口通过这种动态的、连续的观察，让那些试图在时间边界上“反复横跳”的攻击行为无所遁形。它捕捉的是一种持续性的异常趋势，而不是某个时间点的瞬时快照。
三、实战怎么选？别死磕算法，要懂业务
聊到这里，你可能会觉得滑动窗口明显更高级，那就全用滑动窗口呗？
别急，事情没那么简单。我见过不少站点，技术配置挺高级，问题恰恰出在配错了场景。
固定时间窗口，虽然笨，但它的优势是绝对的速度和低开销。对于那种追求极致性能、需要第一时间拦截明显暴力攻击的入口（比如API网关的第一层），或者在一些资源受限的边缘设备上，它依然是首选。它的逻辑简单到硬件芯片都能直接处理，速度快如闪电。
滑动窗口，更聪明，更精准，但代价是需要维护更复杂的状态（需要记录每个请求的时间戳来计算滑动区间），计算成本更高。它更适合放在业务逻辑层，或者作为第二道精细分析防线，用来揪出那些狡猾的“低速攻击”和“脉冲攻击”。
说白了，这俩不是二选一的关系，更像是“保安”和“侦探”的搭配。
一个经验之谈：你的检测阈值，绝不能是拍脑袋出来的。 你得去看自己业务的真实流量曲线。比如，你是一个内容站，凌晨3点的正常请求量可能是每分钟几次，但下午3点可能是每分钟几千次。你用同一个阈值去框，不是误杀就是漏杀。很多高防服务效果不好，根子就在这里——用的是一套通用的、死板的检测规则，根本不贴合你自家业务的“呼吸节奏”。
四、最后说点大实话
CC攻击检测，时间窗口和滑动窗口是基石，但现实中的攻防远比这复杂。现在稍微有点水平的攻击，都会用上“肉鸡代理池”轮换IP，模仿真人鼠标移动和点击间隔（他们管这叫“人性化脚本”），甚至专门绕过你只防护的 /login 页面，去攻击你耗资源的 /search 接口。
所以，千万别觉得懂了这两个算法就能高枕无忧。它们是你的“核心武器”，但要用好，还得：
- 结合业务画像：给正常用户（比如已登录用户、有购买记录的用户）更高的宽容度。
- 多层布防：在入口用固定窗口快速拦掉明显的垃圾流量，在内部用滑动窗口做精细分析。
- 关注资源消耗：有时候，检测请求频率不如直接监控服务器某个关键API的响应时间或CPU使用率来得直接。当响应时间异常飙升时，管你是什么攻击，先限流再说。
防护这件事，本质上是一场成本与体验的平衡。没有一劳永逸的银弹，最好的方案永远是：用最低的成本，增加攻击者的攻击成本。
行了，技术原理就聊这么多。下次再遇到网站莫名“卡顿”，别光重启服务器，记得去看看你的日志，是不是有一群“勤奋的访客”，正在用时间窗口和滑动窗口考验着你家的防护策略。心里，大概就有答案了吧？