摘要

  • RFC 3528 明确允许接受更新的网格增强目录代理先向服务代理返回 SrvAck，再异步把注册转发给其他目录代理。因此，这张回执能够证明本地接受，却不能证明所有副本已经收到状态。
  • 可辩护的证据链必须分别记录写入者权限、本地决定、逐个对等节点的转发、反熵范围、查询可见性、剩余生命周期、删除墓碑、端点可达性与应用结果，不能让第一个绿色状态替后续环节发言。

分布式系统最容易误读的时刻，不一定是失败，而是局部成功。一个节点给出了格式正确、语义真实的成功响应，监控系统便把整个拓扑涂成绿色。

2003 年 4 月发布的 RFC 3528 是一项 Experimental 协议。它在 SLPv2 之上增加按 scope 组成的目录代理全网格、直接转发与反熵机制。文档没有承诺一次写入会像单机赋值那样瞬间出现在所有观察点；相反，它把传播过程拆成可以辨认的状态。

回执只覆盖接受节点的决定

Service Agent 把服务注册交给 Directory Agent。真正接受这次更新的节点称为 accept DA。若它支持 mSLP，就会把新状态继续传给同一 scope 中的对等目录代理。

关键不在“会传”，而在“何时传”。直接转发是异步的。accept MDA 可以在向另一个 MDA 发送 Srv(De)Reg 之前，先向 MSA 返回 SrvAck。

所以回执所证明的是：特定目录代理收到了特定负载，按当时的本地策略完成处理，并向发送者作出响应。它没有观察其他节点的队列，也没有观察随后从其他节点发起的查询。

这种设计有合理的可用性动机。如果写入者必须等待每一个对等节点，任一慢节点都会把故障扩散到全部写入。协议把本地事务和复制事务分开，证据系统也应保留这条边界。

本地回执需要绑定接受代理身份、MSA 身份与认证结果、scope 集合、注册内容摘要、版本时间戳、接受 ID、策略版本与决定。若数据库只留下“注册成功”，后来就无法判断这个成功到底发生在哪一层。

可靠有序连接不等于同步完成

共享 scope 的对等 DA 之间维持持久、可靠、有序的连接，一条连接可以承载全部共同 scope 的注册流量。它提供的是运输顺序，不是分布式提交。

连接在线，不能证明某条尚未发送的消息已经到达；消息已经写入连接，也不能自动证明对端完成索引并可供查询。连接中断后，还可能需要反熵来补齐状态。

初始同步完成后，接受代理把新更新直接发送给相关对等节点，直到发生故障。转发只有一跳：更新从 accept DA 到它在对应 scope 中的 peers，而不是由每个接收者无休止扩散。

来自 peer 的每条 Srv(De)Reg 不需要再逐条返回应用层 SrvAck，因为可靠连接已经承担运输确认。反过来，这并不意味着发给 MSA 的那个 SrvAck 同时是所有 peers 的隐含收据。

逐副本证明需要列出预期 peer、经认证的连接身份、共同 scope、发送位置、运输结果和之后看到的摘要向量前沿。笼统的“mesh connected”无法回答某条注册是否已经跨过连接。

接受时间不是全网格时钟

RFC 3528 用 accept ID 标识更新。它由 accept DA 的 URL 和接受时间戳组成；同一个接受节点必须让时间戳单调递增，来自该节点的更新也按此顺序传播。

但不同 accept DA 的流之间没有统一总序。两个节点接受的更新可以以任何相对顺序抵达第三个节点。把不同来源的数字直接比较，会虚构一个协议并未提供的全局时钟。

注册本身还有由 MSA 设置的版本时间戳，用来判断同一注册哪个版本更新。到达时间不能替代它，因为较老的更新完全可能因网络延迟而在较新版本之后到达。

因此至少要保留三种时间：版本时间回答“哪份内容更新”；accept ID 回答“由哪个入口、按该入口的第几个顺序接受”；查询时刻回答“某个读者何时看见什么”。把它们压成一个 updated_at，事后只能看到最后写入数据库的那次覆盖。

该 RFC 假设每条注册由一个 SA 更新，并不定义多写者冲突解决。若产品允许多个主体修改同一逻辑对象，就必须另行规定授权与合并规则，不能把缺失的共识能力归给 mSLP。

摘要向量是收件前沿，不是健康证明

反熵需要知道双方各自缺什么。摘要向量为每一个已知 accept DA 保存最近收到的接受时间戳。它把多条来源有序流压缩成多个收件前沿。

请求方可以索取各前沿之后的状态。完整反熵还会要求请求中没有列出的 accept DA 状态；选择性反熵只处理明确列出的 accept IDs。两者的“完成”范围不同。

这一区别必须进入审计记录。一次选择性交换可以没有任何错误，却完全没有检查某个被省略的来源。只展示“anti-entropy succeeded”会隐藏最关键的覆盖范围。

提供方按接受 ID 顺序发送请求的状态，处理完后再用 SrvAck 结束反熵请求。这张回执与最初给写入者的回执名称相同，但因果对象完全不同：一张确认本地注册请求，另一张确认特定同步请求的处理。

即使摘要向量完全对齐，也不能证明服务健康。它不保证注册仍未过期、scope 正确、描述真实、端点可达，或者每条查询都能返回该记录。它证明的是目录状态传播到哪里。

