摘要

  • RFC 916 的 SO 标志表示负载恰好只有一个八位组；此时 LENGTH 无须再写“1”，而是直接装入数据，头部校验和同时保护这个字符。
  • 同一个物理位置在 SYN 中表示接收方最大数据长度，在普通分组中表示后续数据计数，在 SO 分组中又成为数据本身；解释权来自已校验的控制位与可接受的连接状态。
  • 发送序号与确认序号各用一个比特，前提是每个方向最多只有一个等待响应的分组；节省的字段与受限的吞吐量来自同一项设计选择。

1984 年 10 月发布的 RFC 916 提出 Reliable Asynchronous Transfer Protocol，简称 RATP。它预期运行在全双工点到点链路上，通常是连接小型计算机、调制解调器或可接收命令设备的异步 RS-232 线路。RFC Editor 当前记录 将其列为 Historic。这说明文档今天的档案状态，不等于对当年采用规模作出结论。

规范把优先级写得很清楚：先保证可靠，再偏向容易实现。它主动舍弃动态窗口，不允许多个待确认分组同时存在；远端关闭时，尚未发出的排队数据会被丢弃，文档认为这样可以少两个状态。RATP 并非把完整 TCP 缩小后塞进串口，而是通过明确收窄问题，换取更小的状态机。

一个字符原本需要七个八位组

RATP 的通常头部有四个八位组：十六进制 01 同步引导、控制字段、数据长度字段与头部校验和。普通负载跟在头部之后，尾部还要带两个八位组的数据校验和。

交互式输入暴露了比例问题。为了让按键及时到达，发送方不能总等到多个字符凑成批次；但按普通格式立刻发送一个字符，需要四个头部八位组、一个数据八位组和两个数据校验八位组，总计七个。

SO（Single Octet）专门处理这一种情况。当 SO 置位，而 SYN、RST、FIN 均未置位时，接收方已经知道负载长度必定是一个八位组。长度字段若再写“1”，只是重复。RFC 916 因而让 LENGTH 位置直接承载字符，不再发送独立数据段，也不再发送独立的 16 位数据校验和；头部校验和覆盖嵌入的字符。文档把从七个降到四个称为传输效率提高 40%。

这里没有对任意数据做数学压缩。少掉的三个八位组，各自功能已经被别处严格替代：SO 提供长度，固定位置提供数据，头部校验和提供有限的错误检测。两个字符不能套用这条捷径，SO 也不会取消确认或连接状态。

一个位置有三份契约

头部第三个位置不能脱离控制位单独理解。在带 SYN 的分组中，它是 Maximum Data Length（MDL）：发送该 SYN 的一方告诉对端，自己愿意在单个入站分组中接收多少数据。三次握手期间，两端分别声明自己的上限。

连接建立后，若 SYN、RST、FIN 都没有出现，这个位置才叫 LENGTH。SO 为零时，它计算后面跟随的数据八位组数量，范围从零到对端声明的 MDL。SO 为一时，它不再是计数，而是唯一的数据八位组。

所以数值 65 本身无法说明意义。它可能是接收上限 65，可能是后续有 65 个八位组，也可能是一个字符值。接收方必须先发现同步引导，验证控制、该位置及头校验和，再判断这些标志在当前连接状态中是否合法，最后才能作出解释。

这也决定了 MDL 不是建议。如果一个通过头部校验的普通分组声称长度大于本端 MDL，RFC 916 将其视为协议违例，或极小概率下未被发现的长度损坏；接收方要用复位中止连接。MDL 是接收方自己声明、由共同规则执行的准入边界。

一端可以用 MDL 零表示不愿接收任何数据，使单向传输成为可能；如果要真正交换数据，两端不能同时为零。公共层只规定上限如何传递、越界如何处理。设备拥有者仍然决定本机能承担多少。

一位序号成立，因为没有第二个未决分组

RATP 的发送序号 SN 与确认序号 AN 各只有一位。两种取值并不适合所有可靠传输，它们依赖更强的前提：每个方向同一时刻至多只有一个需要响应的分组处于发送或确认过程中。

接收方按模二期待下一个 SN。如果收到另一个值，就能把它识别为已经确认过的分组副本——通常意味着先前确认丢失，发送方进行了重传。接收方丢弃重复数据并再次给出相应确认。发送方从 AN 推断唯一待确认分组已经收到，于是从重传队列移除它，再翻转序号位。

两个方向仍可独立推进。只要本方向最后一个需响应分组已获确认，就可以发送新数据；若恰好还要确认反向数据，可把两项功能合在一个分组中。纯确认不要求再确认，否则协议会陷入无穷回执。

代价也在同一条规则里。没有窗口意味着链路在一次往返期间无法连续承载多个待确认分组。对慢速、交互式、内存有限的设备，这减少缓冲区、状态与重复判断；对带宽时延积较大的路径，它会限制吞吐。不能只拿走一位序号的节省，却丢掉“未决分组只有一个”的不变量。

接收方把可承受的分组写进握手

MDL 最大为 255，因此普通 RATP 分组的绝对上限为 261 个八位组：同步、其余头部、两个数据校验八位组和 255 个数据八位组。规范据此得出实现结论：接收单个分组无需分配更大的存储空间。

真正采用的上限仍由本地条件决定。操作系统、驱动程序、内存、波特率以及线路上可能插入的流控字符，都可能使较小值更合适。RFC 916 特别指出，如果长数据流容易触发外部流控，就应降低最大数据量，让部分分组能够不受干扰地到达。

这体现的是“最小但严格”的共同层。协议提供一种确定的上限表示和越界后果；它不替设备选择内存，不替操作者选择应用，也不让中央机构分配容量。每个参与者本地决定，对端按共同规则验证。

分组结束不一定是上层记录结束

RATP 用 01 标记分组起点，却没有相应的结尾定界符，因为任意比特模式都可能出现在数据里。一旦头部通过校验，解释后的长度便决定还要读多少八位组。

上层对象可能大于 MDL，需要分片。EOR 标志表示这个 RATP 分组包含上层记录的末尾；是否设置它由上层负责。一个分组可以在链路层完整并获得确认，却仍只是未完成记录的一片。

证据必须按层停止。头校验通过，证明候选头部满足该算法；确认到达，证明对端 RATP 状态接受了相应分组；EOR 帮助确定上层边界。它们都不能证明应用已经理解记录，不能证明命令有权限，也不能证明预期动作发生。

噪声恢复是另一项机制

RS-232 只给单个字符提供成帧，不给完整 RATP 分组划界。接收方持续搜索 01，随后读取三个头部八位组并检验。如果校验失败，这三个八位组会重新作为输入参与同步搜索，避免因一个伪起点跳过不可知长度的流。

后来记录 SLIP 的 RFC 1055 选择了不同边界：用定界符与转义承载 IP 数据报，却没有类型字段、基础规范统一的最大分组，也没有串行链路层纠错。RFC 1661 与 RFC 1662 随后定义 PPP 的协议复用、LCP 协商、可变限制、标志成帧、透明传输与 FCS。这些只构成机制对照，不证明演化血统。

RFC 793 是 RFC 916 在讨论动态窗口时引用的同期 TCP 对照。TCP 面向互联网络中的可靠字节流，序号与窗口契约更广；RATP 在一条点到点线路内同时承担分组与可靠连接功能。相似术语不意味着相同证明边界。

这些一手资料不能给出 RATP 部署数量，也不支持现代产品或事故结论。校验和不是签名，不负责加密、身份或授权。历史上真正值得保留的，是四个八位组成立的条件：两端必须共享精确状态，明确谁声明容量，并知道线路上最多还有什么尚未解决。