单纯扩容只是在给攻击者递弹药，应用层防护才是真正省钱且有效的解法因为绝大多数攻击流量根本到不了带宽层，它们消耗的是应用的计算资源，而防护要做的是把这些请求挡在门外。
为什么扩容越来越贵，但攻击一点没少
很多团队的第一反应是“被打就加带宽”，结果发现钱花了，攻击还在，原因在于攻击者打的根本不是带宽，而是应用的处理能力，一个普通的HTTP请求只需要几十毫秒的处理时间，但如果每秒来几万个，CPU、内存、数据库连接池、后端线程全部被占满，网站就“假死”了，你扩容买的服务器、带宽、数据库读写能力，全被这些垃圾请求消耗掉,真正的用户反而进不来。
应用层防护的逻辑完全不同，它不靠堆资源硬扛，而是在流量到达后端之前，先做一层智能识别，打个比方，扩容就是你把大门拆了，让所有人都能进来，结果小偷也进来了；而应用层防护是在门口装一个保安，只放行真正的客人，其他人通通拦在外面，处理一个请求的成本远高于拦截一个请求的成本，所以防护每拦截一个攻击请求,都是在省下后端N倍的资源开销。
有一个很容易忽略的事实：多数攻击流量具备明显特征，比如同一个IP地址高频访问、请求路径集中在某个API接口、User-Agent字段异常、行为模式不符合真实用户，这些特征在单纯扩容的场景下根本无法被利用，因为流量全被后端硬吃了，而在应用层防护中，规则一旦生效，平均一个请求的判断时间只需要几毫秒,相当于后端处理一个正常请求的零头。
应用层防护和单纯扩容哪个省钱
做技术选型时，团队最关心的是成本，但多数人只算了“一次性买服务器”的钱，没算长期被打的成本，单纯扩容的模式是：每月交固定费用比如买了一台8核16G的云服务器，再配20M带宽，然后攻击者每天都在测试你的上限，流量一到峰值，你就得加配置，加了配置，攻击者再加流量，这种军备竞赛没有终点,费用却逐月递增。
应用层防护的成本结构则是“基础防护+弹性按量”，基础防护规则部署一次，长期有效；遇到突发攻击时，临时调度清洗节点，按实际流量计费，最关键的是，绝大多数攻击在入口就被拦掉了，后端资源不消耗，也就没有持续的扩容需求,两相对比：
| 成本项 | 单纯扩容 | 应用层防护 |
|---|---|---|
| 服务器投入 | 持续增加，按月付费 | 一次部署，无需频繁升级 |
| 带宽成本 | 被攻击流量大量占用，费用陡增 | 清洗节点分流，带宽消耗小 |
| 运维人工 | 每轮攻击都要手动排查、重启、扩容 | 规则自动拦截，基本无需人工干预 |
| 业务损失 | 攻击期间服务不可用，订单流失 | 用户无感知，业务持续在线 |
尤其对中小团队来说，运维人力本身就是一笔隐性成本，被DDoS攻击后，半夜爬起来处理问题的场景，做过运维的朋友都懂，业内专家指出，中小企业平均处理一次攻击至少需要半天时间完成排查、清洗流量和恢复服务，而应用层防护方案部署好之后，大部分攻击在分钟内就能被自动化解,省下的人力成本远比防护本身的价格高。
应用层防护价格贵不贵：算完总账再下结论
很多团队在咨询报价时会被“每年几万块”的价格劝退，转头买了更便宜的高防服务器，但如果算总账，单纯扩容的综合成本通常更高，以一台中等配置的云服务器为例，年费用已经不小，再加带宽包年、数据库扩容、防DDoS高防包，各项叠加很快就突破防护方案的预算，更不用提攻击造成的业务中断损失一个电商网站在大促前夕挂掉两小时,损失可能抵得上十年防护费用。
行业共识认为，评估应用层防护方案时，要同时考虑防御效果、接入成本、误杀率三个维度，而不是只看标价，便宜的方案如果不支持精细化的规则配置，容易把正常用户也拦掉；而稳定成熟的防护方案，即使价格高一些，长期算下来依然是更优解，例如电商大促、秒杀活动、新游戏上线这类高并发场景，扩容是永远填不满的坑,防护才是从源头解决问题的办法。
地域差异也会影响成本判断，比如在成都、西安等二线城市，团队的人力成本相对较低，很多企业倾向于自己搭nginx规则来“手动防护”，结果发现规则写得不完善，攻击者一换姿势就绕过，身边做运维的朋友就遇到过这种场景，自己折腾了两周，最后还是选择了现成的防护方案，中间的试错成本远超预期，与其踩坑后再补救,不如一开始就把防护纳入技术预算。
网站被攻击了怎么办：一套可落地的部署顺序
如果你是第一次处理应用层攻击,以下步骤可以直接照着做：
第一步：快速判断攻击类型
先看请求日志，分辨是DDoS（流量型）、CC（连接数型）还是API滥用（业务逻辑型），一个简单方法是查看服务器负载和带宽占用情况：带宽跑满但CPU很低，可能是DDoS；CPU和数据库连接数飙升但带宽正常，大概率是CC，域名接口被频繁调用、参数值异常，则是API滥用，判断不清楚时，先临时启用全局限速,保住服务不挂。
第二步：启用基础限流规则
在Nginx层面快速临时限制，
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;
server {
location /api/ {
limit_req zone=mylimit burst=20 nodelay;
proxy_pass http://backend;
}
}这段配置限制单个IP每秒10个请求，超出部分直接返回503，注意，限流规则只能缓解攻击，不能彻底解决，因为攻击者会改用分布式IP继续访问，接下来需要配置更精细的应用层规则，比如对特定路径的请求频率、参数合法性校验和User-Agent过滤。
第三步：部署智能防护规则
这一步需要结合业务特征，比如登录接口连续失败5次就锁定IP，商品查询接口对同一用户限速，文件下载路径限制单连接速率，还可以启用人机校验，通过JavaScript挑战或滑块认证区分真实用户和脚本，相关配置可以参考主流WAF产品的通用策略模板，大部分场景下不需要完全从零开始，云厂商的Web应用防火墙控制台里也提供了开箱即用的规则组,勾选后就能生效。
第四步：验证效果并持续调优
部署之后，用压测工具模拟真实用户请求（不含攻击流量，只测正常访问），确认服务响应正常、误杀率低，同时观察攻击日志的拦截量，如果发现正常用户被误拦，则调整阈值或增加白名单，好的防护方案需要持续迭代，每次攻击都要复盘：攻击者用了什么手法、规则是否覆盖、如何提前拦截。
长尾词补充：防护与扩容在真实场景中的选择
做技术决策还要看具体业务场景，如果是一个以图片和视频为主的网站，攻击流量主要集中在带宽层，高防服务器拖带宽的效果更直观；但如果是API接口、小程序后端、物联网设备的上报服务，攻击针对的是业务逻辑，单纯扩容必然吃大亏，又比如做海外业务的团队，节点分散在不同地域，全球负载均衡加分布式应用层防护组合是常见做法，这套组合的成本有时候比单一高防IP还低，简而言之，预算有限的中小团队以及重视业务连续性的中大型平台，都适合采用应用层防护方案,具体选择取决于攻击类型和业务特征。
Q&A：关于应用层防护和单纯扩容的常见问题
应用层防护和网络层WAF有什么区别？
WAF侧重分析HTTP/HTTPS流量，阻断SQL注入、XSS、恶意爬虫等应用层攻击，防护的是“请求内容是否合法”；而应用层防护还包括限速、会话追踪、人机校验等行为分析能力，解决的是“请求是否符合真实用户行为”的问题，两者可以叠加部署，但底层原理和适用场景不同,不能简单替换。
部署应用层防护会影响访问速度吗？
从用户侧看，绝大多数请求在毫秒级内完成判断，延迟增加通常在几毫秒以内，普通用户基本无感知，少数复杂规则（如异步JS挑战）会增加百毫秒级别的延迟，但只触发在可疑请求上，不影响正常用户，国内云厂商的接入节点分布广泛,就近转发反而可能改善跨地域访问的延迟问题。
为什么说扩容到最后必然撞墙？
因为攻击成本远低于扩容成本，攻击者生成恶意请求几乎不需要费用，而你购买服务器、带宽、数据库实例每一分钟都在花钱，更麻烦的是，扩容意味着更多逻辑节点，攻击面也在同步扩大，运维复杂度提升，问题排查难度增大，从长远看，这是一场永远追不上敌人的竞赛，而应用层防护把战场从资源消耗转移到了智能识别,从根源上改变了游戏规则。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/787004.html
