企业官网建设流程全解析

做实时互动业务的这两年，我被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以上。跨运营商的回源链路还要再加一跳，问题更明显。

我整理过不同接入方式下的链路差异，可以参考：

所以我对“原生”二字的兴趣，最初就是从延迟痛点来的。

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上下；攻击流量刚开始到达的那一两秒，出现了明显抖动，网络时延短暂拉升到数百毫秒甚至更高；清洗策略稳定生效后，时延回落到正常水位，和没有攻击时几乎一致。

这个过程说明一个关键问题：攻击发生时的瞬时卡顿，主要是攻击洪峰到达节点时造成的瞬时拥塞，而不是清洗机制本身引入的开销。防护能不能做到低延迟，看的是清洗稳定后业务链路是否恢复原样，而不是攻击发生的那一瞬有没有波动——那一下的波动，任何做了防护的方案都很难完全避免。

测试阶段我记录了一张简化表，供大家参考：

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一定会出现肉眼可见的上涨，这是验证“低延迟”最直接的证据。

观测指标和核心关注点可以参考这个表：

持续观测比单次测试更有价值。攻击不是一次性事件，防护效果的验证也应该是一条连续的曲线，而不是一个时点快照。我们在监控面板上单独开了一个“攻击时段与业务时延对比”视图，每次攻击结束后自动归档，方便月度复盘。

6.2 哪些业务需要额外叠加高防IP或CDN

原生防护的适用场景是“业务整体在云上”，但现实中还有两类情况需要额外叠加其他防护方案。

一类是源站不在云上，比如业务服务器还在自建机房，只是通过专线或者公网链路接入云网络。这种情况下需要先评估回源链路的质量，如果链路本身不够宽，清洗后的流量回传会卡在最后一公里，延迟照样上不来。

另一类是源站IP已经暴露的情况。攻击者如果已经拿到了源站真实IP，可以直接绕过所有云端防护，把流量打在源站上，这时候再强的T级防御也没用。我的教训是：源站IP一定不能出现在DNS解析里，回源方向只允许白名单IP，业务服务器的防火墙也要按这个逻辑收敛。如果实在无法隐藏源站IP，就考虑把独立高防IP作为显式入口，让源站彻底变成一个“对外不可见”的存在。

最稳妥的组合方案是“CDN承接边缘流量 + 原生防护兜底云入口 + 源站白名单收敛”，三层联动。CDN负责把静态请求拦在最外层，动态请求回源时由云入口处的原生防护做清洗，源站只响应白名单回源请求。这套架构我们跑了将近半年，整体延迟增量控制在可以接受的范围内，稳定性和运维体验都不错。

做DDoS防护这半年多，我最深的体会是：别把“防住了”当成胜利，防护是场持续对抗，攻击手法在变，业务流量也在变，策略必须跟着调。最后分享一个小建议——准备一份“攻击专项预案”文档，把各类攻击的处置动作、联系人、阈值清单、升级条件都写进去，真出事的时候照着执行就行，不用临场想。预案里尤其要写清楚一件事：什么时候决定暂时关停受损业务，这个决策比任何产品选型都重要。防护的最终目标，是让安全方案不成为业务的瓶颈，而这一点，火山引擎原生DDoS防护的低延迟设计确实做到了。