从T级防御到低延迟：火山引擎原生DDoS防护实战复盘

做实时互动业务的这两年我被DDoS教育过不止一次。第一次线上被SYN Flood打瘫时监控面板上的入向流量曲线几乎是垂直上升的机房同事打电话过来说出口带宽已经打满紧接着就是路由黑洞、业务全断。那次之后我花了很多时间研究DDoS防护从选型到接入再到一次次攻击复盘慢慢把“防护”这件事从紧急救火变成了常规运营。最近我在梳理这套方案时发现火山引擎原生DDoS防护这个思路尤其值得聊——它把T级防御和低延迟放在了一起这两个词在过去很长一段时间里是互相矛盾的。这篇文章算是我接手DDoS防护大半年来的完整复盘内容包括技术原理拆解、接入实操、攻击实测和踩过的坑适合正在做防护选型、或者被延迟敏感业务和DDoS攻击两头夹击的同行。1. T级攻击时代防住大流量只是及格线延迟才是生死线1.1 攻击规模从百G到T级单点扛不住的根本原因先说个背景判断DDoS的本质是资源消耗战攻击者永远在找比你更便宜的“弹药”。早期常见的SYN Flood几十Gbps就能把一个机房的出口带宽打满那时候IDC的处理方式也很粗暴——直接上路由黑洞把整段IP的流量全丢掉业务彻底中断但至少网络设备保住了。这几年攻击手段变化很明显反射放大NTP、memcached、SSDP这类协议大幅提高了攻击的性价比加上智能设备被僵尸网络大量劫持攻击流量的规模从几百Gbps一路涨到了Tbps级别。头部云厂商的安全团队在公开分享里也提过T级攻击已经不是小概率事件。单点出口带宽决定了单点防护的上限。一个机房的物理出口可能就是几百Gbps就算把清洗设备部署得再密集物理链路摆在那里单点永远扛不住T级流量。这就是为什么所有能做T级防御的服务商本质上都是靠“分布式防护集群全网流量调度”而不是某一个节点的单机能力。T级防御的第一课是别指望一台设备、一个机房解决问题要让攻击流量“分摊”到全网多个节点上去消化。1.2 传统高防的隐性成本链路绕路是怎么拖慢业务的传统高防IP的接入方式大多数做过防护的人都很熟业务域名解析到高防IP用户流量先进高防机房清洗清洗后的“干净流量”再通过GRE隧道或其他方式回源到你的真实服务器。这套模式在防御能力上没问题但它天然有一个代价——链路绕路。举个例子。我们的源站部署在华东当时选了某个高防节点在华南用户从北京发起请求流量要先绕到华南清洗一遍再回华东源站TCP握手时延直接多出二十多毫秒。对普通网站来说这点延迟还能忍但对实时互动这类业务就是灾难级别。我们自己做过的对比测试同区域的高防节点和直连源站相比延迟多了8-15ms跨区域部署的话差距能拉到30ms以上。跨运营商的回源链路还要再加一跳问题更明显。我整理过不同接入方式下的链路差异可以参考接入方式用户流量路径典型额外时延运维复杂度源站直接暴露用户 → 源站0最低但裸奔传统高防IP用户 → 高防节点 → 回源隧道 → 源站8~30ms以上需维护回源链路、源站白名单原生防护用户 → 云网络入口就近检测清洗 → 源站接近0不需要单独回源链路所以我对“原生”二字的兴趣最初就是从延迟痛点来的。1.3 “原生”的定义安全能力长在云网络里不是一个外挂节点火山引擎原生DDoS防护里的“原生”我的理解是防护能力不再是一个独立的高防节点挂在业务链路前面而是长在云网络架构的内部作为网络入口的天然能力存在。这意味着几件事。第一业务流量不需要被牵引到异地清洗中心入口处的网络设备本身就具备检测和干预能力第二不需要改DNS指向不需要额外管理高防IP云上已有的公网IP、负载均衡实例直接就能绑定防护策略第三防护能力可以跟随云网络弹性扩展在资源池层面共享全网防御能力。对于我们这种云上部署的团队来说运维负担明显比传统高防低很多——不用维护回源隧道不用在源站机器上配一堆防火墙白名单控制台绑定一下策略就完事。但“原生”不等于免费也不等于万能。它最大的优势是解决“链路绕路”和“运维复杂”的问题至于防护效果和策略精细度还是要看具体配置和业务适配程度这些后面我会详细说。2. 原生防护的低延迟逻辑流量不绕路检测不添堵2.1 T级防御的承载逻辑分布式清洗节点与全网调度既然说到了T级就必须把承载逻辑讲清楚。火山引擎原生DDoS防护要承载T级防御靠的是分布式的清洗节点和全网调度能力而不是单个节点。大致路径是这样的攻击流量到达目标IP之前先被云网络的调度系统识别通过BGP路由策略和Anycast这类技术把流量分散到多个地域的清洗节点。每个清洗节点承担一部分攻击流量所有节点并行清洗攻击流量被“摊薄”到每一条物理链路上都能承受的范围。等攻击报文被过滤掉之后干净的业务流量再从就近节点回到目标服务器。打个比方一个机场只有一个安检口客流高峰必然排队排到大厅外分布式清洗相当于把安检口分散到了机场的各个入口每个人都能从最近的入口快速进入而可疑行李会在各自的入口被拦下。T级防御的真正含义是整个网络的总清洗带宽达到T级业务侧感知到的只是入口处多了一道“看不见的关卡”。2.2 低延迟的三个来源不绕路、串行改旁路、就近清洗火山引擎原生DDoS防护能把延迟压下来核心是改变了流量清洗的介入方式。传统高防是“串行清洗”所有流量必须先进清洗设备洗完再放行到源站每一个包都要排队过检延迟自然上去了。原生防护更接近“旁路检测定向引流”正常流量在网络入口做快速检测识别只要不命中攻击特征直接按原有路径转发根本不进深度清洗队列只有被判定为攻击流量或者置信度较高的异常流量才会被引流到深度清洗模块处理。这样一来正常业务流量的转发路径几乎没有增加额外跳数也不存在深度检测带来的缓存排队开销。延迟很低的三个来源也就清晰了不绕路不需要把流量从业务区域牵引到异地的清洗中心再回源。串行改旁路正常流量走原有快速转发路径只有异常流量才进入深度处理通道。就近清洗多地域节点让清洗动作尽量发生在距离用户和源站更近的位置。把这三条做到位防护方案才有可能在抗住大流量的同时把延迟增量压到近乎无感的状态。2.3 智能检测怎么做到既拦攻击又不误伤延迟是显性问题误伤是隐性问题而且误伤的代价往往比延迟更高。真实玩家被误封影响的不只是一个用户可能是整个社区的舆论。所以智能检测模块的判断质量直接决定防护方案的可用性。我了解到的做法是防护系统会先学习业务的正常流量基线。比如你的业务平时每秒新建连接多少、请求包大小分布什么样、单个IP的访问频率规律如何、连接生命周期多长这些特征会被持续统计并动态更新。检测引擎再基于滑动窗口去比对实时流量一旦某个维度的指标明显偏离基线比如新建连接速率突然暴涨、UDP报文量异常放大、单一源IP命中率异常升高就触发分级响应。分级响应很关键。高置信度的攻击直接丢弃低置信度的异常先限速再观察不让“疑似攻击”的流量直接吃满清洗队列。我们自己的实测里慢速CC攻击是最难识别的因为它每个请求看起来都很“正常”后面我会专门讲这个部分的实测记录。3. 接入与验证开通、绑定、压测三步走完真实链路3.1 接入前先把网络架构和防护对象梳理清楚接入原生DDoS防护之前第一件事不是去控制台点开通而是把自己的网络家底盘清楚。我当时踩过一个坑想着赶紧把防护开起来结果遗漏了一个老业务的公网IP攻击者恰好就是从那路IP进来的防护形同虚设。需要梳理的信息大致是这些所有对外暴露的公网IP资产包括云服务器绑定的、负载均衡入口的、还有那些“临时开的、后来忘了”的IP。业务端口和协议类型是纯四层自定义TCP/UDP协议、游戏连接还是七层HTTP/HTTPS Web服务这决定策略模板的选择。业务所在地域和访问量分布如果用户和源站都在华东优先就近绑定节点避免跨地域引入额外延迟。合规边界原生防护更适合整体业务都在火山引擎云上的场景。如果源站还在自建机房就要先确认云和IDC之间的专线或公网链路质量否则“云上清洗IDC回源”的链路延迟未必比传统高防好多少。3.2 开通与绑定控制台上的完整操作路径控制台上的操作路径不同时期界面可能略有调整但整体逻辑是通用的。第一步在火山引擎控制台找到DDoS防护服务开通原生防护实例选择业务所在区域。第二步把需要防护的资源绑定进来支持直接绑定公网IP和负载均衡实例。这里建议优先绑定负载均衡的入口因为后端多台云服务器可以一起被覆盖不用一台台配置。第三步配置清洗阈值和防护策略模板。四层策略里可以设置触发清洗的流量阈值、协议类型七层策略里可以开启CC防护、设置请求速率上限黑白名单和区域封禁在这个阶段也要一并配好。第四步保存配置之后去监控页面确认流量数据和策略下发状态确认有实时流量上报说明绑定生效。接入这个环节我建议不要太相信默认配置。默认模板照顾的是大多数普通场景对特殊业务不一定合适。比如我们的WebSocket长连接业务默认的“新建连接速率”阈值就很敏感因为长连接本身就是高频握手容易被误判。这种场景需要先把阈值放宽再用后面的压测去校准。3.3 与负载均衡、CDN的联动防护不是孤立部署实际生产环境里云上业务很少是“一台云服务器裸奔”的状态。负载均衡在前面分发流量CDN在前面做静态加速这些都是常见的架构。原生防护的优势在于它可以跟这些组件天然联动而不是再插一层独立设备。负载均衡场景下防护直接绑定在SLB的公网入口上后端多台服务器共享防护能力攻击流量在入口就被清洗掉了后端机器几乎感知不到攻击压力。CDN场景下可以用“CDN 回源到负载均衡 原生防护”的链路组合CDN承担边缘缓存和第一层流量分散云网络入口再兜底清洗。需要注意的是这类组合链路越长排查问题时的跳板就越多建议提前画一张流量走向图标注每一条链路的防护责任边界——哪一层负责清洗容量型攻击哪一层负责应用层防护别等出事了再理。4. 攻击实测复盘四层强攻、七层慢速CC与延迟波动都记录下来了4.1 四层大流量压测清洗生效时间与业务无感知窗口先说清楚前提所有压测都在我们自有的测试环境、合法授权范围内进行用的都是合规的压力测试工具生产环境流量验证也是在低峰期小流量灰度做的。真去造T级攻击既不现实也不合法所以这一节大家重点看方法和结论不要照搬攻击思路。我们在测试环境模拟了UDP Flood和SYN Flood攻击流量从几十Mbps起步逐步加到数十Gbps。观察到的现象是流量到达触发阈值后清洗策略几秒内开始生效入向带宽曲线被“削平”源站机器的CPU使用率和并发连接数保持稳定没有出现雪崩迹象。最让我关注的是清洗生效窗口也就是从攻击流量到达入口到清洗策略完全介入的这段时间这个窗口越短业务受影响的概率越低。实测下来这个窗口是秒级对真实业务来说基本无感。但也要说句公道话数十Gbps的压测只能验证策略逻辑和清洗链路是否通畅真正的T级攻击考验的是全网总带宽和所有清洗节点的协同能力这属于平台侧的资源储备业务侧无法完全复现。我们能做的是确认“触发清洗后正常业务不受影响”剩下的交给服务商的T级能力兜底。4.2 七层CC实测慢速请求最难识别阈值决定误杀率四层大流量攻击看起来吓人实际上技术含量不高靠带宽和清洗节点数量就能硬扛。真正难处理的是一眼看上去很像正常请求的七层CC攻击。我们模拟了低频慢速的登录请求和查询请求单个请求的体量很小、频率也不算夸张完全模拟真实用户的访问行为。第一轮测试用的是默认策略模板结果出现了明显的误杀——QA部门模拟真实用户回归业务的脚本有一批请求被限速拦截了。原因是默认阈值按普通企业的请求频率做了设定而我们的接口请求频率本来就偏高。把阈值调高之后误杀确实消失了但问题又来了攻击流量混在正常流量里慢慢磨后端服务器的连接池还是会缓慢爬升。这就是七层防护的经典矛盾越严格的检测越容易误伤越宽松的策略越容易漏防。最后我们采用了分级处置的方案对疑似攻击请求先限速而不是直接丢弃高置信度的再进行验证和封禁同时配合业务侧的人机校验机制把漏进来的慢速攻击拦在业务逻辑层。这一轮实测最大的收获是七层策略不能指望一个默认模板走天下必须用自己的业务流量做回放调试。4.3 攻击期间的延迟波动分清清洗开销和瞬时拥塞延迟波动这个部分我当时的关注点不只是“清洗是否增加延迟”更想知道“攻击发生时用户会不会感觉到卡顿”。实测数据很有参考价值正常时段跨地域TCP建连时延大约在10ms上下攻击流量刚开始到达的那一两秒出现了明显抖动网络时延短暂拉升到数百毫秒甚至更高清洗策略稳定生效后时延回落到正常水位和没有攻击时几乎一致。这个过程说明一个关键问题攻击发生时的瞬时卡顿主要是攻击洪峰到达节点时造成的瞬时拥塞而不是清洗机制本身引入的开销。防护能不能做到低延迟看的是清洗稳定后业务链路是否恢复原样而不是攻击发生的那一瞬有没有波动——那一下的波动任何做了防护的方案都很难完全避免。测试阶段我记录了一张简化表供大家参考阶段四层大流量攻击UDP/SYN Flood七层慢速CC攻击业务表现攻击开始瞬间时延瞬时抖动带宽快速上升无明显带宽变化请求速率缓慢上升偶发卡顿连接建立变慢清洗稳定后带宽被削平时延回落请求被分级限速后端压力可控业务恢复正常误杀需观察持续攻击中时延保持正常水位依赖阈值与策略调优无明显影响需持续监控4.4 一个容易被忽略的点清洗节点的流量回注这个点我要单独拎出来说因为很多人在做攻击复盘时完全不关注它。清洗之后的干净流量要正确回注到业务链路回注路径如果设计不合理一样会造成延迟增加或者丢包。我们用traceroute对比过攻击中和正常时段的路由路径确认攻击发生时流量没有出现异常绕路这才放心。顺手推荐一个小技巧在业务服务器上部署一个简单的时延监控脚本用TCP connect不是ICMP Ping定期探测目标地址把数据落库。这样每次攻击结束之后都能拿到一份“攻击前-攻击中-攻击后”的时延曲线方便复盘时精确判断清洗效果和回注质量。5. 持续运营中绕不开的坑误杀、弹性带宽与阈值调优5.1 误杀排查真实用户被拦截后的完整处理链路接入原生防护后的第一个工作日我们就收到区域用户反馈“登录失败”。查日志发现有某个省份的运营商出口网段整段被区域封禁规则命中了——原因是封禁规则设置得太粗粒度攻击源IP段和正常用户出口网段恰好重叠。这类问题在DDoS运营里非常典型因为攻击者喜欢借运营商的IP池发起攻击而你没法把整个运营商网段都封了那等于自杀。我的处理链路是这样的先从防护控制台导出拦截日志把被拦截的IP段和业务日志里的正常用户访问IP做比对确认高误杀风险然后把封禁规则从“整段封禁”改为“封禁限速”的组合对异常来源先限速而不是直接丢弃最后持续观察两三个小时确认反馈问题消失再调整策略模板的默认阈值。关键经验是防护策略的所有拦截动作一定要有日志留存并且日志要能导出到自己的存储系统里。控制台的在线图表只适合看趋势真正追查问题还是要落到自己的日志平台里做分析。5.2 弹性防护带宽的预算公式与取舍弹性带宽的配置本质是一个成本与安全边际的权衡问题。我把我们的取值思路拆一下防护带宽通常由基础带宽和弹性带宽两部分组成基础带宽是日常兜底弹性带宽是攻击爆发时自动顶上来的“后援”。基础带宽设得太低攻击一超出就被打穿甚至触发黑洞弹性带宽设得太高日常账单压力大。我的建议是取业务近90天最高攻击流量峰值乘以1.5到2倍的冗余系数作为弹性防护水位的参考线。大促或活动之前临时上调水位活动结束后再回落。这个公式不复杂核心是给“历史最大攻击”留足缓冲避免攻击者稍微加力就把防线推平。另外有句话我得提醒为了省成本把防护水位压到极限一旦被打穿触发运营商黑洞业务全部中断造成的损失会比弹性带宽账单贵得多。5.3 与WAF和应用层策略的纵深协同DDoS防护解决的是流量层面的攻击但线上安全的威胁远不止流量这一层。SQL注入、业务逻辑漏洞、爬虫刷接口这类问题原生DDoS防护是管不了的需要跟Web应用防火墙等应用层安全能力配合。我现在的防护架构是四层纵深网络层DDoS清洗负责容量型攻击传输层限制连接速率应用层WAF处理协议漏洞最外层业务逻辑做风控和人机校验。每一层都有明确的职责边界。攻击者突破了网络层的防护到传输层还有连接数限制等着就算伪装成正常请求混进了应用层WAF和业务风控也能兜底。原生DDoS防护不是银弹它是这套纵深防御体系里最外面的一层盾牌别期待一个产品解决所有安全问题。6. 低延迟观测方法别只看Ping值要看整条路径6.1 端到端观测从TCP握手时延到请求完成时延很多团队在验证防护是否低延迟时习惯直接用本机Ping一下公网IP看数值这个方法误差很大。第一清洗节点和网络设备通常不回应ICMP包Ping的数值根本代表不了真实业务链路第二即使用了TCP Ping不同地域、不同运营商访问同一目标的结果差异也很大单点数据没有参考价值。我更推荐的方法是从多个地域的探针发起TCP连接分别记录TCP建连时延、首字节时延TTFB和完整请求完成时延。TCP建连时延反映的是链路基础质量TTFB能看出中间是否有额外的检测处理完整请求时延则直接体现用户体感。尤其是TTFB这个指标如果防护方案在转发路径上加了深度检测TTFB一定会出现肉眼可见的上涨这是验证“低延迟”最直接的证据。观测指标和核心关注点可以参考这个表观测指标推荐工具核心关注点TCP建连时延自建探针脚本、多地域拨测链路基础质量攻击期间是否异常抬高首字节时延TTFB浏览器开发者工具、拨测平台中间是否有额外检测处理请求完成时延APM工具、接口监控用户真实体感最接近业务验收线丢包率自建探针、网络监控平台是否出现清洗回注异常持续观测比单次测试更有价值。攻击不是一次性事件防护效果的验证也应该是一条连续的曲线而不是一个时点快照。我们在监控面板上单独开了一个“攻击时段与业务时延对比”视图每次攻击结束后自动归档方便月度复盘。6.2 哪些业务需要额外叠加高防IP或CDN原生防护的适用场景是“业务整体在云上”但现实中还有两类情况需要额外叠加其他防护方案。一类是源站不在云上比如业务服务器还在自建机房只是通过专线或者公网链路接入云网络。这种情况下需要先评估回源链路的质量如果链路本身不够宽清洗后的流量回传会卡在最后一公里延迟照样上不来。另一类是源站IP已经暴露的情况。攻击者如果已经拿到了源站真实IP可以直接绕过所有云端防护把流量打在源站上这时候再强的T级防御也没用。我的教训是源站IP一定不能出现在DNS解析里回源方向只允许白名单IP业务服务器的防火墙也要按这个逻辑收敛。如果实在无法隐藏源站IP就考虑把独立高防IP作为显式入口让源站彻底变成一个“对外不可见”的存在。最稳妥的组合方案是“CDN承接边缘流量 原生防护兜底云入口 源站白名单收敛”三层联动。CDN负责把静态请求拦在最外层动态请求回源时由云入口处的原生防护做清洗源站只响应白名单回源请求。这套架构我们跑了将近半年整体延迟增量控制在可以接受的范围内稳定性和运维体验都不错。做DDoS防护这半年多我最深的体会是别把“防住了”当成胜利防护是场持续对抗攻击手法在变业务流量也在变策略必须跟着调。最后分享一个小建议——准备一份“攻击专项预案”文档把各类攻击的处置动作、联系人、阈值清单、升级条件都写进去真出事的时候照着执行就行不用临场想。预案里尤其要写清楚一件事什么时候决定暂时关停受损业务这个决策比任何产品选型都重要。防护的最终目标是让安全方案不成为业务的瓶颈而这一点火山引擎原生DDoS防护的低延迟设计确实做到了。