DDoS攻击下CDN与源站协同防御的缓存策略设计

面对大流量DDoS攻击，传统的单一防御体系早已捉襟见肘。真正的难点不在于清洗流量，而在于如何在高强度冲击下，依然保证正常用户对动态内容的访问不受影响。这就引出了一个核心矛盾：CDN为了安全倾向于强力缓存，而源站为了保证业务实时性又不得不限制缓存。解决这个死结的唯一路径，就是设计一套CDN与源站之间的协同缓存策略，让缓存机制本身成为抗D的武器，而非仅仅是加速工具。

DDoS攻击在应用层往往呈现出极端的请求集中度。攻击者会针对特定的URL，例如搜索接口、登录页面或结算流程，发起每秒数十万次的请求。如果这些请求全部穿透CDN回源，源站带宽和计算资源会在几秒内耗尽。此时，CDN边缘节点的缓存策略就成了第一道生死线。关键在于，我们不能简单地设定一个固定的缓存时间（TTL），因为攻击期间正常用户的交互行为也在发生。如果对动态接口粗暴地设置长缓存，会导致用户看到过期数据，业务中断；如果不缓存，源站直接裸奔。因此，协同防御的第一步，是在攻击感知阶段，由源站向CDN下发动态的、针对特定URL的“锁定缓存”指令。这种指令不是基于常规的时间，而是基于“安全状态”，即只要攻击未结束，该URL在CDN层的缓存副本就被视为唯一有效版本，哪怕它只有10秒的生命周期，也要强制CDN在10秒内绝不回源校验。

传统的缓存策略是正向的，即根据资源类型预设规则。但在DDoS场景下，必须建立一套负反馈闭环。源站需要在边缘代理层暴露其真实的健康指标，不是简单的HTTP 200状态码，而是包含连接池耗尽程度、CPU负载、数据库慢查询堆积量的结构化“压力向量”。CDN在接收到回源请求的响应时，除了缓存响应体外，还必须解析这个压力向量。当压力向量中的某一项阈值被突破，例如数据库连接池占用超过90%，CDN需要立即启动“自保模式”。在这个模式下，CDN不再严格遵守源站返回的Cache-Control头，而是自动将非幂等请求之外的GET请求缓存时间延长到一个预设的“逃生舱”值。这种设计相当于把源站的生理指标直接映射为CDN的缓存策略参数，源站越痛苦，CDN缓存得越死，直到源站呼吸平顺为止。

攻击流量的另一个致命特征是高并发重复请求。在攻击瞬间，可能有5万个请求同时请求同一个商品详情页，且这些请求在CDN节点上恰好都没有命中缓存。如果不加处理，这5万个请求会同时涌向源站，形成惊群效应。协同防御的缓存策略必须包含“请求折叠”机制。CDN在接收到请求时，如果发现该资源不在缓存中且已有相同URL的请求正在回源，不应再发起新的回源连接，而是将当前请求挂起到一个等待队列中。源站响应回来后，CDN将该响应广播给队列中所有等待的请求。更进一步，源站可以主动向CDN推送“热点预告”。通过实时分析日志，源站一旦发现某个冷门资源突然被高频访问，可以在收到第一个回源请求时，在响应头中携带一个特殊标记，告诉CDN：“此资源即将被攻击，立即将其纳入永不回源白名单，并启用请求折叠。”这样，第一个请求完成回源后，后续的海量攻击请求在CDN边缘就被直接折叠吸收，源站只承受了1次访问压力。

对于大文件下载或视频流场景，攻击者往往会通过Range请求发起分片DDoS，通过请求文件的极小片段来耗尽源站IO。此时，全文件缓存策略失效，因为攻击者请求的片段千奇百怪。协同防御需要设计一种“分片重组缓存”策略。CDN在接收到Range请求时，如果发现该文件的其他分片正在遭受高频请求，不应机械地透传Range头。CDN可以采取“全量拉取”策略，即忽略攻击者的Range请求，直接回源拉取整个文件，并在边缘节点强制缓存完整文件。一旦完整文件缓存完成，后续所有分片请求都在CDN内存中直接切割响应。源站需要配合的是，对于这种异常的全量拉取请求，要提供一种“无状态传输”模式，不占用应用服务器的连接资源，而是直接从静态存储层通过sendfile系统调用零拷贝传输，以此降低源站的CPU开销。这种策略虽然增加了单次回源的带宽成本，但彻底消灭了后续的IO攻击。

