RFC 814 如何分开名称、地址与路由

摘要

RFC 814 对端口的讨论看似是实现细节，实则说明了互联网核心为何可以保持薄。IP 把数据报送到一台主机，并交给上层协议；TCP 或 UDP 再用端口找到进程或连接。若把端口语义塞进 IP，就会暗示每台网关也要理解应用服务。

David D. Clark 拒绝了这种扩张。当时 TCP 和 UDP 的端口字段位置相同，程序员可以利用这一事实优化实现，但协议架构不能据此宣布所有未来传输都必须采用同一种分派方法。不同协议可能需要不同长度的标识符，知名端口也只在相应传输协议内有意义。

因此，端口不是地址的尾巴。地址完成跨网交付，端口完成主机内部交付。今天 IANA 的服务名称和端口登记仍保留这条边界，并明确提醒：分配端口不代表认可应用，出现在该端口上的流量也未必属于登记的服务。

RFC 814 的起点是人能读懂的字符串。网络、主机和服务都有名称；主机名称再被转换成 32 位互联网地址。问题在于，映射会变。

文件举出的风险很具体：主机搬走后，本地 NIC 主机表仍指向旧地址。交互用户或许会立即发现回答者不对；无人值守的排队邮件却可能继续投向占据旧地址的另一台机器。每一层都可能“成功”，整体仍然错了。

这说明地址不是名称的同义词。地址描述当时的网络接入位置。名称保留的是查询对象。若把两者锁在一起，每次迁移都要重建人和应用持有的引用。

Clark 还给出了一条面向代码的迁移原则：不要让程序到处直接读取主机表，而应把访问封装在子程序后面。分布式名称服务器成熟后，只需替换子程序的实现，应用仍然提出同一个名称问题。小接口使旧系统可被替换，而不是成为永久入口。

1982 年的互联网只有约 25 个活跃网络和数百台主机，但 RFC 814 已要求按更大规模设计。每台机器保留所有名称并不合理：表会太大、变更太频繁，而且绝大多数条目永远用不上。

未来方案是分布式维护和最近使用缓存。网络或网络组维护自己的名称，名称服务器提供转换，主机只保留当前有价值的结果。状态规模由实际工作决定，而不是由整个互联网决定。

缓存也会放大陈旧问题。文件讨论过向远端地址询问其关联名称的验证思路，但这不等于密码学身份认证。它真正揭示的是：一条映射必须附带来源、观察时间和失效条件。

RFC 1034 后来用带类型的资源记录、区域责任和 TTL 把这种思想工程化。DNS 的主要目标是建立一致名称空间，并明确说名称不应被要求包含网络标识、地址或路由。地址成为名称下面可变化的数据，而不是名称语法不可拆除的一部分。

得到地址后，IP 必须判断目的网络是否直接相连。若不相连，就要选择网关。早期实现曾为 256 个可能网络建立静态网关表；网关移动、故障或地址格式扩展后，这种全量假设便失效。

RFC 814 建议为正在使用的目的地址保存路由缓存。没有条目时，主机可以尝试一个可达网关；若不是最佳下一跳，网关可以返回 ICMP Redirect，主机据此更新选择。路由因此是一项可修正的局部运行状态，不是名称的固有属性。

第一台网关如何发现，文件有意留给本地网络。某些网络能广播寻找，某些提供专门设施，另一些需要安装者手工配置。共同互联网层没有把一种局部能力升级为全球强制机制。

RFC 1122 后来继续把复杂路由放在网关，并希望主机软件不必随路由体系每次演化而重写。路径 MTU、往返时延等也可随路由缓存记录。它们属于某次路径观察，不属于名称身份。

RFC 814 还比较过另一种服务发现方式：连接前先把字符串服务描述交给会合服务器，由它为该次服务选择端口。这适合有建立阶段的虚电路，却会给一次性 UDP 数据报增加一次往返、一个中介和更长字段。

文件没有宣布会合模式错误，而是拒绝让所有上层协议都服从它。最小数据报交换可以保留低开销，需要会合的协议也可自行采用。未来决定被留在更接近需求的一层。

这与《heng-lu-note》的薄协调原则相呼应，但不是 RFC 814 的原句：共享层应只规定互操作所必需的事项，不应凭借一个方便的入口取得对所有后续选择的权力。

虚电路网络可以在建立阶段发送很长地址，随后只携带短连接标识。互联网数据报没有预先建链，必须让每个包单独可路由，所以地址要出现在每个包里。RFC 814 把 32 位描述为覆盖能力与报头成本之间的折中，也承认要把所有地点塞进去非常吃力。

这不是对 CIDR、NAT、IPv6 或今天 IPv4 经济的预测。它只是给地址划定功能：地址是受报头约束的交付坐标。若名称直接继承这个坐标，身份就会被交付字段的稀缺、结构与迁移锁住。

运行记录应分别保留：查询的名称、回答来源和 TTL；返回的每个地址；所选接口、下一跳与路由版本；传输协议和端口；应用的认证、授权与完成结果。

这样才能准确判断故障。名称可解析但无路由；有路由但端口关闭；端口响应却由错误进程占用；进程认证成功但业务操作失败。把这些事件压成一个绿色“端点正常”，就失去了故障位置和责任边界。

RFC 814 的历史贡献不是发明一句口号，而是让实现者看见多次转换。名称不是地址，地址不是路由，路由不是进程，端口也不是服务真实性。互联网能够迁移和扩展，恰恰因为每一层只对自己能观察到的事实负责。