摘要

  • RFC 935 回应 RFC 914 与 RFC 916 为低速异步串行线路提出的新办法。Robinson 比较字符定界、比特定界与按长度计数的老方案，最后主张采用字符定界、16 位 CRC 和 LAPB 控制规程。
  • 例子先取 13 字节 Thinwire 帧，再加链路开销：标准组合加八个，线上共 21 个；RATP 加六个，共 19 个。若线路每秒送约 120 个字符，120×13/21 与 120×13/19 就是每秒约 74 与 82 个 Thinwire 字符。他认为，这点差额买不回失步恢复、多帧并行、现成硬件和互通能力。

节省两个字符，谁来付后面的账

一张开销表很容易选出胜者：把每帧要额外发送的字符数排好，最小的那列涂上颜色就行。RFC 935 偏偏把表后面的故障也算进来。Robinson 面对的是个人电脑经低速异步电话线路连向网关的难题。RFC 914 谈 Thinwire，RFC 916 提出 RATP；两者都有充分理由盯紧线上每个字符。但线缆上的省略，往往意味着接收机、程序员和设备供应商多干活。

Robinson 没有否认差额。13 字节是加入链路开销前的 Thinwire II 帧。标准组合另加八个字符，8/13 约为 61%，线上合计 21 个；RATP 另加六个，6/13 约为 46%，合计 19 个。线路若每秒送约 120 个字符，120×13/21 得到约 74 个 Thinwire 字符，120×13/19 得到约 82 个。这个打字场景里，每 13 个 Thinwire 字符仅一个是用户输入，所以 Robinson 再估出每秒约 5.6 与 6.3 个用户字符。真正刺眼的是收益的尺度：为每秒不到一个用户字符的差别，是否值得另造一种链路语言？

三个老方案处理边界的方式本就不同。字符定界用特殊字符标出帧的开头和结尾，数据碰上同样字符时还要转义。比特定界靠标志位与填充位，通常用于同步线路。DDCMP 在头部写长度，不用逐个转义内容；可长度一旦在噪声中损坏，接收端便需要校验头部，并重新找到下一个头。按正常帧统计的“零转义成本”，不会替故障后的失步付账。Robinson 因而拒绝把依赖数据内容的转义字符数当作固定优势。

校验的对象不只是数据

RFC 914 和 RFC 916 提议的简单加法或异或校验，便于普通处理器计算。Robinson 要求链路层使用 16 位 CRC。理由不止是传输数据可能出错：控制字段若被噪声击中，收发双方会在确认、丢帧或重复帧上发生分歧。TCP 与 IP 的校验在更高层工作，慢速链路等它们来收拾故障，恢复会拖得更久。他还指出，CRC 与上层加法式校验捕捉的错误型态不同，两种相似的加法校验叠起来仍有共同盲区。在每秒最多约 120 字符的假设下，他估算软件 CRC 每字符要约五至六条指令，网关还可能有硬件支持。

他给出的方案并非全盘照抄某一种旧协议。帧用 DLE STX … DLE ETX CRC CRC 的透明字符格式；控制部分借 LAPB 的序号与确认，可把确认搭在反向流量上，每方向最多让七帧同时在途。点对点线路用不上多点地址，现成标准却带着地址字段；Robinson 选择保留它，因为删去这个字符就要离开现成实现。每帧总计八个字符。他也承认 RATP 的单字符特例还能进一步减开销，却认为敲字业务里的空闲带宽足以容纳那点差异。

最尖锐的一笔是芯片。广泛使用的规程会得到厂商的实现，网关和个人电脑都可能从硬件分担处理工作中获益；自定义协议则要自己承担代码、互通、诊断和供货。RFC 935 提出的不是已获采用的行业判决，而是 1985 年的一份公开报价。文末 Robinson 还预测 X.25/X.32 会迅速取代这类拨号接入，并提到自己方案与约 1976 年的 Telenet 链路设计相似。那是他的时代判断。文章真正留下的难题在另一处：当线路出错时，省下两个字符的那张表，能不能教接收机找回下一帧？

来源