攻击流量的特征不是"平稳增长"，而是"突然跃升"。一个正常运行的业务，可能在几秒内从常态流量跳到每秒数百G的攻击峰值。这种情况下，防护容量能否在攻击突发的瞬间自动扩容，直接决定了业务会不会被打穿。
本文拆解高防CDN弹性防护的三种机制，说明攻击突发时清洗容量如何自动扩容。
一、带宽池共享：不依赖单节点扩容
传统高防方案的扩容逻辑是"单节点扩容"——某个节点被打满时，通过人工或自动方式为该节点增加带宽。这种逻辑在攻击突发场景下有一个致命缺陷：扩容需要时间。从检测到攻击、到决策扩容、到带宽实际可用，通常需要几分钟。而攻击峰值可能在几十秒内就打穿节点。
弹性防护的第一种机制是带宽池共享。服务商将所有清洗节点的带宽资源汇集成一个"资源池"，当某个节点遭受攻击时，调度系统从资源池中调配带宽支援该节点，而不需要等待物理扩容。这种机制的前提是服务商的清洗节点总数足够多，资源池的冗余足够大。这与高防CDN清洗容量冗余评估中提到的节点冗余逻辑是直接相关的。
二、节点间调度：把流量分散到有冗余的节点
弹性防护的第二种机制是节点间调度。当某个清洗节点检测到攻击流量超过其容量阈值时，调度系统自动将部分流量牵引到其他有冗余容量的节点。这个过程在秒级完成，不依赖人工介入。
节点间调度的核心是调度决策的实时性。调度系统需要实时监控各节点的带宽使用率、PPS处理率、CPU利用率、清洗设备健康状态，并根据这些指标动态调整流量分配。如果调度决策是周期性的（例如每5分钟更新一次），那么在攻击突发的瞬间，调度系统可能还来不及响应。这与高防CDN节点调度与近源清洗中提到的攻击态自适应机制是同一套逻辑。
节点间调度还有一个隐性要求：调度切换不能影响已建立的会话。 对于TCP长连接业务（如WebSocket、游戏协议），流量牵引到新节点时需要保持连接状态，避免玩家掉线。这需要调度系统支持连接迁移或会话保持机制。
三、弹性计费：按攻击峰值计费而非按常态计费
弹性防护的第三种机制是弹性计费。传统高防套餐按固定防御峰值计费，用户需要为"可能用不上的防护容量"付费。弹性计费则按实际攻击峰值计费，攻击发生时自动扩容，攻击结束后自动恢复常态，用户只需要为实际使用的防护容量付费。
弹性计费对业务波动大的场景尤其友好。例如电商大促、游戏开服、直播赛事这类业务，平时流量平稳，但特定时段可能遭遇攻击。弹性计费让这些业务的防护成本与实际风险挂钩，而不是为峰值预留大量闲置容量。
评估弹性计费时需要确认：扩容的触发条件是什么？扩容的响应时间是多少？扩容后的计费方式如何？ 如果扩容触发条件是人工确认，那么弹性计费就失去了意义——攻击突发的瞬间根本没有时间等人确认。成熟的弹性计费方案应该是自动触发、秒级响应、按实际使用量计费。
| 机制 | 核心逻辑 | 响应时间 | 适用场景 |
|---|---|---|---|
| 带宽池共享 | 汇集所有节点带宽资源，按需调配 | 秒级 | 攻击峰值超出单节点容量 |
| 节点间调度 | 将流量牵引到有冗余的节点 | 秒级 | 攻击集中在某一区域 |
| 弹性计费 | 按实际攻击峰值计费，自动扩容 | 自动触发 | 业务波动大、攻击不确定性高 |
四、弹性防护的边界条件
弹性防护不是无限的。评估时需要注意三个边界条件。
资源池的总容量是上限。 带宽池共享和节点间调度只能在服务商拥有的总资源池内调配。如果攻击峰值超过了资源池的总容量，调度系统也无能为力。因此，选型时需要确认服务商的清洗资源池总容量是否覆盖业务可能面临的攻击峰值。
调度切换可能引入额外延迟。 当流量从节点A被牵引到节点B时，流量路径发生了变化，可能引入额外的网络延迟。对于延迟敏感的业务，需要在弹性防护和延迟之间做取舍。
弹性计费可能有最低承诺消费。 部分服务商的弹性计费方案要求用户承诺最低月度消费，即使用户当月没有遭遇攻击。选型时需要确认计费模式的具体条款，避免隐性成本。
五、结语
弹性防护的核心是"在攻击突发的瞬间自动扩容"，而不是"事后手动扩缩容"。带宽池共享、节点间调度、弹性计费三种机制协同工作，才能在攻击峰值突然跃升时守住业务。评估时需要确认扩容是否自动触发、响应时间是否在秒级、资源池总容量是否足够、调度切换是否影响会话连续性。这四件事，比"防御峰值是多少T"更能说明一套高防CDN在真实攻击场景下的弹性能力。
相关阅读：如果你想了解清洗容量冗余的评估方法，高防CDN清洗容量冗余怎么评估拆解了PPS与带宽的匹配逻辑；关于节点调度的完整机制，高防CDN节点调度与近源清洗中有详细说明。
