摘要

  • RFC 795 把早期 IP 服务类型字段里的优先级、时延、吞吐、可靠性要求，分别映射到 AUTODIN II、ARPANET、PRNET 和 SATNET 的本地选项。
  • 映射表写明了需求落地时的缺口：PRNET 没有优先级标记，ARPANET 只用一位表示优先级，多种请求会落入同一服务，111 在两份表里直接报错。

一只 IP 报文在表单上勾了「快」「稳」「先办」。到下一个网络，柜台却回答：我们没有这么多按钮。Jon Postel 1981 年 9 月的 RFC 795 只有四页，读起来像四家运输公司的点单手册。它讲的不是抽象的服务质量理想，而是同一套 IP 请求在四种网络里究竟能换成什么具体动作。

当时 IP 的服务类型占一个字节：前三位是优先级，接下来三位分别表达低时延、高吞吐和高可靠性的偏好，最后两位预留。优先级从常规、优先、立即、闪电等一路列到网络控制。发送者有一套简明的共同语言。Postel 随即提醒，列出的网络各有非常具体、彼此不同的服务选择；精彩处从这里开始。

AUTODIN II 先把流量接纳类别与应用类型分开。接纳类别较容易与 IP 优先级对应。应用类型则有四种组合：I/A 偏向低时延，Q/R 是普通设置，B1 偏向高吞吐，B2 同时偏向吞吐与可靠性。把 IP 后三位的请求倒查到本地服务，多种比特模式会汇到 Q/R 或 I/A；三位全为 111 则是错误。客人可以把所有格子都打勾，柜台无须凭空做出第五道菜。

ARPANET 更节俭。它只有一位优先级，可与 IP 优先级的最高位相映。其他选择是普通的 Type 0 或非受控的 Type 3 消息，以及单分组或多分组。Type 3 的多分组形式不允许。多个时延、吞吐、可靠性组合最终都会走 Type 0 多分组；100 和 110 走 Type 3 单分组，101 走 Type 0 单分组，111 则再次报错。IP 表单上多出的区分，在这张菜单里变成了同一张票。

PRNET 连优先级这一栏都没有本地标记。它能选经由站点或点到点路由，还能选是否需要确认。映射表让时延位影响路由类型，让可靠性位影响确认；改变吞吐位，表里的路由和确认组合并不跟着改变。报文可以带着很高的优先级抵达，PRNET 却没有对应的优先级开关供它拨动。

SATNET 则在另一端：它同样没有优先级标记，其他旋钮却很多。块式或流式，四档时延，两种保留时间策略，三档可靠性，相乘得出 48 种本地组合。一个简短的 IP 三位请求不能逐一命名这些设置。要把要求变成一个实际选择，就必须知道边界处采用哪条转换规则。

这份小表格把「统一」的限度写得异常清楚。统一的是请求所用的语言；具体网络保留自己的路由、确认、消息类型与保留策略。Postel 没让标题里的「服务」二字替硬件许愿，而是把折损、报错和空白按钮都印在表上。互联网的共同语言从这里长出来，也从这里学会看菜单。