这是最具挑战性的一环。对于包含用户登录态、购物车信息的动态接口，传统CDN只能透传。但在DDoS攻击下，必须让CDN具备“有限逻辑执行”能力。通过边缘计算，源站可以将部分业务逻辑和令牌校验算法下发到CDN边缘。具体来说，源站将用户认证令牌的校验密钥和算法部署到CDN的EdgeWorker中。攻击请求到达CDN时，CDN首先在边缘校验令牌合法性。对于令牌缺失或伪造的请求，直接在边缘返回拦截页面，这些拦截页面本身被极度缓存。对于携带合法令牌的请求，CDN才进行后续的缓存查找。更进一步，对于“库存查询”这类准动态接口，源站可以将库存状态抽象为一种“状态令牌”，并以极短的TTL（如2秒）下发给CDN。CDN根据这个状态令牌，在2秒内自行响应所有查询请求，无需回源。这种策略将源站从高频的、重复的逻辑计算中解放出来，只负责在状态变更时推送新的令牌。

攻击者常常利用URL参数排序不同、大小写差异或添加随机后缀来绕过CDN缓存。协同防御策略必须在CDN和源站之间统一“缓存键规范”。源站需要在应用启动时，向CDN下发一份“参数白名单”和“排序规则”。CDN在计算缓存键时，严格剔除白名单外的参数，并对参数进行字典序排序。例如，对于URL中的随机时间戳或来自攻击工具的特定特征码，CDN在计算缓存键时直接丢弃。更高级的做法是，源站通过实时分析攻击样本，动态生成“参数黑名单正则表达式”，通过API实时推送给CDN。CDN在收到请求后，如果命中黑名单参数，不仅不将其作为缓存键的一部分，甚至可以直接将该请求标记为低优先级请求，在节点负载高时优先丢弃。这种协同确保了攻击者无法通过变换参数来穿透缓存，将攻击面压缩到了最小范围。

当攻击流量大到足以拥塞CDN与源站之间的回源链路时，任何实时协同都可能失效。因此，必须预设一套“离线缓存”策略。CDN需要在日常运行中，根据源站提供的“关键资源清单”，主动抓取并永久缓存这些资源的副本。这份清单不是简单的URL列表，而是包含资源优先级、校验和以及静态化版本的完整快照。一旦CDN检测到源站完全不可达，立即切换到离线模式。在这个模式下，CDN不再尝试任何回源，而是直接使用预置的快照版本响应所有请求。对于必须登录的动态页面，CDN返回一个极度简化的静态“维护中”页面，但这个页面本身也经过了缓存优化，能够承受海量并发。源站在恢复后，会先与CDN进行缓存校验同步，增量更新变更内容，再逐步切回在线模式。这种设计确保了即使在最恶劣的“断网式”攻击下，核心内容的只读访问依然可用。

上述所有协同策略都依赖于CDN与源站之间的控制信令能够可靠传输。在DDoS攻击中，源站的公网IP往往被直接攻击，导致CDN的回源控制接口无法访问。因此，必须为协同信令建立带外通道。源站除了主IP外，还应提供一组通过不同运营商、不同AS域接入的备用IP，甚至可以通过消息队列服务作为信令中转。CDN的调度中心在检测到主控制接口超时时，自动切换到备用通道下发缓存锁定指令。同时，源站应具备“信令抢占”能力，即使在带宽被DDoS打满的情况下，也能通过预留的极小带宽或独立的管理网卡，向CDN发出最高优先级的“熔断”指令，强制CDN进入全局缓存模式。这种冗余设计保证了控制平面在数据平面被摧毁时依然能够运作。

在协同防御中，一个常见的误区是过度关注缓存命中率。在DDoS攻击期间，由于攻击请求大量命中缓存，CDN的缓存命中率指标反而会变得异常好看，可能达到99%以上。但这并不能反映真实防御效果，因为正常用户的非缓存请求可能已经被挤压。因此，协同策略必须监控“有效缓存命中率”，即剔除被标记为攻击特征的请求后，正常用户的缓存命中情况。源站需要向CDN提供真实的“用户转化数据”或“业务成功率”作为反馈。如果CDN的缓存策略过于激进，导致正常用户的动态请求被错误地缓存，业务成功率会下降。协同防御的终极目标不是追求100%的缓存命中率，而是在保证业务成功率的前提下，将回源请求数压制在源站承载极限的50%以下。这需要CDN和源站共享业务指标，而不仅仅是机器指标。