1. 前言一次真实的流量清洗经历先讲个事。去年年中我们某个业务线正做着线上推广数据眼看要破峰值结果凌晨两点运维突然打电话把我从床上拽起来“兄弟出事了网关的入向流量干到 40G 了跑业务的端口全堵死客户那边已经开始报障了。”我第一反应是被打了。第二反应是哪种打法因为 DDoS 攻击的应对完全取决于“是什么类型的攻击”——是纯粹的带宽塞满型还是 TCP 层连接耗尽型还是连应用都没放过、慢刀子割肉型。这三种攻击方式虽然统称 DDoS但原理不同、特征不同、清洗策略完全不同你在没看清类型之前就乱开防护轻则无效重则误杀正常用户业务雪上加霜。这篇文章我不打算讲“怎么发动攻击”——那是红线也没意思。我今天想认真聊的是作为一名后端开发、运维工程师或技术负责人当你被这世界上三种最主流的 DDoS 攻击方式打上门时你该怎么从监控数据里辨认它们、怎么理解它们的杀伤逻辑、怎么用方案把它们按下去。我会结合我踩过的坑和实际清洗经验把“识别”和“处置”两条线全讲透。1.1 全文围绕三个核心问题展开这三种攻击方式分别是什么、为什么能打死你的服务真实流量进来时怎么从监控指标里一眼判断是哪种每一种攻击对应的防护思路和落地配置怎么搭顺便说一句DDoS 攻击和普通高并发请求有本质区别高并发是业务真的有人用请求里带 Cookie、带正常 UA、有业务序列DDoS 是请求里全是“假人”或者干脆连握手都完成不了。技术上判断“是不是真流量”是后文所有清洗动作的前提。下面我们直接进入正题。2. 流量型攻击把带宽打满的粗暴打法2.1 流量型攻击的核心逻辑第一种攻击方式叫流量型攻击通俗讲就是“用超大流量把你的带宽管道塞爆”。很多新人有个误区以为服务器配置高就能扛其实流量型攻击的目标压根不是你的 CPU 或内存而是你的交换机端口、机房出口带宽、云服务商的物理链路。你的服务程序还没来得及处理数据网络层就已经完全瘫痪了——就像高速公路上再多收费亭入口匝道被大卡车堵死了后面的车谁也进不来。这类攻击最常见的载体是 UDP 反射放大。这里稍微展开讲一下原理UDP 是面向无连接、无验证的协议攻击者把源 IP 伪造成受害者的 IP然后向互联网上大量的公共 UDP 服务比如网络时间协议、部分旧版 DNS 服务器发送极小的查询请求这些服务收到请求后会回应一个体积比请求大几十倍甚至上百倍的响应包。如果你伪造了一堆受害者 IP 的请求所有放大器的响应都会汇集到受害者那条带宽线上瞬间把它打满。另外历史上还出现过一种叫“畸形报文洪泛”的老流派通过发送分片重叠、校验和非法的数据包触发协议栈漏洞来耗尽设备 CPU但现在大部分路由器都有分片重组防护这类手段已经很少见了。如今的主流流量型攻击依然靠“量大管饱”取胜。2.2 典型特征与识别要点被流量型攻击打中时监控面板通常会有非常明确的信号入向带宽瞬间飙到接近甚至超过物理上限比如你买了 1G 的带宽监控直接画出一条顶到天花板的横线源 IP 分布分散端口号大量且随机只要带宽塞满无论 TCP 还是 UDP 业务都会同时卡死因为回包根本挤不出去专线/机房侧会出现明显的丢包率抬升因为设备缓冲已满后来者只能被丢弃我踩过的一个坑是当时我只看了负载均衡的 QPS 和延迟发现 QPS 并不高但客户端全部超时一度以为是代码死循环产生了线程阻塞。排查了半小时最后拉出带宽监控才发现问题——入向带宽已经顶着上限跑了二十分钟。所以从这个教训出发我给自己定了一条铁律遇到大面积超时第一件事先看带宽和丢包率再去看代码逻辑。方向错了排查时间翻倍业务损失也翻倍。2.3 防护思路在“管道”层面解决问题应对流量型攻击核心原则是“别在自己家里硬扛要在源头或骨干侧清洗”。因为你的机房带宽再大也大不过攻击者聚合起来的流量你硬扛等于用自己的钱包跟对方的钱包拼消耗。实务上最有效的做法是引入高防 IP将业务域名解析切换到高防 IP 上所有流量先经过云端清洗集群清洗集群的带宽通常是 TB 级远高于攻击流量规模。清洗设备识别并丢弃攻击报文后把干净流量回源给你的真实服务器 IP。这样做有几个必须注意的操作细节购买高防服务时要确认清洗集群的防护能力到底多大建议至少留 2~3 倍冗余。曾经有同行贪便宜买了低配套餐结果攻击流量冲到 60G套餐防护能力只有 30G清洗集群本身先被打瘫了所有流量直接黑洞化业务彻底断线源站 IP 必须隐蔽。清洗设备回源时攻击者只要扫到源站 IP就会绕过高防直接打源站。源站防护手段包括防火墙只允许高防集群的网段访问业务端口、回源方式启用以高防侧特定标记来鉴权、源站前置只放行指定来源如果攻击流量超过云服务商能承受的极限运营商侧会直接实施黑洞路由也就是把你的整个 IP 断掉以保护骨干网络。这不是服务商坑你而是所有云服务的通用机制。所以大促等关键业务节点务必在服务商侧约定更高的防护阈值并做好跨可用区即时切换备域名的预案2.4 低价方案路由黑洞与限速如果你的业务预算有限或者攻击规模还没有大到必须上高防的程度也可做几项应急处理在防护设备上开启 UDP 限速策略设置单 IP 的入向 UDP 流量阈值超过后直接丢包。毕竟绝大多数流量型攻击用的都是 UDP对 TCP 业务几乎无影响把防火墙的 ICMP 回应关掉禁止 ping可以过滤一部分探测流量如果攻击源相对固定直接拉黑源 IP 段。但说实话这条对流量型攻击帮助有限因为攻击源通常是基于伪造地址的你不一定能拉得完这一条里我想特别强调流量型攻击的“识别”比“处置”更考验功力。很多团队第一次被打时最容易犯的错误是盯着应用层日志找原因白白浪费了宝贵的 10 分钟。监控体系里把带宽、PPS每秒数据包数量、丢包率、连接数四个指标固定放进第一屏是所有后续防护动作的地基。3. 连接耗尽型攻击用半开连接拖垮系统3.1 连接耗尽型攻击的核心逻辑第二种攻击方式目标是指向操作系统和应用程序的并发连接处理能力。攻击者并不需要多大的带宽但可以通过大量建立半开连接、占用并发连接槽位让服务器无法再为合法用户建立会话。这类攻击最经典的代表就是 SYN Flood。我解释一下什么叫半开连接。TCP 建立连接需要三次握手客户端发 SYN服务器回 SYN-ACK客户端再回 ACK握手才完成。SYN Flood 的思路是我拼命向你发 SYN但我收到你的 SYN-ACK 后就是不回 ACK于是服务器侧的这个连接就一直停留在 SYN_RE 状态占用着一块内核内存和一个连接表项。攻击者每秒发几万个 SYN连接表很快被灌满此后无论谁再发 SYN服务器都没有资源响应了。这个攻击最狡诈的地方在于它消耗的是服务器的内存、CPU/中断资源而不是带宽。你监控带宽时可能一切正常但用户已经完全连不上服务了。3.2 典型特征与识别要点当你怀疑被连接耗尽型攻击时优先看这几个指标系统里 netstat 状态中 SYN_RE 或 SYN_RECV 积压数量异常庞大正常情况下这个值应该很小带宽占用不大但新建连接失败率极高或者连接建立极慢CPU 出现大量软中断和内核态占用因为每个伪造 SYN 都会触发协议栈的处理路径服务器日志里出现大量“Cannot assign requested address”或超时类错误这是连接表耗尽后系统资源枯竭的信号我记得有一次某台 4 核 8G 的节点扛了十分钟 SYN Flood因为当时的版本内核参数没有调优默认的 SYN 队列长度仅能容纳一两千个半连接攻击量一上来立刻被打到零新建连接监控面板的 TCP 新建速率直接从每秒数百掉到个位数。所以你自己心里要清楚正常业务的并发连接数和攻击下连接数根本没有可比性——后者能在秒级把队列撑爆。3.3 防护策略内核参数调优与应用层防滥用连接耗尽型攻击的防护分为三层第一层是操作系统内核优化。这是成本最低的一步也是不少团队忽略的一步。推荐调优的几个关键项启用 SYN Cookies内核在 SYN 队列满时不维护半连接状态而是通过 Cookie 机制在握手第三步验证客户端可以极大缓解 SYN 洪泛。这个配置默认在部分发行版里关闭务必手动确认开启加大 SYN 队列长度如果你的业务本身确实有瞬间突发高并发调大队列可以给合法连接更多排队机会。但注意不能无限调大因为每个队列项都占内存调得过头会挤占其他业务内存缩短 SYN-ACK 重传次数合理降低重传次数可以让内核更快丢弃无效的半连接释放队列资源开启 tcp_tw_reuse 等 TIME_WAIT 复用参数提高连接表周转效率第二层是网络侧防护。服务商高防同样能处理 SYN Flood防护设备维持代理握手即客户端先与高防节点完成 TCP 握手确认是真实请求后再转发到源站。这种方式彻底隔离了源站与攻击者的直接连接效果最为干净。缺点是源站侧需要兼容高防回源的 IP 标记来识别真实用户。第三层是自研网关限速。有些场景由于业务合规或信创原因不能全上云就必须在自建负载均衡上做手脚。我的经验是对单个源 IP 的并发连接数设置上限正常业务单 IP 并发连接很少过百超过阈值直接丢 SYN对新建连接速率做令牌桶限速让每个源 IP 每秒最多建立 N 个新连接防止单点打爆在接入层定期抓包确认 MAC 地址频率特征必要时对异常源 IP 段临时封禁这里必须说一个我在实践中反复遇到的现象不少运维在调完内核参数后以为万事大吉结果下次攻击照样出事。为什么因为调优只缓解了协议栈处理压力并没有解决连接资源最终被占满的问题——攻击者如果持续高频发包就算队列再长也会被填平。所以内核调优只能作为防御纵深的一层绝不能作为唯一方案。真正的兜底一定要落到网络侧清洗上。3.4 实操记录一次手动防御升级前年我处理过一个真实案例业务部署在某云裸金属服务器上带宽 5G应用是自研网关加多组后端。攻击爆发时带宽只有 3G但 TCP 新建成功率掉到不到 1%。我立即执行了一套组合动作先登录服务器查看协议栈状态确认 SYN_RECV 已超过一万立刻启用 SYN Cookies 并加大队列效果立竿见影——新建成功率恢复到 60% 左右然后联系服务商把该 IP 的防护阈值临时上调到 20G同时切到高防备用入口最后在自研网关层临时加了一条规则单源 IP 每秒新增强连接数限定为 20超限直接重置这套组合拳执行完大约花了 8 分钟业务在 10 分钟内恢复基本可用。事后复盘发现真正起作用的是两步SYN Cookies 扛住了前几分钟的尖峰高防切流把攻击流量彻底隔离在源站之外自研限速只是兜底。如果你问我基础设施安全里最值得投入的是什么我的答案一定是“场景化的应急预案”而不是某套具体设备。4. 应用层攻击慢速耗尽与资源榨干4.1 应用层攻击的核心逻辑第三种攻击方式同时也是技术含量最高、最难以防御的一种应用层攻击。它的特点是流量本身看起来完全合法——请求格式正确、HTTP 协议完整、甚至带上了正常的 User-Agent 和 Cookie。攻击者不再追求短时间塞爆带宽而是通过模拟真实用户行为一点一点耗尽应用层的并发连接、数据库连接池、后端线程池、CPU 和内存资源。它最常见的两种形态第一种是慢速攻击。攻击者建立 HTTP 连接后以极慢的速度发送请求数据。比如说正常浏览器发送一个 POST 请求几毫秒就传完了攻击者却故意把请求体分成很多片每片之间间隔几秒甚至几十秒才发一点。服务器端如果设置了较长的超时时间就会一直为这个连接保留线程和内存等它把数据传完。一个攻击者同时开几千个这样的慢速连接就能把服务器所有线程都占住合法用户的请求排不进去。第二种是代理池高频请求攻击。攻击者通过大量代理 IP 或秒拨 IP 池以正常速率高并发地请求动态接口、搜索接口、转账验证接口等较重量级的业务逻辑让后端持续处于高负载状态。这类攻击看起来就像“一群真人正在疯狂刷你页面”单纯靠拉黑 IP 根本拉不完因为 IP 池的动态性极强。4.2 典型特征与识别要点应用层攻击最阴的地方在于如果你没有细看会觉得只是突然来了个热点用户、接口被刷爆了。我总结了几个区分“真热点”和“被攻击”的关键差异真实热点通常集中在少数几个热门 URL 上而攻击流量通常均匀或随机地分布在大量 URL 甚至全部动态接口上真实热点用户的 IP 带有地理集中性比如是一个城市的用户密集访问而攻击流量源 IP 分散在全国甚至全球、且 AS 号分布异常杂应用层攻击往往伴随请求频率非常均匀人为刷的频率特征反而更规律比如精确地每 3 秒一次、每次间隔几乎一样真人做不到这么机械慢速攻击更容易识别连接建立后长时间不传数据、传输速率极低、单个连接的存活时间远超正常业务阈值正常页面最多几十秒加载完慢速连接可能挂几十分钟从资源维度看CPU、数据库连接数、应用线程数持续高位但带宽和入口 QPS 并没有高到离谱4.3 防护策略应用层需要精细管控应用层攻击的防御光靠网络层设备远远不够必须把防线拉到应用本身。以下几个方案是我经历了多次攻防对抗后验证有效的在接入层网关设置合理的“请求头超时”和“请求体超时”。比如客户端超过 5 秒没发完请求头就直接断开请求体整体超时限制在 20 秒以内。这个数字要根据业务情况调但不能给得太宽否则就是给慢速攻击留了后门在网关统一启用并发连接数限制单 IP 最大并发数、单 IP 每秒最大请求数、单 IP 每分钟最大请求数三级限流。重点配置在需要计算成本的动态接口上静态资源请求可以放宽对动态接口做业务风控侧识别比如校验短时间内的访问频率、是否带登录态、用户操作路径是否符合真实业务逻辑。代理 IP 池攻击虽然可以伪造请求头但很难模拟真实用户的行为轨迹部署 Web 防火墙WAF重点拦截异常 UA、异常 Referer、异常请求分布匹配。要注意的是WAF 规则一定要在攻防前做充分压测否则防护规则误伤正常用户比攻击本身还伤业务在应用层实现用户级限流如滑动窗口计数器确保单个用户即使被刷也不会占满全局资源我还想专门提示一点很多人以为应用层攻击一定需要很高 QPS 才有威胁其实这是一个误区。慢速攻击的 QPS 可能只有几百却能把几千线程的容器拖垮。如果你只按“QPS 超过阈值就限流”来防护慢速攻击刚好卡在阈值以下系统照样会挂。所以应用层防护不能只看 QPS 一个维度必须同时看连接存活时长、传输完成率、并发线程水位三个指标。4.4 实操记录慢速攻击识别与处置今年早些时候我们一套核心接口出现过诡异问题负载均衡的 QPS 不过三四百但后端 Java 服务的线程池被打满了大量请求出现排队超时。刚开始团队怀疑是 Full GC 问题折腾了一下午发现堆内存一切正常。后来登录服务器执行命令查看 ESTABLISHED 状态的连接时发现一个异常现象连接的平均存活时间超过 20 分钟而正常业务平均只有 4 秒。顺着这个线索进一步排查定位到大量来自低版本安卓 UA但 UA 版本和系统版本明显不匹配的长连接每个连接都在以极低速率零星发送数据。显然这就是慢速攻击对方在拖住我们后端的连接线程。处置动作非常直接网关层把超时时间收紧到 10 秒针对匹配 UA 的请求启用人机验证对已建立的连接按“空闲超过 8 秒即断开”策略强制回收处置完成后一个小时内后端线程池水位就降下来了接口延迟恢复正常。这次攻防对抗让我记忆很深刻如果团队平时对连接存活时长、线程池水位这类应用指标不做监控这类攻击几乎是无解的。5. 防御体系的整体编排与实战速查5.1 为什么不能只防一种攻击方式写到这里你会发现我前面把三种攻击方式分得很清但在实际攻防中攻击者极少只打一种。常见的手法包括先用流量型攻击打高防 IP迫使你切流量架构然后同步打源站 IP逼你暴露真实 IP先使用连接耗尽型攻击让接入层瘫痪趁你忙着调内核参数时应用层同步发起慢速攻击针对你的 WAF 规则做定向探测确认规则后换上更隐蔽的应用层攻击特征绕行所以一个成熟安全的架构应当是纵深防御Defense in Depth的每层各有侧重又互相协同第一层网络层清洗高防 IP / 运营商侧黑洞联动负责挡住流量型和连接耗尽型的大部分流量第二层接入层负载均衡限速Syn Cookie、单 IP 限流、超时管理负责挡住漏进来的连接请求第三层应用层安全策略WAF 规则、业务风控、线程池隔离负责处理看起来像真人的恶意请求第四层数据层保护数据库连接池隔离、热点数据缓存、降级预案确保即使前端被打穿核心数据也能守住5.2 实战速查表我把三类攻击的识别与处置要点整理成了下面这张表建议截图保存或者打印贴工位上攻击类型核心资源瓶颈关键监控指标快速识别特征首选处置方案流量型攻击带宽/交换设备入向带宽、PPS、丢包率带宽顶满、UDP占比高、源端口杂乱高防 IP 过滤 隐蔽源站连接耗尽型攻击连接表/内核内存SYN_RECV数、并发连接数、新建连接成功率带宽不高但连接失败率高、大量半开连接SYN Cookies 网络侧代理握手应用层攻击线程池/CPU/数据库连接池线程水位、请求平均耗时、连接存活时长、业务 QPS连接存活时间异常长、请求特征机械、IP杂乱网关超时收紧 动态限流 WAF/风控5.3 实战中的优先排序当攻击事件发生时实操经验教会我的处置优先级是先恢复业务可用性再查攻击动机。先切高防、收紧超时、摘掉故障节点让业务先跑起来千万不要开着抢修会滔滔不绝分析攻击者画像隔离优于硬扛。任何层次的攻击优先把流量引到可控的清洗节点或备用节点而不是在主链路上一遍遍调参保留现场证据。抓包文件、监控曲线、日志片段保存至少 30 天不仅用于复盘也可能成为后续追溯和同行业预警的素材最后再考虑根因加固。攻击结束后必须复盘应急预案是否生效、监控指标是否覆盖到位、配置变更是否遗漏形成闭环6. 日常防护清单与资源配置经验6.1 基础设施层面的日常自检与其每次被打个措手不及不如日常把防护能力做成“肌肉记忆”。我建议每个团队参照下面的清单巡检是否已经在网络侧部署了清洗能力高防 IP 或运营商清洗清洗能力是否至少覆盖近三个月内出现过最大攻击流量的两倍所有对外服务端口是否已经收敛到最小集非业务端口一律拒绝互联网访问源站 IP 是否曾经暴露过比如通过历史 DNS 记录、证书透明度日志、邮件头信息可反查到源站地址操作系统是否已经启用 SYN Cookies并合理配置连接超时相关参数接入层是否配置了单 IP 并发连接限制和新建连接速率限制应用层是否对动态接口设置了超时和限流规则超时配置是否经过了真实业务压测验证重要接口是否具备人机验证和风控能力至少做到在攻击时可以快速启用“验证码模式”降级监控面板是否同时覆盖带宽、PPS、TCP 连接状态分布、请求耗时、线程水位等指标并且有独立的告警通道别小看这份清单每一项都对应着血泪教训。前几天有个朋友跟我诉苦说他们的服务被打时发现高防套餐早过期了告警短信也没收到因为监控只配了带宽超限而攻击是应用层的带宽压根没超。所以监控指标覆盖不全的危害有时候比攻击本身还大——你根本不知道自己在挨打。6.2 预算有限时如何取舍很多中小团队面临一个现实问题上高防 IP 一年几十万业务收入却不高。这种预算下的合理策略是分级防护最核心的业务接口登录、支付、核心交易做精细化的应用层防护因为这类接口的可用性直接关系收入中低价值页面营销页、公告页只做基础限流即使被打挂也不影响核心交易静态资源走内容分发网络不仅可以加速访问也能天然分担一部分攻击流量另一个省钱但很实用的技巧是“多活冗余”把业务部署在两个云服务商的可用区或两套独立资源池中平时流量按比例分摊。一旦某侧被攻击打垮可将域名解析全部切到另一侧。这个方案不增加额外攻击防御成本但能显著降低因单点防护能力不足导致的整体不可用风险。7. 额外送上的三个实用经验文章最后我分享三个只有实际操作过才会注意到的细节第一抓包分析时不要只看数据包数量更要关注包的特征分布。比如 UDP 反射放大攻击通常攻击包的源端口和目的端口都存在高度集中性某些端口如 53、123的占比会异常高。这些特征能帮你在高防规则里快速建立端口级过滤策略比盲目的源 IP 封禁有效得多。第二配置高防 IP 切换时务必检查域名的 CNAME 和 TTL。如果 TTL 设置过长DNS 解析切换生效会很慢攻击流量会持续涌向源站。我的习惯是重要业务域名的 TTL 日常保持 60 秒有条件时提前做预切让新解析记录提前生效不给攻击者留切换窗口。第三自研防护规则要进行定期演练。我们每个季度会做一次内部攻防演练模拟流量型、连接耗尽型和应用层攻击各一次检验排查流程是否顺畅、监控告警是否及时、应急预案是否需要修正。平时不演练真出事时你会发现该谁第一时间发通知、该谁决策买不买临时高防、该谁联系服务商开启清洗全都混乱不堪。DDoS 攻击不是一个可以一次性解决的安全问题它是对你整个技术体系响应能力、监控覆盖度和团队协作效率的综合大考。防御的本质不是某套神级设备而是你对自己系统掌握到什么程度、预案演练过多少遍、指标监控有没有真的覆盖到链路每一个关键位置。把这些基本功打扎实任何形式的攻击打过来你都能冷静打开监控面板一步步拆解快速恢复业务而不是像无头苍蝇一样到处乱撞。希望这篇经验之谈能让你少走一些我走过的弯路。