删除先成为墓碑，再成为空白

恢复期间转发的注册带着剩余生命周期，而不是重新获得完整期限。否则每次反熵都会给陈旧记录续命。

注销也不能立即从所有存储中消失。系统要保留 deleted registration 状态，作为墓碑阻止迟到的旧注册把已删除服务复活。等原注册到期后，墓碑才可清除。

“接受注销”“peer 收到墓碑”“物理清除状态”是三个事件。“查询不再返回”又是某个观察点的第四个事件。任何一步都不天然证明所有观察者同时完成其余步骤。

删除证据应包括注册标识、版本、accept ID、删除标志、剩余时间、同步路径和查询观察。没有节点与时间的“已删除”只是愿望。

Scope 决定哪些副本属于这个承诺

所有服务同一 scope 的 MDAs 形成全网格。两个节点的一条持久连接可以承载多个共同 scope。MSA 不必向所有 MDA 分别注册，只需选择一组节点，使其 scope 并集覆盖自己的 scope，然后依赖传播。

因此，在哪个 scope 接受是证据的一部分。对 scope A 的成功不能外推给 scope B，scope 外的目录代理也不属于这张收据。User Agent 选择不同目录或不同 scope 时，看到不同结果并不与本地回执矛盾。

RFC 把全网格视为简单可靠的方案，但说明一般规模是几十个 MDA 或更少，并非面向任意大的成员数。这是文档中的设计边界，不是对现网规模的测量。

把一个父 scope 拆成两个子 scope 会改变注册义务。过去只在父 scope 下登记的服务，为维持相同可发现性，可能必须在两个子 scope 中都出现。scope 治理不是标签整理，而是查询与传播路径的变更。

错误的授权决定也会被网格放大

mSLP 沿用 SLPv2 的认证。文档要求 MDA 在 peering 前应认证其他 MDA，在接受并转发更新前应认证 MSA；MSA 也应认证它使用的 MDA。

可靠 TCP 连接只能说明特定运输通道有序，不能证明对端是获准加入网格的成员。签名通过不能单独证明该密钥仍有权为这个 scope 发布。格式正确更不能证明服务陈述真实。

一个 MDA 被攻陷可能影响全网格，因为它接受的状态会被传播。提高可用性的扇出，同样会放大入口授权错误。

SLPv2 还指出，在缺少预配置安全信息的启动阶段，发现过程可能需要一定程度的“盲目信任”。因此，密钥分发、信任锚和验证策略仍然是部署责任。

IANA 目前把 SLPv2 扩展号 0x0006 分配给 Mesh-enhancement，并引用 RFC 3528。注册表只稳定编号含义，不证明实现、启用、认证、收敛或服务结果。

可查询之后仍要证明可使用

写入者与读者走的不是同一条路径。Service Agent 向某个 DA 写入，User Agent 随后按自身的发现和 scope 规则选择 DA 查询。

要证明可见性，就要从相关读取点发出查询，并记录应答 DA 身份、请求 scope、过滤条件、响应摘要、注册版本、剩余寿命与观察时间。若承诺是整个 mesh 可见，还要明确覆盖了哪些成员。

查询返回的只是目录声明。它不建立到服务的连接，不验证应用协议，不授予用户权限，也不完成用户想做的事。

证据链还要经过目标解析、网络可达、协议握手、服务专用健康检查和最终应用结果。目录告诉读者去哪里找，不能替目标服务回答。

为每个边界保存自己的收据

首先保存协议与权力：RFC 身份和状态、scope 定义、MSA 身份、凭据、信任策略与授权结果。将它们绑定到负载摘要、版本时间戳、accept DA 和 accept ID。

给写入者的 SrvAck 保持为不可变的本地收据。之后为每个 peer 单独记录连接、共同 scope、发送结果和摘要前沿。不要把后续事实反写进早期回执，而应使用不可变标识把它们关联起来。

反熵记录请求是完整还是选择性、输入向量、覆盖来源、传输状态和最终回执。生命周期与墓碑不可被一个布尔“active”字段吞掉。

最后再加入查询与服务结果。目录团队只对状态传播作证，安全团队对主体权限作证，服务负责人对健康作证，应用负责人对用户承诺作证。链条可以汇总，却不应让最早的一环垄断所有含义。

证据边界

本文不指认任何实现、厂商、运营者、网格、Directory Agent、Service Agent、User Agent、服务、端点、注册、部署、事故、中断、攻击或客户结果，也不测量当前采用率、拓扑规模、传播延迟、查询成功率或健康状态。

RFC 3528 被准确描述为 2003 年 4 月发布的 Experimental 协议，不是 Internet Standard。文档给出的 200 秒 keepalive 与 300 秒 timeout 默认值不是任何现网配置或故障发现时长的证据。

后续元数据、注册表与相关 RFC 各有自己的范围，只能证明文档身份、编号分配与协议背景，不能证明运行代码遵守了规则。

Heng Lu 关于权威与 running code 的笔记在此作为公开的编辑视角，用来追问协调记录能够证明什么；它们不证明 IETF 作者意图，也不证明任何部署事实。

结论保持有限：本地接受、网格传播、查询可见、端点可达和应用成功可以处于不同状态，每一项都需要自己的观察。

来源