一、各家说各家的话

早期的计算机通信是一片方言区：

第一行是说 IBM 的 SNA、DEC 的 DECnet 这些体系： 每一家都自成一套、内部很完整、对外完全不通。 客户买了两家的设备，就只能买两套网、养两拨人。 第二行是关键转折：ARPANET 的 TCP/IP 第一次证明了「不同厂商的机器能跑同一套协议」， 而且这套协议是公开的、不要授权的。 这一点决定了后来的格局——不是技术更好的赢，是「谁都能用」的赢。

二、谁在定标准

定标准的机构不止一个，各管一段：

第二行与我们关系最大：IETF 的产出就是 RFC，编号连续、全文公开、免费下载。 它没有会员费、没有投票权门槛， 靠「跑得起来的实现」和「粗共识」推进——这也是它能跟上互联网速度的原因。 第三行是两个常被混淆的东西：802.3 是以太网（有线），802.11 是无线局域网， 它们都只管最底下两层，这也是为什么 Wi-Fi 和以太网能无缝接在一起——上面的层是同一套。

三、RFC 是一份带编号的文档

几个必须认得的编号：

注意 TCP 有两条：793 用了四十一年，2022 年被 9293 取代。 协议不是刻在石头上的，它可以被新文档替换。 但替换的是「文档」，不是「行为」—— 9293 主要是把几十份勘误和补充合并进来，没有推翻 793 的做法。 编号大小与重要性无关：768（UDP）比 791（IP）还早，编号只代表提交顺序。 从 768 到 9293 跨了八千多号，中间绝大多数是早已废弃的实验文档。 这就是「标准化」的实质：把「大家实际怎么做」写成一份谁都能下载的公开文档， 然后让实现对齐文档，而不是让实现对齐某一家厂商。

四、动手 Demo：标准是一份带编号的文档

把几份关键 RFC 的编号、年份、职责列出来。 这些都是可以逐条查到的事实，不是记忆题。

import urllib.request

docs = [('RFC 791', 1981, 'IP (IPv4)'),
        ('RFC 793', 1981, 'TCP 原始规范'),
        ('RFC 768', 1980, 'UDP'),
        ('RFC 9293', 2022, 'TCP 现行规范'),
        ('RFC 8200', 2017, 'IPv6')]
for num, year, what in docs:
    print('%-10s %-6d %s' % (num, year, what))

url = 'https://www.rfc-editor.org/rfc/rfc9293.txt'
req = urllib.request.Request(url, method='HEAD')
with urllib.request.urlopen(req, timeout=8) as r:
    print('rfc9293.txt 状态 %d、长度 %s 字节'
          % (r.status, r.headers.get('Content-Length')))

实跑输出：

--------------------------------------------------------------------
标准是一份带编号的文档
--------------------------------------------------------------------
**书里说「协议由谁规定」——规定它的是 RFC 文档，每份一个编号。**下面这几个编号是硬事实，
直接查得到的：

  编号         年份     管什么
  -----------------------------------------------
  RFC 791      1981     IP（IPv4）
  RFC 793      1981     TCP 原始规范
  RFC 768      1980     UDP
  RFC 9293     2022     TCP 现行规范（取代 793）
  RFC 8200     2017     IPv6

**注意 TCP 有两条**：793 用了四十一年，2022 年被 9293 取代。
**协议不是刻在石头上的，它可以被新文档替换。**

**从 768 到 9293，编号跨了 8525 号**——**编号不代表重要程度，只代表提交顺序。**

**「标准化」的实质是：**
**把「大家怎么做」写成一份谁都能下载的公开文档**，
**然后让实现去对齐文档，而不是让实现去对齐某一家厂商。**

TCP 有 793 与 9293 两条，这是本节最值得记住的一处：一份规范活了四十一年，被新文档接替。 最后两行真的去拉了 RFC 9293 的头部：能拉到就说明「标准是公开可下载的」不是一句口号。 换一家厂商的私有协议，你拿不到这份文档。 这也是排障时最有用的一条路子： 遇到「这个字段到底该填什么」的疑问，直接查 RFC 原文，别信二手博客。

30 秒实验

1. 把 rfc9293.txt 换成 rfc768.txt， 对比两份文档的长度——感受一下「UDP 简单、TCP 复杂」在文档体量上的差距。
2. 去 rfc-editor 网站搜 HTTP/1.1，找到它的 RFC 编号（2616 与 7230 系列）。
3. 查一下 IEEE 802.3 与 802.11 分别对应什么，想想为什么它们只覆盖最底下两层。

常见误区

1. 以为标准是「技术上最优的那个方案」。 常常是「先跑起来、能被广泛实现」的那个。 OSI 七层在理论上更完整，实际赢的是 TCP/IP。
2. 以为 RFC 编号越大越新越重要。 编号只代表提交顺序，绝大多数 RFC 是实验性的、早已废弃的。
3. 以为标准化就是「统一实现」。 统一的是行为与接口， 实现可以千差万别——这正是各家协议栈能共存的原因。

下一节讲「标准化之后剩下什么」——标准统一了行为，但没统一写法，这才有了后来的协议演进。

• ☐ （本节完，下一节 1.4.2 协议的标准化）

相关笔记

• 分组交换协议
• 协议的标准化
• 📚 图解TCP／IP · 索引