防御DDoS攻击业务带宽预留应对突发攻击流量

带宽预留这件事，很多企业是在第一次被打到业务全断时才意识到其价值。DDoS攻击流量往往在几十秒内就能从正常水平拉到几十Gbps甚至上百Gbps，如果完全依赖云端清洗或运营商黑洞路由的触发时间，业务中断几乎是必然的。所谓带宽预留，不是在攻击发生后才去扩容，而是提前在业务入口、上游链路和清洗设备之间保留一条“缓冲带”，让突发流量有地方可去、有时间可解。

先明确一个核心问题：带宽预留和带宽冗余不是一回事。冗余是指日常业务带宽之外多买一些余量，比如业务峰值10Gbps、买15Gbps，这叫冗余。而带宽预留更偏向策略层面，是在攻击场景下，为攻击流量和清洗后的正常流量分别规划承载路径和容量阈值。简单说，冗余解决的是“正常业务涨了怎么办”，预留解决的是“攻击流量涌进来时，你的防护动作会不会把自己也掐死”。

很多企业部署了抗DDoS设备或者接入了云清洗服务，但攻击一来依然出问题，原因往往不在防护能力，而在带宽预留逻辑错误。比如一条主链路总带宽20Gbps，日常业务占用5Gbps，抗D设备串联在链路上。当攻击流量达到18Gbps时，链路还没有完全塞满，但抗D设备如果处理性能只有10Gbps，设备本身就会先成为瓶颈。此时即使云端清洗中心能扛住200Gbps，流量在到达清洗中心之前，已经把本地链路和设备压垮了。

另一个常见问题是回注路径。清洗后的正常流量需要回注到源站，如果回注链路的带宽预留不足，或者回注流量和攻击流量走了同一条物理路径，清洗就失去了意义。正确的做法是把“攻击入口带宽”和“清洗后回注带宽”分开规划，并且回注链路要预留出正常业务峰值的1.2到1.5倍容量。

第一是运营商上游入口。攻击流量先经过这里，如果这一层的带宽预留不足，运营商可能会直接触发黑洞路由，把所有流量丢弃，包括正常用户。很多企业等到业务全断才发现，运营商的黑洞阈值是固定的，比如超过链路带宽的90%就自动黑洞。因此，与运营商协商调整黑洞阈值、或者在上游增加一条专门用于攻击引流的大带宽链路，是带宽预留的第一步。

第二是清洗设备或云清洗平台的接入容量。无论是本地抗D设备还是云清洗，都需要有足够的接入带宽来“接住”攻击流量。如果清洗平台的接入带宽小于攻击峰值，清洗平台本身就会被流量冲垮。这里有一个常见误区：认为买了100Gbps的云清洗服务，就能防住100Gbps的攻击。实际上，如果本地到云清洗平台的链路只有10Gbps，攻击流量在到达云清洗平台之前就已经把本地链路堵死了。所以带宽预留必须覆盖从攻击入口到清洗节点的整条路径。

第三是清洗后的正常业务回注带宽。回注带宽不需要等于攻击带宽，但必须大于正常业务流量。攻击时正常业务流量可能会下降，但也可能因为用户重试、TCP重传等原因出现短时上升。建议回注带宽预留为正常业务峰值的1.5倍以上，并且与攻击入口链路物理隔离。

预留带宽的计算不能拍脑袋，需要基于历史攻击数据和业务模型。一个实用的公式是：预留带宽 = 历史最大攻击峰值 × 1.2 + 正常业务峰值。如果企业从未遭遇过大流量攻击，可以参考同行业公开的攻击案例数据，或者使用第三方威胁情报平台的历史攻击统计。对于电商、游戏、金融等高频攻击行业，预留带宽建议至少覆盖到历史最大攻击峰值的1.5倍。

但这里有一个成本问题。如果历史最大攻击峰值是300Gbps，按1.2倍预留就是360Gbps，这个带宽成本对大多数企业来说难以承受。所以更实际的做法是分层预留：本地链路只预留到能触发云清洗的阈值，比如本地链路预留50Gbps，超过50Gbps的流量自动牵引到云清洗平台，云清洗平台按需弹性扩容。这样本地带宽成本可控，云清洗的弹性带宽只在攻击发生时付费。

带宽预留如果只靠人工操作，在攻击发生时根本来不及。必须与流量监测和自动化调度系统联动。当入口流量达到预留带宽的70%时，系统应自动触发告警并开始准备清洗资源；达到85%时，自动启动流量牵引，将攻击流量导入清洗平台；达到95%时，启动备用链路或扩容策略。这个过程需要在秒级完成，否则预留带宽就只是纸面数字。

