内容分发网络（CDN）已经从单一厂商的自建体系，逐步演化为横跨多个云服务商、多个CDN提供商的分布式协作系统。IETF的CDN运作组（CDNI WG）近年来推出了一系列RFC和草案，用于规范CDN之间的互联与互通，其中涉及HTTP转发、日志传递、元数据交换等多个方面。与此同时，QUIC和HTTP/3的落地让CDN的传输层发生了根本性变化。本文将围绕多云CDN相关的RFC草案展开解读，把协议标准与工程实践结合起来，帮助读者建立完整的知识框架。
CDNI框架：多云CDN的协议基石
CDNI的全称是Content Delivery Networks Interconnection，即内容分发网络互联。它由一组RFC组成，其中RFC 6707定义了整体问题域和框架，RFC 8006定义了CDN米数据（CDN Metadata）接口，RFC 8007定义了CDN控制接口，RFC 8008则规范了请求路由的模型。这些文档共同回答了一个核心问题：当一个CDN节点无法服务某个用户请求时，如何把这个请求安全、可控地传递给另一个CDN。
在多云场景下，CDNI的价值尤为突出。假设一家企业同时使用了两家云厂商的CDN服务，主CDN在某个区域没有覆盖节点，就需要将请求委派给下游CDN。CDNI规定了两种委派方式：一种是通过DNS重定向，即在DNS响应中返回下游CDN的权威域名；另一种是通过HTTP重定向，即在响应中返回指向下游CDN的302状态码和新URL。RFC 8008对这两种方式的适用场景做了细致区分，DNS重定向适合粗粒度的区域级调度，HTTP重定向则适合细粒度的内容级调度。
此外，CDNI还定义了一个关键的请求头CDNI-Request族，用于在两个CDN之间传递原始请求的上下文信息，例如客户端IP、原始主机名等。RFC 8009专门规定了如何在HTTPS场景下通过Forwarded头安全地传递这些信息，避免客户端真实地址在多层委派中丢失。理解这套接口体系，是读懂后续所有多云CDN草案的前提。
CDN绑定与SVCB记录：请求路由的新方案
传统的CDN请求路由依赖DNS和HTTP重定向，但这两种方式都有明显的缺陷。DNS重定向会增加一次额外的域名解析，HTTP重定向则会让客户端多发起一次请求，两者都会增加延迟。为了解决这个问题，IETF正在推进CDN Binding（CDN绑定）相关的草案，尝试利用DNS的SVCB和HTTPS资源记录来简化路由流程。
SVCB记录最早在RFC 9460中标准化，它允许在DNS中直接描述服务的替代端点、端口和协议提示信息。CDN绑定草案的思路是：当一个域名需要通过多个CDN分发时，权威DNS可以直接返回多条SVCB记录，每条记录指向一个CDN的接入点，并携带各自的优先级和参数。客户端或本地解析器根据这些信息选择最合适的CDN，整个过程不需要HTTP层的二次重定向。
;; SVCB记录示例：域名同时绑定两个CDN example.ipipp.com. 300 IN HTTPS 1 cdn-a.ipipp.com. alpn=h3,h2 example.ipipp.com. 300 IN HTTPS 2 cdn-b.ipipp.com. alpn=h3,h2 ech=...
上面这个例子中，优先级为1的记录代表主CDN，优先级为2的记录作为备用。客户端在主CDN不可达时会自动降级到备用CDN，这实际上把故障切换的决策权从CDN层下沉到了客户端解析层。这种设计的优点是链路更短、切换更快，缺点是对老版本客户端的兼容性不够好，需要部署方做好灰度评估。草案中还讨论了与ECH（加密ClientHello）配合使用时如何保护用户访问目标的隐私，这也是目前讨论最热烈的部分。
QUIC与HTTP/3：CDN传输层的性能重构
QUIC在RFC 9000中标准化，HTTP/3则在RFC 9114中定义。相比运行在TCP上的HTTP/1.1和HTTP/2，QUIC最大的变化是把传输层加密和传输层握手合并，将建立安全连接所需的往返次数从两三次压缩到一次，理想情况下甚至可以做到零往返恢复。对CDN而言，这直接缩短了用户首次访问边缘节点的等待时间，尤其是对短连接、高并发的动态内容加速场景，效果非常明显。
在CDN回源链路上，QUIC同样有发挥空间。边缘节点需要频繁地向源站或者上游CDN回源，如果回源连接基于TCP，每次新建连接都要经历完整的三次握手加TLS握手。基于QUIC的回源可以让边缘节点复用会话票据，实现零往返时间的连接恢复。同时，QUIC的连接迁移特性意味着即使边缘节点的网络路径发生变化，连接也不会中断，这对于多线接入的CDN节点十分有价值。
不过，QUIC运行在UDP之上，也带来了一些工程挑战。首先是内核缓冲区的调优问题，Linux上UDP的默认缓冲区往往偏小，高吞吐的QUIC流量容易触发丢包，需要通过sysctl调大net.core.rmem_max和net.core.wmem_max。其次是负载均衡问题，传统四层负载均衡器基于TCP连接做会话保持，而QUIC连接由连接ID标识，负载均衡器必须解析QUIC包头中的连接ID字段，才能把属于同一连接的包转发到同一台后端节点。IETF的QUIC负载均衡草案正是为此而生，它规范了连接ID的编码方式，让负载均衡器可以从连接ID中直接推导出路由信息，而不需要维护庞大的会话表。
多云场景下的工程落地建议
将CDNI、CDN绑定和QUIC这些协议组合落地，需要一套清晰的工程路径。第一，接口对接上，多云CDN之间的元数据同步建议采用RFC 8006定义的CDN Metadata模型，用JSON描述主机名、采集策略和传递策略，保证不同厂商的系统之间有一致的理解。第二，请求路由上，可以采取渐进式策略，先在内部灰度SVCB记录，观察老客户端的回退行为，确认兼容性后再逐步扩大范围。第三，传输层上，边缘节点与上游之间的回源链路优先启用HTTP/3，并配置充分的连接复用与会话恢复参数。
# 调整UDP缓冲区以支持高吞吐QUIC流量 sysctl -w net.core.rmem_max=16777216 sysctl -w net.core.wmem_max=16777216 sysctl -w net.core.rmem_default=16777216 sysctl -w net.core.wmem_default=16777216
监控层面也要做相应调整。传统的CDN监控以HTTP状态码和TCP建连时间为主，引入QUIC后，需要额外关注QUIC层面的握手类型分布、丢包恢复统计和连接迁移次数。多云CDN还要求监控系统能够串联起多个厂商的链路数据，否则一旦出现跨CDN的委派故障，排查起来会非常困难。建议在每个委派边界上记录Forwarded头信息，将客户端IP、委派来源、时间戳统一写入访问日志，形成完整的调用链。
总的来说，多云CDN的RFC体系正在把原本各家私有封闭的CDN互联方式推向标准化。CDNI解决了CDN之间的互操作问题，CDN绑定草案优化了请求路由链路，QUIC与HTTP/3则重塑了传输层性能。对架构师而言，紧跟这些草案的演进，在合适的时间窗口引入对应能力，是构建高质量内容分发体系的关键。