摘要

  • RFC 3568 是 2003 年发布的 Informational 调查，概括截至 2000 年 12 月已知或使用的 DNS、传输层与应用层请求路由机制；它不是互联网标准，也不是当代部署报告。
  • “最佳替代服务器”不是服务器的固有属性，而是观察者、可见请求者、候选集、指标方向与新鲜度、策略权重以及交接方式共同生成的有期限结论。

DNS 请求里通常没有客户端地址。专用 DNS 服务器能按策略返回不同的 A、NS 或 CNAME 记录，却常常只知道客户端站点的 DNS 服务器。若解析采用递归，请求路由服务器看到的甚至只是代替该站点 DNS 继续查询的另一台服务器。

这不是定位精度少几个百分点的问题，而是优化对象已经被替换。系统测量到递归服务器的往返时间，不能据此声称测量了每个终端到替代服务器的路径。证据链必须先回答：决策到底看见了谁？

一个解析器承载很多客户端

单一 DNS 回复可以指向一台替代服务器或一组服务器的虚拟地址；多个 A 记录可以让站点解析器轮转选择。排序可以影响同一解析器背后的多个客户端，但它并不证明实际负载均衡。

在 TTL 有效期内，共享解析器的用户可能获得同一组地址。突发流量于是带着共同选择涌向一个节点。缩短 TTL 能更快响应故障或负载变化，却会增加 DNS 查询量；有些实现还不遵守 TTL。缓存有效不等于支撑该答案的测量仍然有效。

每次选择都应绑定解析器身份、递归链、候选集、测量时间、策略版本、缓存范围和到期时刻。“最近”还必须带一个 离谁最近 的字段。缺少这个字段，形容词就在替数据作证。

多级解析增加了多级责任

NS 与 CNAME 可以把一次解析交给多个专业决策服务器。NS 重定向受域名层级限制，最后一台 DNS 服务器可能影响整个过程的缓存期限，异常引用还可能触发超时。CNAME 可以转入全新域名，不受原名称层级限制，但会增加另一轮解析。

这种分工能让地域、内容或策略判断更细，却也增加延迟、缓存和权威边界。审计记录不能只保存最终 A 记录；它必须保存每一跳收到什么、依据什么、返回什么以及答案会保持多久。

Anycast 找到的是决策服务器

RFC 3568 描述多台请求路由 DNS 服务器宣告同一 anycast 地址。路由会把查询送到在 OSPF/BGP 意义上离站点解析器较近的实例。它解决的是“哪台决策服务器接收查询”。

它没有证明该实例离客户端最近，也没有检查其负载。路由协议通常不对服务器负载敏感；路由距离近也未必意味着时延最低。更不能把到决策服务器的路径，冒充后来内容交付节点的路径。

因此 anycast 收件记录与替代服务器选择记录必须分开。前者说明查询到了哪里，后者才说明候选如何被比较。

DNS 只看见名称

DNS 天然按域名决策，理想的内容路由却可能需要按对象决策。把对象类型、哈希或标识编码进 DNS 名称，可以提前暴露对象信息，但一张页面可能因此触发多次解析，增加总体时延。

传输层提供另一条路。检查首个数据包可以看到客户端 IP、端口与四层协议，再对 DNS 的粗选结果作细化。不过 RFC 3568 指出，客户端到新节点的前向流量通常仍会经过最初由 DNS 选中的替代服务器，而数据量更大的反向流量可能直接返回客户端。

同一会话于是有决策路径、前向路径与反向路径。任何时延指标都要标明方向；任何“已交接”都要有目标节点接受、实际响应路径与生效时间的后续凭证。

应用层用权力换取可见性

应用层能读取 URL、头部、Cookie、语言和 User-Agent，从而按对象或会话选择节点。它可以返回 302 类重定向，在路径中拦截并拼接连接，或改写页面里的嵌入 URL。

每一种精细化都带来成本。重定向多一次往返，并依赖客户端继续请求；路径内元素把解析与连接状态放进数据通路；URL 改写仍让第一次请求到达源站，而且会把一次选择固化进页面。若页面被长期缓存，旧 URL 会继续指向已不可用或已不合适的节点。

TLS 把权限边界暴露得最清楚：内容网络若不终止 TLS，就看不到完整 URL。要获得更精细的路由上下文，就必须承担证书、密钥、内容可见性与修改授权。更了解请求，不只是技术能力提高，也是权力范围扩大。

指标从不脱离观察点

规范列出时延、跳数、BGP 信息、节点负载和内容可用性等输入。在其讨论中，“邻近”指往返时间；DNS 模式下常测到本地解析器。有些测量只有单向，而互联网路径可能不对称。

主动探测只能周期进行，NAT 与防火墙可能阻断，入侵检测还可能报警。没有回复可能代表策略，而非远或故障。用 HTTP 探测节点负载也难以获得实时信息，旧反馈可能不准确。RFC 3568 甚至明确警告，BGP AS_PATH 作为优选指标可能没有意义。

每个指标都应保存来源、目标、方法、方向、时间、原始值与失败语义。策略还要保存版本、硬约束、权重和决胜规则。只有这些字段齐全，“最佳”才是可以重放的计算，而不是无法质询的标签。

从选择到交付的凭证图

先记录该层实际可见的请求者与请求，再记录解析器链、查询或对象、候选与排除原因。测量携带观察点和新鲜度，策略给出规则，选择记录给出节点、理由与到期时刻。

随后保存 DNS 答案、重定向、改写、拦截或传输交接；保存 TLS 终止者与修改权限；保存目标节点是否接受请求、服务时是否拥有对象、当时负载、响应实际经过的路径、客户端是否重试以及应用结果。

DNS 返回不等于客户端到达。发出重定向不等于客户端跟随。改写 URL 不等于对象交付。选中节点不等于节点接单。任何一层都不能替下一层签收。

证据边界

本文不指认任何 CDN、运营商、解析器、客户端、源站、替代服务器、厂商、会话、事故或实测性能。RFC 3568 是历史机制调查，不是部署证明。

RFC 3466 提供同期内容互联模型；RFC 3238 讨论中间件边界。RFC 2782、RFC 1546、RFC 1034、RFC 1035 与 RFC 2181 提供 DNS/anycast 背景；RFC 3272、RFC 2386 与 RFC 3221 提供路由背景。RFC 7336 与 RFC 8008 只是后来的 CDNI 演进背景，不能倒推早期实现。

Heng Lu 关于运行代码优先与最小初始规范的文章，是明确披露的编辑视角：共同协议应保持小，而实际测量、交接和交付必须由运行系统举证。它们不证明 RFC 作者意图或任何部署结果。

结论是有限的：请求路由器只能在自身观察范围内作优选。只有把“为谁、为哪个对象、在何时、从哪些候选、依据哪些方向的测量、最终是否交付”写进同一凭证图，“最佳”才有可治理的含义。

Sources