摘要

  • RFC 872 质疑一种流行看法：局域网速度高、出错少，TCP 就必然显得多余。应用需要什么样的主机间服务，才是决定性的起点。
  • Padlipsky 认可 UDP 或直接使用本地网络能力的场景；但若机器还要连接外部网络，另养一套本地协议也得付开发和维护费。

两台机器之间只有一根短线，TCP 看起来像是带着全套行李来串门。Michael A. Padlipsky 在 1982 年 9 月的 RFC 872 里问：箱子里究竟是什么？有人反复说，为跨网络通信设计的 TCP 不适合局域网。他借故事里的“乌兹兽”形容这种越传越大的恐惧：人们追着自己的脚印走，最后确信森林里有怪物。电缆确实存在；怪物需要先经过技术检查。

他先界定讨论中的局域网。它连接近距离的主机，传输速率高、错误较少，主机可以是不同系统，并通过彼此通信来共享资源。介质可以不同，拓扑也可以不同。关键是主机之间真正要交换什么。若只是一些终端分别接入几台主机，而主机彼此并不用计算机间协议通信，Padlipsky 会给它另一个名字。线路的物理本领与应用收到的服务，不能在一张表里混为一谈。

TCP 为有此需求的应用提供可靠的逻辑连接、流量控制和有序交付。接收方搬到同一层楼，文件也还是要按顺序到齐。低错误率能改善传输环境，应用的要求却不会随楼道长度自动改写。把“距离近”直接推成“不需要可靠服务”，等于让网线替程序员签了合同。

IP 的职责又是另一层。Padlipsky 把它与 TCP 分开讲：IP 判断目标是否在近旁的网络上，否则把数据送往网关；它还要处理不同网络可接受的数据包大小，并在接收端交给正确的上层协议。这套跨网机制也可供 TCP 以外的主机间协议使用。一台机器若既要与同室主机通信，也要走向更远的网络，局域网只是整个路径的第一段。第一段宽阔，不等于后面的路消失了。

其他选择始终存在。RFC 提到分组语音一类用途：应用更看重速度时，可用 UDP，而无需 TCP 那套可靠连接。若程序专为本地设施设计，也可以更直接地使用局域网的能力。但为本地通信另造一套完整协议、同时保留 TCP/IP 供外网使用，意味着同一批主机里有两套代码、两套假设、两份维护工作。为了躲开想象中的笨重协议而增加一套真实的复杂系统，账本可能很幽默，维护人员未必笑得出来。

性能疑虑值得测量。局域网出错少，TCP 校验和看上去像多做一道手续。Padlipsky 引述当时研究环境中若干主机实现的计时结果，说明校验计算在每次传输处理时间里只占一部分。那是特定年代、特定实现的观察。工程上的好问题是比较整条工作链：磁盘多久取出数据，操作系统怎样调度，应用怎样消费，替代协议又花多少处理时间。标称链路速率再高，也得等主机把数据交出来。

文中还列出已运行的 TCP/IP 实现和相容的应用协议，说明讨论的对象确实在机器上工作。Padlipsky 同样要求谨慎测量 TCP/IP 在局域网上的性能。本地替代方案可以凭具体用途与实测优势赢得位置；比较时要把服务内容与后续维护都算进去。单看电缆上的数字，容易把瓶颈错认成协议的影子。

RFC 872 留下的是一个 1982 年的工程争论，也是一套拆解疑虑的顺序：应用需要可靠、有序、受控的交付吗？同一台主机还要跨过局域网吗？测出来的限制到底在电缆、协议、磁盘还是应用？问题越具体，墙上的怪兽就越小。