摘要

  • RFC 3466 描述独立内容网络如何共享资源，从而扩大各自的规模或覆盖范围。
  • 它提出的是信息性模型与共同术语，不是 CDN 互联协议、价格表、服务授权，也不证明网络间确实建立了合作。

数据包不再能讲完全部故事

浏览器请求一张图片，源站可能远在他处，附近缓存未必存有这份内容，而单一服务商也未必有足够的节点覆盖所有用户。2000 年代初，解决办法逐渐延伸到能理解应用请求和内容的设施，而不只是读取 IP 首部的网络设备。

RFC 3466 于 2003 年 2 月发布，将这类设施称为“内容网络”。它描述的是第 4 至第 7 层上的功能：处理请求、响应，以及可能跨越许多数据包的对象。这不是要取代 IP 路由，而是在其上增加一个协调面：内容在哪里、请求送往何处、副本如何移动、活动怎样记账。

该文也刻意放弃了一个容易带入误解的类比。“Content peering”或“CDN peering”听起来像 IP 网络互联，仿佛自然带有开放交换、互惠或结算等规则。工作组改用“content internetworking”。改名没有解决互联问题，却避免由一个熟悉的词替参与方预设答案。

一次交付，四种不同职能

RFC 3466 将 CDN 拆成四类职能。请求路由把用户代理引向合适的替代服务器；分发将发布者控制的内容从源站送到替代服务器，可以预先放置，也可以在请求后获取；交付是替代服务器向客户端返回内容；记账则记录路由、分发和交付活动，可能供之后转移资金、商品或责任使用。

四类职能留下的证据并不相同。发生重定向，不代表内容已经到达。替代服务器有副本，不代表客户端曾被引导到那里。一次成功响应，也未必能证明上游由哪个网络提供内容。日志记录更不等于双方认可的账单。模型的价值，正是让这些动作能被分别命名。

控制权也分布在不同参与方手中。发布者最终控制内容及其分发；源站保存主副本或权威副本；替代服务器负责交付，却不是源站。内容互联网关可以是分发、请求路由、记账的接点，也可以只承担其中一部分。互联并不要求一个网络公开所有内部机制。

黑箱之间仍须有合作协议

把相邻网络当作“黑箱”，并不意味着插上接口就能互操作。RFC 3466 将“协商关系”定义为：其条款部分或全部在内容互联协议之外建立。网络可以共享资源、隐藏内部拓扑，但共同术语无法决定哪些内容可复制、可以在哪里交付、哪些活动需要收费，或谁为错误账目负责。

网关或许能扩大可达范围，外部协议却仍会限定可处理的内容、账务明细与责任分担。技术上有效的请求路径，不等于有权交付任何对象。互联还要面对伙伴身份、内容完整性和账务数据可审计性等问题。RFC 3466 提出这些安全关注点，但没有逐一规定实现机制。

先画地图，再造机器

RFC 3466 是一份 Informational 文档：它提供模型，不是标准轨协议。到 2012 年，RFC 6707 仍将 CDN 互联界定为待解决的问题，围绕控制、请求路由、元数据和日志提出接口问题，并把商业关系排除在范围之外。这个后续节点只能说明历史脉络，不能代表今天的部署状态。

因此，RFC 3466 的历史贡献在于划出边界：不同网络可以讨论如何共享覆盖，却不能假定共同词汇自动创造了开放市场。路径、副本、服务许可和账单仍各自需要凭据。

来源