摘要

  • RFC 1498 先列出服务或用户、节点、网络接入点、路径四种可命名对象，再用三次连续绑定解释如何到达服务。
  • 服务可以换节点、节点可以换接入点、路径可以换而不改变相邻层对象的身份；可变的是关系，不必是名字。
  • 一条地址或解析结果只记录某时刻的一段关系。认证、授权、可达、交付和应用结果都需要额外回执。

名字之前先有对象

网络讨论很容易从三个熟悉词开始：名字说明想要什么，地址说明它在哪里，路由说明怎样过去。RFC 1498 没有否定这套说法，却指出三个标签不足以容纳实际对象。

Jerome Saltzer 的做法更像建立数据模型。他先列出四类东西。服务与用户是被使用的功能以及使用它们的客户；节点是运行服务或用户程序的计算机；网络接入点是节点连接网络的端口或位置；路径则跨过链路和转发节点，把两个接入点连起来。

这篇论文最初发表于 1982 年，1993 年 8 月以 Informational RFC 重刊，并不是互联网标准。它留下的不是一套强制词典，而是一种防错顺序：先确定值命名了什么，再问绑定记录在哪里。

字符形态不能替对象作答

RFC 1498 特别警惕两种视觉直觉。人们常把可打印字符串叫作“名字”，把机器可处理的二进制串叫作“地址”；又常假设服务天然使用字符串、节点天然使用唯一编号、接入点天然使用分层地址。

这些只是习惯。四类对象都可以使用任何有用的命名形式；同一个节点还可以同时有分层字符名与唯一二进制标识。RADC-Multics 看上去像主机或服务名，仍可能实际命名 ARPANET 的某个接入端口。一个 48 位 Ethernet 值看上去像接口地址，也可能被其他系统当作节点名。

因此，屏幕上的字符不能独立证明对象类型。可信记录至少要包含命名空间、对象类别、分配主体和绑定上下文。

三段关系允许三种移动

对象分开以后，变化也能分别描述。服务可以在一个或多个节点运行，并在节点之间迁移而保持服务身份。节点可以连接一个或多个接入点，并在接入点之间移动而保持节点身份。两个接入点之间可以有多条路径，路径改变也不必改变端点身份。

向服务发送数据，概念上要连续完成三件事：找出运行该服务的节点，找出到达该节点的接入点，再找出从请求方接入点通往目标接入点的路径。RFC 1498 分别称其为服务名解析、节点名定位与路由服务。

每一步都可能返回多个选择。服务可能有副本，节点可能多宿主，路由可能有多条。不同层的选择还会互相影响：路径状况可能反过来决定使用哪个服务节点。网络表可以只交付部分绑定或一个列表，把最终选择留到最后，并记录在三种网络绑定服务之外。

所以“一次查询返回了这个地址”只是窄事实。它不证明没有其他候选，也不证明选择策略、路径继续有效或服务最终响应。

DIALOG 表移动的是关系

RFC 1498 用一行表格揭示了最容易混淆的地方：Lockheed DIALOG Service 当前运行在节点 5。这个句子含有三种关联。

“Lockheed DIALOG Service”长期关联着特定服务、管理与存储资料；“5”长期关联着特定节点；表中真正准备随时修改的，只是 DIALOG 此刻在哪个节点运行。把 5 改成 6，会移动服务，却不会给服务或节点改名。

真正改名要困难得多，因为名字与对象的关联还存在于程序、文档、手写笔记和宣传资料里。可编辑表格是一个可变关系的操作面，不是整个现实的命名权。

这也划出治理边界：维护绑定表的人可以影响请求被送往哪里，但这个能力不会自动变成对服务身份、所有权或外部行为的裁决权。

省掉一张表，也会失去一种选择

Ethernet 的 48 位值展示了永久绑定的收益与代价。节点自己携带该值，接口又用它接收帧，于是它可以同时被理解为节点名与接入点名。把两层名称固定成同一个值，节点移动物理位置时不必改网络记录，还能省掉一层绑定表并简化替代路径。

困难出现在同一节点需要在同一 Ethernet 上拥有两个可单独寻址的接入点时。使用两个值，别的记录可能误以为有两个节点；使用同一个值，又无法精确指定其中一个接入点。固定绑定没有消灭两种对象，只是用较少状态换取较少表达能力。

ARPANET NCP 的助记名则从另一方向暴露问题。字符串实际落在接入点层，用户却把它当作服务名。邮件服务可以由另一台机器继续提供，但用户必须输入看似不同的“服务名”，因为原名称没有在服务层表达冗余。

一个服务器可以压缩实现，不能压缩证据

一个名称服务器可以接收服务名并直接返回接入点列表，机械上同时完成前两段绑定。分布式路由再悄无声息地完成第三段。这种合并有效率，却不改变故障诊断的问题：服务是否仍在该节点？节点是否仍接在该点？路径是否仍存在？

后来的 RFC 1958 要求应用尽量使用名字而不是硬编码地址，并强调模块化。RFC 2101 把 IPv4 的标识符与定位符要求拆开，称同一地址字段兼任两职是历史上的偶然事实。RFC 2956 又记录节点身份与投递位置混合带来的困难。这些是后续印证，不是替 RFC 1498 增补条款。

Saltzer 的宽泛解释甚至把“地址”理解为下一层对象的名字：服务的地址可以是节点名，节点的地址可以是接入点名，接入点的地址可以是路径名。到达服务的路由还要加上节点内部的活动或 socket 标识。即便如此，它也不是交付回执。

RFC 1498 明说没有讨论安全问题。地址不认证服务，路径不授权行为，socket 标识不证明应用接受，更不证明现实结果。

Heng Lu 关于运行代码优先、未来决策本地化与现实层和符号层的论述给出同一纪律：协调记录可以帮助系统互操作，却不能因为方便或长期使用就冒充对象本身、运行事实或持续权威。

完整证据链应保留名字与命名空间、查询时间、全部节点和接入点候选、拓扑与策略快照、所选路径、socket、会话以及应用响应。RFC 1498 的历史价值正在于此：不要让一个压缩后的答案，继承它所省略的全部含义。

来源