工坊 · 223 字 · 1 分钟阅读

RFC 1:发明互联网治理的文档

Steve Crocker 在深夜的浴室里写下了 RFC 1,因为他不想显得专横。这份试探性的文档成为了后来所有互联网标准的范本。

#TL;DR

1969 年 4 月,一位名叫 Steve Crocker 的 24 岁 UCLA 研究生写下了一份三页的笔记,描述了 ARPANET 主机软件小组一直在讨论的一些想法。他将其命名为 “Request for Comments”(请求评论)——不是 Specification(规范),也不是 Standard(标准)——因为他害怕一位研究生发出的”规范”会冒犯资深研究人员。这个试探性的名字保留了下来。五十七年和近 10,000 份文档之后,互联网上每一个重要的协议——TCP、IP、SMTP、HTTP、DNS、TLS、QUIC——都是通过一位紧张的研究生为避免显得专断而发明的同一流程定义的。

#1969 年 4 月的情况

四节点 ARPANET 距离上线还有八个月。BBN 正在构建 IMP。电线正在安装。但没有人决定这些主机计算机——UCLA 的 SIGMA 7、SRI 的 SDS 940、UCSB 的 IBM 360/75、Utah 的 PDP-10——将如何通过新网络实际相互通信。

ARPA 没有指定委员会。没有工作组。只有四个站点的研究生们一直在非正式地会面,头脑风暴可能的协议。他们自称为 Network Working Group (NWG)

有人需要写下他们讨论过的内容。Crocker 自愿承担,然后立即开始担心。

#浴室、浴缸和标题

此后 Crocker 多次讲述过这个故事。他住在朋友家里。室友们都睡着了。他想在不打扰任何人的情况下工作,所以他拿着一个记事本走进浴室,在不打扰其他人的光线下连夜写作。

焦虑是结构性的。Crocker 24 岁。他没有资格向一个充斥着来自半打机构的资深研究人员的领域发布规范。如果他写 “Host 软件规范” 或 “ARPANET 协议标准”,哈佛和 MIT 的人会合理地问他以为自己是谁。

所以他软化了它。每一段都有所保留。标题使整个东西明确是临时的:

Request for Comments 1969 年 4 月 7 日 Host Software Stephen D. Crocker UCLA

这个框架是一个社会工程动作。你没法反对某人在征求意见。而一旦意见来了,每个贡献过的人都隐含地成了参与者。规范是强加的,Request for Comments 是邀请的。五十年的互联网治理都靠这个区别在支撑。

#RFC 1 实际上说了什么

今天读 RFC 1,它是一份奇怪的文档。它不是一个协议的设计——它是一个关于一个协议的对话的设计。它提出了一些没能存活下来的东西,勾勒了一些仍然与我们同在的想法,并故意把大多数真正的问题留着不答。

大致上,文档论证道:

  • 主机到主机的通信应该是分层的。下面有 BBN 提供的 IMP 子网,上面有主机软件。两者应该清晰地分开。
  • 每个主机应该运行一个叫 Network Control Program 的程序,管理与其他主机的连接。
  • 连接应该是全双工的,由一对命名的 socket 标识。更高层的用途——远程登录、文件传输——作为这种连接原语的使用者运行。
  • 应该区分连接(短、面向控制)和辅助连接(长、数据密集)。这个划分在早期 NCP 里短暂存在过,后来被废弃了。
  • 流控重要但这里不做规范。应该让别人再写一个 RFC 讨论它。

重要的不是技术内容——其中大部分是错的,一年之内就被后续的 RFC 替换掉了,最终被 TCP/IP 取代。重要的是格式:一份带日期、带编号、有签名的文档,提出问题、解释问题、邀请回应。

#RFC 1 启动了什么

Network Working Group 继续写。到 1969 年底,他们出了大约 20 份 RFC。到 1971 年,数字已经到数百。每一份都建立在或替代一份更早的。这个体裁的规则自然而然地固定下来了:

  • 按顺序编号,永不复用。 RFC 3 作废了 RFC 2;RFC 2 仍然留在档案里。什么都不会被删。这就是互联网规范语料库如何成为自己演化的分层记录——你今天仍然可以把 RFC 821(最初的 SMTP,1982 年)和 RFC 5321(它的替代品,2008 年)并排读。
  • 任何人都可以写。 RFC 是被编辑的,不是由机构把关的。电信公司的 Pat Lyall、伯克利的研究生、思科的工程师,走的都是同样的审查流程。
  • 纯文本,无标记。 直到最近,RFC 都是 72 列 ASCII,以便在任何终端上可读。那个约束现在没了,但”一个文件、无依赖、永远可读”的文化留了下来。
  • “我们拒绝国王、总统和投票。我们相信粗略共识和能跑的代码。” 这句话——出自 1992 年一次 IETF 会议上的 Dave Clark——成了 IETF 事实上的宪法。当足够多的实现者达成一致,并且至少存在两个可互操作的实现时,一个标准才算定案。

#治理的意外

RFC 1 无意中解决了标准机构在一个世纪里都在搞不定的问题。由今天的 ITU 维护的国际电信标准,是 Crocker 模型的对立面:政府派代表,文档用法语和英语并行书写,批准要花好几年,产出的规范读起来还要花钱。厂商各实现各的,还都宣称自己兼容。

RFC 流程正好相反:

  • 读免费、引用免费、实现免费。
  • 自下而上,谁在乎到愿意露面,谁就来推动。
  • 增量的——提出小改动的 RFC 可以在几个月内成为标准。
  • 实现优先——如果代码跑不起来,RFC 就不发。

后来 ISO 试图通过传统的自上而下流程去标准化自己的七层网络栈(OSI 模型)时,输得彻底,因为 TCP/IP 已经通过 RFC 迭代了十年,OSI 才出来。OSI 模型如今主要作为一种教学工具存在。RFC 模型在运行互联网。

#不是命令的那份文档

RFC 1 的诀窍——Crocker 的措辞至今仍在统治的原因——是它拒绝声称自己没有的权威。“Request for Comments” 是为那些后来会被证明是错的贡献者设计的体裁。它优雅地挺过被证伪。规范可以被违反,请求评论只能被取代

事实证明,对于一个需要跨越五十年、六代硬件、九个数量级的规模扩张还要不断演化的标准过程来说,这是对的设计。当你设计的东西最终会运行在从 900 磅的 Honeywell 到一台智能恒温器的所有设备上时,你没法提前知道正确答案。但你能知道如何让对话继续下去。

ARPANET 那篇文章把 RFC 1 当成一位紧张研究生的可爱轶事。它也是工程史上最成功的标准语料库的第一条目——而且是这张清单上唯一一份被刻意写得不像治理文档的治理文档。