防御DDoS攻击带宽资源规划应对业务增长

规划DDoS防御带宽不能只看当前业务流量峰值，必须把业务增长模型、攻击流量模型和清洗链路冗余同时纳入计算。多数企业出现防御失效，不是因为设备性能不够，而是带宽资源在规划阶段就低估了“正常业务增长”和“攻击突发”叠加后的瞬时需求。一个可执行的思路是：以未来12到18个月的业务带宽峰值为基准，再叠加至少1.5到2倍的攻击冗余，最后按清洗中心可承载的转发能力反推接入带宽。

业务带宽规划的第一个错误是用月平均流量或日平均流量来推算防御带宽。DDoS防御资源对应的是瞬时并发峰值，尤其是业务大促、版本发布、直播活动或集中结算时段的流量尖峰。你需要从监控系统中提取过去6个月每5分钟粒度的出口带宽峰值，找出P99或P100的峰值区间。如果业务处于增长期，还要乘以增长系数。例如当前峰值是10Gbps，业务年增长率为60%，则12个月后的业务峰值约为16Gbps。这个16Gbps才是防御带宽规划的起点，而不是当前的10Gbps。

很多方案直接写“按业务带宽的3倍预留”，这种说法在资源规划上过于粗糙。攻击流量的大小取决于行业属性、业务暴露面、历史攻击记录以及是否容易被竞争对手或勒索组织盯上。金融、游戏、电商、SaaS平台遭受的攻击规模往往远高于企业官网。正确做法是拉取近两年内实际遭受的攻击峰值，同时参考同行业公开披露的攻击事件规模。如果历史最大攻击是40Gbps，业务峰值是16Gbps，那么防御带宽至少不能低于40Gbps。但还要考虑攻击手法变化，比如UDP反射放大、TCP SYN洪水、HTTP慢速攻击等对带宽消耗的差异。一个更稳妥的公式是：防御带宽 = max(历史最大攻击流量 × 1.5，未来业务峰值 × 3)。这样既考虑了攻击增长，也覆盖了业务突发。

很多企业在规划时只计算“进入机房的攻击流量”，却忽略了清洗设备或云清洗中心在转发干净流量时也会产生额外开销。无论是本地清洗设备还是运营商上游清洗，清洗过程中需要对数据包进行镜像、检测、丢弃和回注。回注流量通常比正常业务流量略高，因为存在协议栈重传、DNS重试、TCP握手重试等行为。实际经验中，清洗后的干净流量可能比正常业务流量高出10%到20%。如果你的业务峰值是16Gbps，清洗后回注流量可能达到18到19Gbps。因此接入带宽不能只按16Gbps计算，至少要预留到20Gbps。

带宽扩容不是即时完成的。无论是向运营商申请扩容、增加物理端口、调整BGP会话，还是扩容云清洗实例，都需要时间。国内运营商扩容通常需要3到15个工作日，云清洗服务升级可能较快，但涉及专线接入或跨地域调度时同样存在周期。规划时必须把扩容周期纳入时间轴。如果业务每季度增长15%，而带宽扩容周期是一个月，那么每次扩容的步长至少要覆盖未来两个季度的增长。否则会出现频繁扩容、业务中断或防御空窗。建议按季度做一次带宽资源评审，每次评审时用未来6个月的预测峰值来触发扩容决策。

本地清洗设备受限于机房接入带宽和硬件吞吐能力，适合防御中小规模、高频次攻击。云清洗中心带宽储备大，但流量调度需要时间，且回源链路质量会影响业务体验。合理的资源规划是本地防御覆盖日常攻击和瞬时小流量攻击，云清洗作为大规模攻击时的逃生通道。本地带宽可以按业务峰值的1.5到2倍配置，云清洗带宽则按历史最大攻击的2倍以上购买弹性容量。两者之间的切换阈值要提前设定，例如本地带宽利用率超过70%或攻击流量超过本地清洗能力80%时，自动触发云清洗调度。这样既避免本地资源浪费，又保证大流量攻击下有兜底。

