一个打的是管道宽度和协议栈，另一个打的是业务等待队列与数据库连接，防御动作一旦混用，钱花了、策略上了，业务照样中断。
很多运维看到流量突然上涨,第一反应是拉带宽、上高防，但如果攻击发生在应用层，带宽根本没满，拉再大的管子也白搭，下面把两个战场拆开看。
应用层攻击和网络层攻击有什么区别？先分清两个消耗模型
网络层泛洪像有人开卡车堵住小区大门,门外的路再宽也进不去，应用层逻辑耗尽像一群人冲进超市，把每个收银台都占着，不结账也不走，真正要买单的顾客全卡在门口，前者堵的是入口，后者耗的是内部服务能力。
网络层泛洪：拼的是管道，不是智商
这类攻击不关心业务逻辑,只关心能不能把入口塞满，据工信部相关通报，反射放大攻击是流量型DDoS的一种常见形式。
- 典型类型：SYN Flood、UDP Flood、ICMP Flood、NTP/DNS/Memcached反射放大
- 消耗对象：带宽、PPS、防火墙会话表、内核协议栈
- 特征：机房出口拥塞，正常包大量丢包，服务器自身CPU不一定高
- 判断命令：
sar -n DEV 1 10看网卡速率，netstat -an | grep SYN_RECV | wc -l看半开连接数 - 防御思路：BGP高防清洗、黑洞路由、协议限速、开启
net.ipv4.tcp_syncookies=1
应用层逻辑耗尽：打在业务最脆弱的等待队列上
这类攻击的每个请求都完成了TCP三次握手,甚至带着正常User-Agent，它不打带宽，打的是Web服务器线程、数据库连接池、Redis连接这些有限资源。
- 典型类型：CC攻击、慢速HTTP POST、慢速读取、针对搜索或登录接口的刷请求
- 消耗对象：Nginx worker线程、MySQL连接数、Redis连接、业务CPU
- 特征：带宽曲线平稳，但页面响应时间不断拉长，数据库活跃会话持续升高
- 判断命令：
SHOW PROCESSLIST;看SQL会话，awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20看URI请求集中度 - 防御思路：WAF七层CC防护、频率限制、人机验证、缓存、SQL优化
为什么总被混为一谈
因为两者都叫DDoS,来源都是大量请求，业内专家指出，把CC攻击简单归为DDoS流量攻击，是防御体系中常见的分类错误，网络层看的是流量图，应用层看的是业务指标，混在一起判断会延误处置。
网站被CC攻击时，高防IP为什么经常看起来没生效
很多网站负责人买了高防IP,结果CC攻击一来，页面照样转圈，原因在于，基础版高防IP的清洗策略主要针对网络层流量型攻击，CC攻击的每个请求都像正常用户，清洗设备很难只凭包特征拦截，只有开启七层CC防护模块，才能对URI访问频率、Referer、Cookie、浏览器指纹做组合判断。
高防IP价格一般多少，和这个有什么关系
高防IP价格差异很大,不能只按防御峰值比较，部分基础版高防IP只含网络层清洗，七层CC防护需要单独购买或升级，这就解释了为什么同样标称300G防御，有的能扛住CC，有的不能，采购时要问清楚：是否包含URI频率限制、验证码跳转、智能会话跟踪。
打开七层防护前后的差别
- 未开七层防护：清洗设备只看包速率和连接数，对正常HTTP请求不做内容识别
- 开启后：对单IP的请求频率、UA、Referer、Cookie进行组合判断
- 配置重点：
limit_req_zone限速、验证码验证、动态URI保护 - 误伤控制：设置白名单，搜索引擎爬虫和API调用方要放行
浙江高防服务器租用哪家好，关键看两类战场防御配比
浙江机房靠近长三角用户群,本地BGP线路时延低，互联网企业密集，但选高防服务器不能只问“多少G防御”，要问“七层CC防护策略是否包含”。
- 看机房是否支持BGP多线,且到浙江本地用户平均时延低
- 看防御产品是否区分网络层清洗和七层CC防护,还是只标一个总防御峰值
- 看攻击溯源和流量调度能否在两个战场之间快速切换
- 看服务商在攻击中能否提供人工策略调整,而不是只靠自动清洗
防御权重分配参考
| 攻击类型 | 主要资源消耗 | 核心防御手段 | 配置重点 | 常见误判 |
|---|---|---|---|---|
| 网络层泛洪 | 带宽/PPS/会话表 | BGP高防、黑洞清洗 | 防御峰值、协议过滤 | 带宽不够 |
| 应用层逻辑耗尽 | 线程/数据库连接/CPU | WAF、CC防护、验证码 | 频率限制、业务限流 | 代码性能差 |
实操步骤：如何判断当前攻击属于哪个战场
- 带宽先看：
sar -n DEV 1 10，网卡出方向接近上限，先按网络层处置 - 连接状态：
netstat -an | awk '{print $6}' | sort | uniq -c | sort -nr，SYN_RECV大量堆积指向网络层SYN Flood - 数据库会话：
SHOW PROCESSLIST;，大量相同查询或异常Sleep连接，指向应用层逻辑耗尽 - URI聚合：
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20，某个接口请求占比异常高，基本可以判定CC攻击 - 业务指标：交易成功率、登录成功率、验证码通过率，这些能反映真实用户是否被误伤
针对网络层泛洪的处置动作
- 联系云服务商或机房,切入清洗路由
- 临时黑洞攻击源IP段
- 如自建防护,谨慎使用iptables限速，如
iptables -A INPUT -p tcp --syn -m limit --limit 10/s --limit-burst 20 -j ACCEPT
- 开启内核参数
net.ipv4.tcp_syncookies=1缓解SYN Flood
针对应用层逻辑耗尽的处置动作
- Nginx配置限制：
limit_req_zone $binary_remote_addr zone=cc:10m rate=10r/s;和limit_req zone=cc burst=20 nodelay; - 对登录、搜索、下单等重接口单独限流，静态资源尽量走CDN
- 引入验证码或行为验证,在攻击高峰自动升级
- 数据库侧：优化慢查询、加索引、引入Redis缓存，减少直连数据库的重复请求
- 线程池和连接池：设置合理的最大连接数和等待超时，避免一个接口占满所有连接
网络层泛洪和应用层逻辑耗尽不是同一场战争,前者看流量图，后者看业务指标，把两个战场分开指挥，才能在攻击真正到来时少走弯路。
网络层泛洪与应用层逻辑耗尽常见问题
如何快速区分网络层泛洪和应用层逻辑耗尽
看第一个到达瓶颈的资源,带宽或PPS先打满，通常是网络层泛洪；带宽平稳但数据库连接、线程数、响应时间快速恶化，通常是应用层逻辑耗尽。
高防IP能防住应用层CC攻击吗
基础高防IP主要清洗网络层流量,对七层CC攻击的防护能力取决于是否开启CC防护模块，多数高防IP需要额外配置URI频率限制、人机验证等策略后才能有效拦截应用层逻辑耗尽型攻击。
网站被CC攻击时，只用高防IP够吗
不够,需要配合WAF七层策略、Nginx限速、缓存层和数据库保护，才能完整覆盖应用层逻辑耗尽，高防IP解决的是流量入口问题，业务逻辑的脆弱点仍要在代码和架构层修复，高防IP的七层防护能力与具体套餐配置相关，攻击形态越复杂，越依赖策略组合而不是单点防御。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/637331.html
