摘要

  • 1990 年 4 月的 RFC 1152记录了一场由互联网研究指导小组发起的高速网络工作坊。David Clark 提醒与会者：若目标只是达到每秒千兆，现有协议已经有潜力；长距离、多用户和新服务才让设计问题变复杂。
  • 同一份记录中，Keith Lantz 把低时延和音视频同步放在应用需求中心；Craig Partridge 指出远程调用的往返等待会吞掉越来越多处理器周期；Nectar 原型的主机接口又把板间吞吐与程序实际拿到的速度拉开。

先问速度要替谁工作

这场工作坊由互联网研究指导小组发起，该小组属于 IRTF 的运作体系。Craig Partridge 整理的 RFC 1152 来自各场会议主席的记录，并经过参与者审阅。文档保留了彼此不同的主张，读起来像一间真正的研究会议：一项新能力刚露面，大家已经开始争论它会卡在哪里。

在协议实现的讨论里，David Clark 提出了一个让“换掉旧协议”没那么顺理成章的判断：如果只要求每秒千兆，现有协议也能办到。现实中的高速网络还要走远路、服务大量用户，并承载预留带宽等新功能。研究者因而需要先说清楚需求，再评价是改实现方法、增加专用处理器，还是重排协议功能。会议记录没有宣布一条唯一的升级路线，反而把问题的边界画得更细。

Keith Lantz 从使用者那头拆开“快”。他描绘的“可携带办公室”指人无论在公司、家中还是远处，都能访问相同的服务和协作者；关键是服务可以跟着人走。桌面视频会议会让文字、图像、声音与影像同时流动。各路数据需要的带宽相差很大，却普遍需要低时延，其中一些还需要稳定的到达节奏，彼此更得对齐。声音和嘴唇各走各的，线路再宽也救不了这场会议。

Lantz 还主张协议能够适应拥塞、低速网络以及画质可调整的场景。现实路径可能跨过不同能力的网络；应用不能只按最宽的一段设计。让视频分辨率随条件变化，属于服务能否继续使用的决定，而非给千兆数字添一个脚注。

光走得快，距离照样收费

在分布式系统讨论中，Partridge 指出另一个账本：计算机变快了，远程调用的往返时间却受传播距离限制。处理器在等另一台机器回答时，浪费掉的指令周期越来越多。并行发起多个请求可以让工作交叠，却不能让一个必须逐步等待结果的请求链立刻结束。提前猜测未来需要什么，也有预测出错的代价。

他把大量缓存看作一条会绕回原点的路：缓存越多，维护各处内容一致所需的通信就可能越多，最后为了避免普通远程调用，又发起同步调用。他更看好把同一台机器上的几项工作合并成一次较大的远程操作。报告中其他发言者也提出提前预取和异步编程等办法。争论本身说明，瓶颈已从链路速度移到了程序如何安排请求。

主机接口也给出现场证据。报告称，Carnegie Mellon 的 Nectar 原型中，通信板上的进程可在板间达到 70 Mbps，主机进程却受 VME 接口限制，约为 25 Mbps。这是该原型的初步数据，却足以把问题画清楚：数据通过网络，并不等于应用已经拿到数据。Jeff Mogul 进一步把数据搬入处理器缓存、通知用户进程的开销列为将来可能主导的成本。

这份工作坊记录的价值，正在于它没有把千兆当成终点。线路、远程调用、同步的音视频、低速路段、主机总线和进程通知，最终都要落到同一个使用动作上。谁在等、等多久，才是那道无法用广告牌遮住的问题。