带宽资源规划不能只看Gbps，还要看每秒新建连接数、并发连接数和包转发率。很多DDoS攻击的破坏力不在于带宽大小，而在于海量小包或连接耗尽。业务增长后，正常用户的连接数也会上升，如果防御设备的小包处理能力不足，即使带宽没跑满，业务也会出现卡顿或不可用。规划时要同时计算未来业务峰值下的CPS和并发连接数，并确保清洗设备、防火墙和负载均衡器在这些指标上有足够余量。例如当前业务峰值CPS是5万，年增长50%，则12个月后CPS约为7.5万。防御设备至少要有2倍以上的处理能力，即15万CPS以上，才能应对攻击时的连接洪水。

单点接入的带宽规划压力远大于分布式架构。如果业务部署在多个可用区或多个机房，攻击流量可以被分散，单点防御带宽需求会下降。但分布式架构也会带来新的问题：全局流量调度、DNS解析切换、跨机房回源延迟等。在做带宽规划时，要明确业务是否具备多入口调度能力。如果具备，可以按每个入口的业务峰值分别计算，再汇总为总防御带宽。如果不具备，只能按单点最大攻击来规划。对于快速增长的业务，建议在带宽规划的同时推进分布式部署，否则单点防御成本会随着业务增长呈非线性上升。

无限堆高防御带宽会造成严重的资源浪费。一条10Gbps的独享带宽和一条100Gbps的独享带宽成本差异巨大，而且日常业务根本用不到那么高。更合理的做法是采用“基础带宽+弹性带宽”的组合。基础带宽覆盖日常业务峰值和中小攻击，弹性带宽按需启用，按使用时长或流量计费。这种模式在云清洗服务中已经很成熟，但在本地机房或混合云场景下需要提前和运营商谈好弹性带宽的计费方式和启用速度。关键指标是弹性带宽的启用延迟，如果启用需要几个小时，而攻击在几分钟内就打满带宽，那弹性带宽就形同虚设。规划时要明确弹性带宽的触发条件和启用SLA。

业务增长往往伴随着新功能上线、新域名启用、新API开放或新地域部署。每一个新入口都可能成为攻击面，也会带来新的正常流量。带宽规划不能只盯着现有业务的流量曲线，还要和产品、研发、市场团队保持同步。例如计划上线一个文件上传下载功能，正常用户的带宽消耗可能比纯网页浏览高出数倍。再比如开放第三方API，攻击者可能通过API接口发起应用层攻击，消耗的不仅是带宽，还有后端计算资源。每个新功能上线前，都要评估其对带宽模型的影响，并更新防御带宽需求。

带宽资源规划完成后，必须通过压力测试和演练来验证。可以模拟业务峰值流量叠加攻击流量，观察清洗设备、出口路由器和上游链路的实际表现。测试中要重点关注几个指标：带宽利用率达到多少时开始出现丢包、清洗设备CPU和内存是否先于带宽成为瓶颈、回注流量是否正常、业务延迟是否在可接受范围内。很多规划在纸面上看起来合理，但实际测试中会发现设备的小包性能、会话表容量或日志处理能力先达到上限。测试结果要反哺规划模型，修正冗余系数和设备选型。

业务增长是动态的，攻击手法也在不断变化，带宽资源规划不能一劳永逸。需要建立一套持续监控机制，跟踪业务带宽峰值、攻击带宽峰值、清洗设备负载、弹性带宽使用率等核心指标。每周或每月生成带宽资源使用报告，当实际流量接近规划阈值的80%时触发预警。同时每季度重新评估增长模型和攻击趋势，调整未来6到12个月的带宽规划。只有把带宽资源规划变成一个持续迭代的过程，才能在业务增长和DDoS防御之间保持平衡，既不因资源不足导致业务中断，也不因过度冗余造成成本浪费。