摘要

  • RFC 877 只统一了 IP 与 X.25 交界处的必要规则：协议标识字节、完整的数据报分组序列，以及可由站点协商的参数。
  • 虚电路按需开启，空闲关闭时间取决于维持电路的成本；RFC 明确不为每条 TCP 连接单独开一条 X.25 电路。

分析

电路也有自己的经济时钟

1983 年 9 月，J. T. Korb 发布 RFC 877，说明如何通过基于 X.25 的公共数据网络传送 IP 数据报。文档开篇称 CSNET、VAN Gateway 等组织已采用这项标准。它给出了具名采用者，却没有列出所有部署网络。

这里需要衔接的是两种不同的运行方式：IP 发送数据报，X.25 公共网络提供虚电路。RFC 877 没有试图让承载网的电路模拟应用层会话，而是在两者之间规定一套小而明确的接口，同时把若干运行选择留给接入站点。

一个字节标识协议，一组分组承载数据报

X.25 呼叫请求的 Call User Data 字段首字节用于区分网络层协议；0xCC 表示 IP。之后，每个 IP 数据报作为完整的 X.25 分组序列发送：数据报从分组边界开始，如果需要多个分组，More 位表示后面仍有数据。RFC 没有要求在数据分组里再加额外头部。

大小限制也被写清楚了，但允许协商。除非双方协商了更大的 X.25 分组尺寸，IP 数据报最大为 576 octets。RFC 以 1,024 octets 举例说明更大的已协商尺寸。窗口和分组尺寸等 X.25 功能可以由站点协商，不必被统一成一套全球固定值。

TCP 会话不等于电路寿命

虚电路有自己的计时方式。RFC 877 规定，数据报到达接口准备发送时可按需开启电路；空闲一段时间后可以关闭，而这段时间的长短取决于开放电路的成本。如果接口没有可用电路，也可以关闭某条电路；通信两端都可以发起关闭。

RFC 对 TCP 的界线写得很直接：IP 之上的协议不影响这项标准，尤其不会为每条 TCP 连接开一条对应的 X.25 虚电路。因此，持续很久的 TCP 连接并不意味着公共数据网络会一直为它保留一条专用电路。适配器管理的是网络资源，TCP 连接状态则在另一层。

可证实的后果有明确边界：如果数据报传输期间电路被关闭或重置，该数据报就会丢失。RFC 没有给出这种情况的发生频率，也没有描述应用最终看到什么。更高层如何处理，不是这份文档能证明的。

“推荐”并不等于人人部署

1984 年的 ARPA-Internet 官方协议状态报告 RFC 924，把“Internet Protocol on X.25 Networks”列为 Recommended，并引用 RFC 877。在该报告中，Recommended 表示鼓励主机实现，并非所有主机都已实现。1992 年，RFC 1356 回顾说 RFC 877 所述方法已被广泛使用，并以新规范取代它，原因包括消除歧义、处理数据报与分组大小、虚电路管理及多协议互联需求。

这几份记录把具名采用、官方建议和后续修订连成一条线，却没有提供站点清单、资费表或具体的空闲超时值。证据能说明规范被采用和后来扩展，不能计算它的全部覆盖率。

用后来的 Note 64 作一层解读

Heng Lu 的 Note 64 提出一种设计原则：共同规范只定义互通所必需的最低规则，后续选择留给实际运行系统的参与方。作为编辑视角，它能帮助解释 RFC 877 的结构：0xCC 和数据报分组边界属于共同规则，空闲关闭时长和可协商参数则没有被定为一个全球值。

这只是后来的解读。RFC 877 没有引用 Note 64，Note 64 也不能证明 Korb 在 1983 年的意图。RFC 本身已经说明了这条历史边界：IP 可以在公共 X.25 服务上被识别和传送，而不必让所有网络采用相同的电路成本和生命周期。

来源