摘要

  • RFC 914 的例子中，一个 Telnet 字符装在 41 字节的 TCP/IP 包里。按作者给定的线路假设，1200 波特的链路发完它约需 0.3 秒；每包只送一个字符时，有效速率约为 30 波特。
  • Thinwire I、II 分别把示例缩到 17 和 13 字节；Thinwire III 则让网关代办网络与传输事务，文中估算平均有效速率约 900 波特。每一步提速都要另找地方存放工作与责任。

一颗葡萄配一辆货车，送货公司肯定很高兴，收货人未必。1984 年的个人电脑接入互联网，有点像这门生意。David Farber、Gary Delp 和 Thomas Conte 在 RFC 914 里写道，3000 至 1 万美元的电脑已经足以放到办公室或家里；56k 专线贵、难等，1200 或 2400 波特的电话调制解调器更现实。可电脑一旦接上 Telnet，单个字符就背起 41 字节的 TCP/IP 包。用户买到了便宜的电脑，协议却仍按宽敞线路的习惯打包。

他们先把等待时间摆上桌。以 1200 波特传输这个最小包，大约要 0.3 秒；若每包只有一个字符，相当于约 30 波特的有效字符速率。这不是实地统计，而是按线路为唯一瓶颈、并把线路视作同步链路得出的估算。中断、计算和成帧开销，还可能让时间再恶化 10% 至 50%。本地回显、整行编辑可以让某些操作不那么难熬；必须逐字交互的程序仍要为每次击键付全价。

Thinwire I 像批改上一张表格。线路两端各保留前一个包，新的包只写“从这里起换掉几个字节”。示例更新包从 41 字节降到 17 字节，作者估算有效速率升到约 70 波特。办法直接，缺点也直接：它只记得一个共同底稿。不同类型的包交替出现时，新包与底稿越来越不像，节省便缩水。人们想让邮车少载纸，却发现每个部门递来的表格格式都不同。

Thinwire II 给不同连接分文件夹。每条 TCP 连接有自己的模板；位图指出头部哪些字段变了，短差量替代反复发送的长数值。示例缩到 13 字节，单字符的有效速率约 95 波特。省下来的线上空间，转成了两端的记忆负担：电脑得存多个模板，网关得管连接表。一旦两边记忆对不上，数据流就停。作者因此要求可靠的串行链路，并定期发送完整包重新对齐；压缩器不认识的协议，只好原样传。省字节并不免费，它把账记在状态同步和故障恢复上。

Thinwire III 索性问：为什么还要让个人电脑和细电话线承担整套互联网传输工作？在这个方案里，中央网关为电脑开 TCP、UDP 连接，电脑与网关之间用一条可靠串行流复用数据和控制命令。文中估算平均有效速率可到约 900 波特，跳幅远大于继续挤压包头。代价是角色变化：网关成为电脑对外连接的代理。电脑可以要求在网关处预留被动服务入口；普通外部主机却不能像连接完整互联网主机那样，直接向这台电脑发起任意入站连接。细线轻了，门房重了。

今天的 RFC Editor 记录 将它列为 Historic。1984 年作者提出的是讨论方案，文中的速度也是在限定条件下的计算。正因如此，这份文件保住了一个尚未被结果抹平的路口：少量压缩、较多的共享记忆，或者把网络职责交给网关。每一种都让个人电脑更接近互联网，每一种也规定了谁需要记住、修复和决定下一次连接。一个击键引出的问题，远比一个字符大。