网络层清洗、传输层限连、应用层识别不是三道独立的门，而是一条流水线上的三道工序：先清洗大流量，再限制连接洪峰，最后识别应用层恶意请求。
网络层清洗与传输层限连如何配合？先分清各自职责
很多站长被DDoS攻击时,第一反应是把所有防护都打开，结果误杀正常用户，攻击却没挡住，问题出在没搞清三层各自管什么。
网络层清洗：负责滤掉“大而粗”的流量
网络层清洗处理的是带宽型攻击，比如SYN Flood、UDP Flood，攻击特征明显：流量巨大、源IP分散、包内容无意义，清洗系统部署在机房入口或云端高防节点，通过路由牵引把流量拉过去，识别并丢弃攻击包，再把干净流量回注到源站。
它的优势是“快”和“大”，能扛几百G甚至T级流量，但它也有明显短板：看不透应用层内容，哪怕一个请求是正常的HTTP包，只要来自黑名单IP，也可能被误杀；反之，如果攻击者用真实浏览器发起低速率请求，网络层清洗几乎束手无策。
传输层限连：负责挡住“连接风暴”
传输层限连关注的是TCP连接建立速度与数量，典型的场景是CC攻击变种攻击者建立大量半连接或高频率短连接，耗尽服务器的连接表或线程池。
限连机制通常部署在防火墙、负载均衡器或内核参数中，常见做法包括：
- 限制单个IP的并发连接数
- 限制单IP每秒新建连接数
- 对SYN半连接队列长度做封顶
- 开启SYN Cookie让服务器在握手过程中不分配资源
限连能有效防止“慢速连接拖垮进程”，但它管不了连接建立之后的请求内容，比如攻击者保持长连接，每隔几十秒发一个正常请求，限连只能看到连接数正常，识别不了这是恶意行为。
两者配合的关键：别让限连被清洗拖垮
网络层清洗和传输层限连经常在同一个入口设备上执行,行业共识认为，协调配合的难点在于清洗动线不能和限连规则冲突。
举例：清洗机房会把攻击流量过滤掉，再把回注流量发给源站，如果源站防火墙上设置了“每秒新建连接数超过2000就封IP”，而清洗回注时突然涌入大量正常用户（比如热点活动），限连规则可能误判为攻击，把整段用户流量都掐断。
正确的配合思路是：
- 网络层清洗先“扛体积”，把明显攻击流量丢弃
- 传输层限连在清洗回注的干净流上做“流量整形”，平滑突发连接
- 限连阈值要留有冗余,避免正常业务高峰被误伤
用表格对比更直观：
| 层面 | 主要职责 | 核心指标 | 应对攻击类型 |
|---|---|---|---|
| 网络层清洗 | 滤除大流量攻击包 | 清洗带宽、丢弃率 | UDP Flood、SYN Flood、反射放大攻击 |
| 传输层限连 | 管理连接建立速率与数量 | 并发连接数、新建连接速率 | 连接耗尽攻击、高频短连接攻击 |
| 应用层识别 | 分析请求内容与行为 | QPS、恶意请求命中率 | CC攻击、慢速攻击、爬虫滥用 |
应用层识别怎么配合DDoS防护？从CC攻击说起
CC攻击是应用层DDoS的典型代表,它用的不是大流量，而是大量“合法请求”比如反复查询商品详情、搜索接口、登录接口，这些请求从TCP层看完全正常，连接数也在合理范围内，但堆积起来照样能打垮应用。
应用层识别看的是“请求像不像人”
应用层识别引擎会检查HTTP头部、Cookie、User-Agent、请求频率、浏览路径，它会问几个问题：
- 同一个IP是否在1秒内发起超过阈值次数的请求？
- 请求是否对同一URL反复访问,且不带Referer？
- 访问行为是否表现出“机器规律”，比如固定间隔、无鼠标移动轨迹？
- 是否突然出现大量来自非活跃地区的新IP？
识别结果是动态的,正常用户可能也被限速，但识别系统会根据验证码、JS挑战、跳转等交互方式，快速放行真实用户，这就是应用层识别独有的“软性拦截”能力。
三层配合的典型链路：清洗→限连→识别
一次完整的防护流程像流水线：
- 网络层清洗最先看到流量，先判断是否有超大流量冲击，如果是，直接丢弃攻击包
- 传输层限连对通过清洗的流量做连接管理，防止建连速度过高导致后端服务无响应
- 应用层识别最后检查已经建立连接上的请求，把高频、异常、带攻击特征的请求挡在业务逻辑外
这三步必须串行,不能跳过，如果清洗做得不到位，大量SYN包涌到限连层，限连负担过重，反而拖慢正常连接，如果限连没控制住，应用层识别要面对海量连接，CPU和内存可能已经耗尽，根本来不及做深度检测。
有一种常见误区：直接用应用层识别应对所有攻击，如果攻击流量达到百G级，应用层识别系统首先会因带宽拥堵而“罢工”，反过来，只用网络层清洗，遇到慢速CC攻击则毫无办法。三层配合的本质是互补盲区，而不是用某一层包打天下。
三层联动的落地配置顺序与实操建议
纸上谈兵没用,下面给出一套可落地的配置路径，按顺序执行即可。
第一步：网络层清洗先接管入口
无论用云高防还是自建清洗设备,先确保入口流量全部经过清洗节点，配置时注意：
- 设置引流规则：把80/443及其他业务端口流量牵引到清洗设备的虚拟IP上
- 开启基础防护策略：SYN Flood、UDP Flood、ICMP Flood的丢弃阈值调为“保守”级别，宁可误杀一些异常包，也要保住带宽
- 回注方式推荐使用GRE或VxLAN,回注链路带宽要大于正常业务峰值的1.5倍
第二步：传输层限连做二次过滤
清洗之后,干净流量进入防火墙或负载均衡，限连规则要结合业务特性来定：
- 普通Web业务：单IP并发连接数建议限制在200-500之间（根据服务器性能调整）
- 单IP新建连接速率：每秒不超过50个，超出直接丢包或返回RST
- 半连接队列长度：保持在系统能承受范围内，启用SYN Cookie
这里要特别提醒：限连参数不要照搬网上的“最佳实践”，一台2核4G的云主机和一台16核32G的物理机，能扛的并发数完全不同。先压测，再定阈值。
第三步：应用层识别做精准拦截
应用层识别策略通常放在WAF或CDN后的反向代理上,配置顺序建议从宽松到严格：
- 先配置基础频率限制：单IP每秒钟请求数超过10次则触发JS挑战
- 再配置URL白名单：静态资源、图片、CSS等不参与限频，避免误伤
- 然后配置攻击特征规则：SQL注入、XSS、命令注入等直接拦截
- 最后开启行为分析：识别短时间访问多个URL、无鼠标轨迹、无Referer等机器行为
配置完成后,一定要做“回源测试”和“误杀率测试”，模拟正常用户操作路径，确保不会把连续翻页的用户当成攻击者。
配置顺序决定成败，别反着来
有些人习惯先在应用层加规则,用CDN顶一顶，实在不行才上高防，这个顺序实战中效果最差，因为CDN和应用层识别在面对高频CC时，自身的源站带宽可能先被打满，规则还没跑就宕机了。
正确顺序永远是：先保带宽，再保连接，最后保应用，无论你用的是云厂商的DDoS防护包，还是自建机房设备，这个优先级不会变。
一层是盾，两层是墙，三层是护城河
网络层清洗扛冲击,传输层限连稳核心，应用层识别判敌我，三者各自做好本职工作，再按顺序串联，才能在高强度攻击下既挡住恶意流量，又放行真正用户，如果你正在配置防护系统，不妨从清洗入口检查到应用层规则，一层一层理顺，比盲目堆功能有效得多。
网络层清洗传输层限连应用层识别配合的常见问题
网络层清洗和传输层限连的区别是什么？
网络层清洗针对的是带宽与包量层面的攻击,目标是在流量进入服务器之前把攻击包丢弃，保护链路带宽和基础网络设备，传输层限连针对的是连接建立过程，目标是防止服务器连接表、线程池等资源被耗尽，两者一个管“量”，一个管“速率”，缺一不可。
应用层识别能不能完全替代网络层清洗？
不能,如果攻击流量超过服务器接入带宽，应用层识别系统会因为网络拥堵而无法接收完整请求，只有先通过网络层清洗把流量体积降下来，应用层识别才能在相对干净的流上做深度检测，反过来，应用层识别能捕捉到网络层清洗看不到的慢速CC攻击，两者是互补关系。
如何判断我的网站需要哪种防护配合？
先用监控工具查看攻击特征：如果服务器带宽接近上限、CPU占用不高，多半需要网络层清洗，如果带宽正常但连接数飙升、应用响应迟滞，需要传输层限连，如果连接数正常但业务接口被大量相同请求打满，则需要应用层识别，实际上大多数中大型网站会同时开启三层防护，只是阈值和策略需要根据业务场景动态调整。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/637147.html
