流量型攻击冲的是带宽和链路，特征很明显——监控上流量曲线一下子顶到顶上。CC 攻击不一样，它用大量看起来完全合法的请求，去占满应用的处理能力。表现出来是带宽看着还挺正常，页面却开始转圈，接口响应从几十毫秒变成几秒，数据库连接池满了之后连后台都进不去。名字里的 Collapsar 说的就是这种效果：把服务压到塌陷。
它挑的目标通常有几个共同点：不需要登录就能访问，参数比较复杂，或者背后会触发数据库的重查询。搜索接口、列表分页、报表导出、短信验证码、登录接口，都是高发位置。
第一步是探测。攻击者会先看看哪些页面是动态的、哪些接口参数多、哪些功能不需要身份验证，顺便摸一下网站的响应时间基线，方便后面判断施压效果。第二步是准备资源，租一批云主机或者控制一批代理，把请求源分散开。第三步才开始加压，往往只集中打少数几个接口，参数略作变化，有时还会带上正常的 Cookie 和浏览器标识，甚至模拟一条完整的点击路径，把自己伪装成真实用户。第四步根据效果调整强度，页面越慢，说明越接近目的。
先看日志画像，而不是急着封 IP。要看的几项是：来源地址的分散程度，浏览器标识是不是高度集中，请求路径是不是集中在少数几个接口，来源页是不是普遍为空，参数有没有共同的规律。这些特征能帮你区分是攻击、是采集，还是某个客户端版本出了问题在疯狂重试。
临时处置可以从几个方向同时做：给问题接口加上频率限制；把已经确认的恶意来源段拉黑；对可疑请求先要求人机校验；把静态资源和动态请求分开，能缓存的全部走缓存。有两件事建议不要做——直接封掉整段运营商地址会误伤大量真实用户，把接口整个关掉造成的业务损失往往比攻击本身更大。
应急只能顶住当下，长期要看架构。页面能静态化就静态化，能缓存就缓存，源站压力立刻就会下来。动态接口要分级，正常用户不会一秒请求几十次同一个查询接口。数据库连接池要设上限，配上慢查询保护，避免一个接口把连接占满，把整个站点拖垮。还有一个思路是把攻击者便宜的资源对应的处理变贵，反过来把自己昂贵的处理变便宜，比如把复杂统计改成预计算，把实时查询改成定时生成。
防护规则写得粗，误伤和漏放会同时出现。判断一个请求该不该限速，可以叠加几个条件：单位时间内同一来源的请求数，同一会话在短时间内访问的接口数量，以及请求参数的相似度。正常用户不会在一分钟里用几乎相同的参数反复请求同一个搜索接口，而攻击脚本恰恰是这样做的。
另一个容易被忽略的点是缓存键的设计。如果缓存键里带上了随机的查询参数，每个请求都会绕过缓存打到源站，等于缓存白配了。可以在入口把无意义的参数过滤掉，让攻击者构造出的每个请求都落到同一份缓存上，源站的处理压力自然就下来了。验证限速是否真的生效，不能只看拦截数量，还要看源站的处理指标有没有跟着回落。
施压的来源也不是一成不变。有的会定期更换出口地址，有的会交替使用不同的浏览器标识，单纯按来源或标识去匹配很快会失效。相对稳定的特征是行为本身：请求的节奏、参数的形态，以及访问路径的重复程度。把判断建立在这些特征上，比追着不断变化的标识跑更有效。
看源站的处理指标有没有回落：处理器占用、数据库连接数、接口平均响应时间、错误率。同时一定要看业务指标，比如下单量、登录成功率。两个方向一起看，才能区分是挡住了攻击，还是把用户也一起挡住了。
售后客服
企业微信