自动化调度系统需要具备两个核心能力：一是实时流量可视化，能区分正常流量和攻击流量的比例；二是策略编排能力，能根据攻击类型和流量规模自动选择清洗路径。比如针对SYN Flood和UDP Flood，清洗策略不同，回注路径也可能不同。如果自动化系统不能区分攻击类型，预留带宽可能被错误分配。

第一种错误是只预留了入口带宽，没有预留清洗设备与回注链路之间的带宽。攻击流量进入清洗设备后，清洗设备需要将正常流量回注到业务网络，如果这段链路带宽不足，正常流量会丢包，用户感知就是业务时断时续。很多企业攻击时业务没完全断，但用户体验极差，原因就在这里。

第二种错误是把带宽预留等同于买更大的带宽包。带宽预留的核心是路径规划和策略联动，不是单纯堆带宽。如果路径设计不合理，比如攻击流量和正常流量混在一起，即使买了再大的带宽，攻击流量也会抢占正常流量的资源。

第三种错误是忽视了DNS和API网关等前置节点的带宽预留。很多DDoS攻击直接打向DNS服务器或API网关，这些节点如果带宽预留不足，即使源站带宽充足，用户也无法解析域名或调用接口，业务同样不可用。

对于游戏业务，UDP协议的攻击占比很高，而且游戏对延迟极其敏感。带宽预留不仅要考虑容量，还要考虑延迟。建议游戏业务在主要用户区域部署多个入口节点，每个节点预留独立带宽，攻击时通过智能DNS将用户调度到未受攻击的节点。这种分布式带宽预留比单纯在单一入口堆带宽更有效。

对于电商业务，攻击往往集中在促销活动期间，比如双十一、黑五。这类业务需要提前与运营商和云清洗服务商沟通，在活动期间临时提升带宽预留额度。活动结束后再恢复日常预留水平，这样能平衡成本和防护效果。

对于金融业务，攻击往往伴随着勒索和精准打击，攻击流量可能不大，但非常精准，比如直接打向某个支付接口。这类业务需要在应用层做细粒度的带宽预留，比如为关键API接口单独规划带宽通道，确保攻击时核心交易链路不受影响。

带宽预留最大的阻力是成本。很多企业认为预留带宽是“白花钱”，因为攻击不发生时，预留的带宽闲置。但实际上，带宽预留的成本远低于攻击造成的业务损失。一次大流量DDoS攻击导致的业务中断，损失可能是预留带宽年费的几十倍。关键在于如何设计弹性预留方案，让日常成本可控。

一种常见的做法是“基础预留+弹性扩容”。日常只预留正常业务峰值的1.2倍带宽，这部分成本固定。与云清洗服务商签订弹性带宽协议，攻击发生时自动扩容，按实际使用的攻击带宽计费。这样日常成本低，攻击时又有足够的带宽可用。但需要注意，弹性扩容的生效时间必须足够快，否则攻击已经造成损失，扩容才生效就没有意义了。

另一种做法是与运营商建立“清洗带宽池”。多个企业共享一个大的清洗带宽池，攻击发生时从池中分配带宽。这种模式成本较低，但需要运营商有较强的调度能力，而且共享池的带宽在多家企业同时遭受攻击时可能不够用。

带宽预留方案不能停留在纸面上，必须定期验证。很多企业的预留带宽在真实攻击中失效，是因为从来没有测试过。建议每季度进行一次模拟攻击演练，使用受控的攻击流量测试从入口到清洗再到回注的整条链路。演练中重点关注三个指标：流量牵引时间、清洗生效时间、正常业务丢包率。

演练时还要验证自动化调度系统的触发逻辑。比如设置一个模拟攻击流量，观察系统是否能在预设阈值触发告警和清洗。如果自动化系统没有按预期工作，预留带宽再充足也无济于事。

另外，带宽预留方案需要与业务增长同步更新。很多企业做完一次带宽预留规划后就不再调整，但业务流量在增长，攻击流量也在增长。建议每半年重新评估一次预留带宽，根据最新的业务峰值和历史攻击数据调整预留额度。

带宽预留不是一次性的配置，而是一个持续优化的过程。攻击者的手法在变，攻击流量在增长，业务架构在演进，带宽预留策略也必须跟着调整。真正有效的带宽预留，是在攻击发生前就已经把路径、容量、自动化策略全部准备好，让突发攻击流量有地方可去，让正常业务流量有路可走。