互联网技术标准中，愚人节玩笑竟有如此悠久的传统。

在这篇文章中，Omer 带我们愉快地探索了 IETF 发布的近 50 年来的愚人节 RFC。你将了解到“鸽子传 IP”、“邪恶位”、HTTP 418 等笑话，这些玩笑背后也透露了不少互联网真实运作的原理。

https://freecodecamp.org/news/the-internet-s-longest-running-joke-a-field-guide-to-the-april-fools-rfcs/…

互联网历时最久的玩笑：愚人节 RFC 实地指南

来源：https://www.freecodecamp.org/news/the-internet-s-longest-running-joke-a-field-guide-to-the-april-fools-rfcs/

互联网历时最久的玩笑：愚人节 RFC 实地指南

以下是互联网管理者们发布的一份官方文件中的一句话：

“那些无法通过阅读文本来区分讽刺作品的读者，或许在市场营销领域会有前途。”

这句话实际上出自 RFC 编辑的 《RFC 作者指南》，即互联网标准如何编写的实际规则手册 [1]。

这引发了一个合理的问题：为什么制定 IP、TCP 和 HTTP 的标准机构，需要白纸黑字地警告你，它自己的一些文档是玩笑？

因为近五十年来，它一直在故意发布这些玩笑文档。

如果你读过我的文章，就知道我热爱计算机网络，特别是我们日常依赖的协议细节。当我第一次偶然发现这个传统时，真的被震撼到了，从此它成了我最爱谈论的话题之一。那么，让我们开始这场巡礼吧。

自 1978 年起，每年的 4 月 1 日，IETF 都会至少发布一份刻意幽默的 RFC。其中最棒的那些，在形式上与定义真实互联网的文档毫无二致。

本文基于我的演讲“愚人节 RFC”。如果你更喜欢视频，可以在此观看 (https://youtu.be/Pv3AyfFzUss)。我提到的每一份 RFC 都是真实的，并在文末的参考资料 (https://www.freecodecamp.org/news/the-internet-s-longest-running-joke-a-field-guide-to-the-april-fools-rfcs/#references)中附有链接，你可以亲自去阅读原文。

目录

• 首先，什么是 RFC？ (https://www.freecodecamp.org/news/the-internet-s-longest-running-joke-a-field-guide-to-the-april-fools-rfcs/#heading-first-what-even-is-an-rfc)
• 一切的开端：RFC 748 (1978) (https://www.freecodecamp.org/news/the-internet-s-longest-running-joke-a-field-guide-to-the-april-fools-rfcs/#heading-the-one-that-started-it-all-rfc-748-1978)
• 官方立场（以及那句营销名言） (https://www.freecodecamp.org/news/the-internet-s-longest-running-joke-a-field-guide-to-the-april-fools-rfcs/#heading-the-official-position-and-the-marketing-line)
• RFC 1149：鸟类载体的 IP 传输 (1990) (https://www.freecodecamp.org/news/the-internet-s-longest-running-joke-a-field-guide-to-the-april-fools-rfcs/#heading-rfc-1149-ip-over-avian-carriers-1990)
• RFC 2549：鸽子，但带服务质量 (1999) (https://www.freecodecamp.org/news/the-internet-s-longest-running-joke-a-field-guide-to-the-april-fools-rfcs/#heading-rfc-2549-pigeons-but-with-quality-of-service-1999)
• RFC 3514：邪恶位 (2003) (https://www.freecodecamp.org/news/the-internet-s-longest-running-joke-a-field-guide-to-the-april-fools-rfcs/#heading-rfc-3514-the-evil-bit-2003)
• RFC 1925：网络十二定律 (1996) (https://www.freecodecamp.org/news/the-internet-s-longest-running-joke-a-field-guide-to-the-april-fools-rfcs/#heading-rfc-1925-the-twelve-networking-truths-1996)
• RFC 2324：咖啡壶与状态码 418 (1998) ☕ (https://www.freecodecamp.org/news/the-internet-s-longest-running-joke-a-field-guide-to-the-april-fools-rfcs/#heading-rfc-2324-the-coffee-pot-and-status-418-1998)
• ASCII 的艺术：RFC 8140 (2017) (https://www.freecodecamp.org/news/the-internet-s-longest-running-joke-a-field-guide-to-the-april-fools-rfcs/#heading-the-art-of-ascii-rfc-8140-2017)
• 现代瑰宝 (https://www.freecodecamp.org/news/the-internet-s-longest-running-joke-a-field-guide-to-the-april-fools-rfcs/#heading-the-modern-gems)
• 我的感悟 (https://www.freecodecamp.org/news/the-internet-s-longest-running-joke-a-field-guide-to-the-april-fools-rfcs/#heading-what-i-take-from-all-this)
• 参考资料 (https://www.freecodecamp.org/news/the-internet-s-longest-running-joke-a-field-guide-to-the-april-fools-rfcs/#heading-references)

首先，什么是 RFC？

RFC 代表 Request for Comments（请求评议）。它是一份编号文档，描述互联网的协议或标准，由互联网工程任务组（IETF）自 1969 年起发布。如果你曾好奇规则到底在哪儿，答案就在这里。

每一份 RFC 有且只有一个编号，且发布后永不被编辑。它可能被后来的 RFC 更新或废止，但原版始终冻结在其编号下。它是互联网最接近宪法的东西：一系列文档声明“这是标准”，然后所有构建路由器、浏览器和邮件服务器的人都同意遵循它。

现在请记住这个形象：严肃的编号标准、冻结的宪法——因为只有当你像 IETF 一样认真对待这个格式时，玩笑才能成立。

一切的开端：RFC 748 (1978)

1978 年，系列中出现了一份奇怪的东西。Mark Crispin，后来创建了 IMAP（你的邮件客户端用来读取收件箱的协议），发布了 RFC 748：“TELNET 随机丢失选项”。[2]

他的观察：当时许多网络主机已经提供了“随机损失”，即崩溃、数据丢失以及程序无故出错。问题在于，这是一个未文档化的特性。因此 RFC 748 旨在修复这个问题——不是通过消除异常行为，而是通过将其标准化。

它提议了 Telnet 选项代码 256，这样两台机器可以正式协商服务器是否允许随机故障：

• IAC WILL RANDOMLY-LOSE：“我请求允许随机丢失。”
• IAC DON'T RANDOMLY-LOSE：“我要求你停止随机丢失我的数据。”

它凭空出现，语气一本正经，格式与周围所有严肃的选项规范如出一辙。自那以后，RFC 编辑几乎每年愚人节都延续了这个传统。

官方立场（以及那句营销名言）

这个传统足够正式，以至于被写入了《RFC 作者指南》[1]：

“多年前，RFC 编辑确立了每年 4 月 1 日发布一篇或多篇讽刺性文档的做法。读者应注意，许多日期为 4 月 1 日的 RFC 不应被当真。”

然后是点睛之笔，也就是我们的开篇引言：

“请注意，过去几年中，RFC 编辑有时会在 4 月 1 日发布严肃文档。那些无法通过阅读文本来区分讽刺作品的读者，或许在市场营销领域会有前途。”

声明一下，我喜爱市场人士。这是 IETF 说的话，不是我。😄 但你能看出他们的调皮：他们也会在 4 月 1 日乐意地发布真正的标准，而你得通过阅读实际文本来区分。现在来认识一下经典之作。

RFC 1149：鸟类载体的 IP 传输 (1990)

这大概是最著名的愚人节 RFC 了。

一只二战时期的信鸽栖息在树枝上，胸前绑着一个小相机背带。图片来源：Bundesarchiv, Bild 183-R01996 (https://commons.wikimedia.org/wiki/File:Bundesarchiv_Bild_183-R01996,_Brieftaube_mit_Fotokamera.jpg) / CC BY-SA 3.0 DE (https://creativecommons.org/licenses/by-sa/3.0/de/deed.en)。(来源：Brief (https://youtu.be/Pv3AyfFzUss))

1990 年，David Waitzman 定义了一个使用信鸽传输 IP 数据报的标准 [3]。全文以完全直白的方式写成，承认了真实的工程权衡：高延迟、丢包（鹰隼）以及风暴干扰。最大传输单元（MTU），即一次能发送的最大数据块，受限于载体的腿长（我在关于 IPv4 工作原理 (https://www.freecodecamp.org/news/how-ipv4-works-a-handbook-for-developers/)的文章中介绍过 MTU）。

以下是直接从 RFC 引用的数据包格式：

“IP 数据报以十六进制打印在一小卷纸上，每个八位组之间用空白和注释分隔。纸卷缠绕在鸟类载体的一条腿上。”

八位组（octet）就是字节的另一种说法。是的，这是一份真实、已发布、有编号的 RFC。

当人们真的实现它时（卑尔根，2001 年）

接下来的故事就精彩了。2001 年，挪威的 卑尔根 Linux 用户组 决定真的这么做。他们通过鸽子发送了 9 个 ICMP 回显请求数据包（ping，来自我们第三层的视频），距离超过 5 公里。

结果正如你所期待的那么科学：

• 丢包率：55%（9 只鸽子中只有 4 只成功返回）。
• 往返时间：每数据包大约 50 到 100 分钟。

这是历史上第一次确认的符合 RFC 1149 的 ping。以普通 ping 输出呈现，运行结果如下：

64 bytes from 10.0.3.1: icmp_seq=0 ttl=255 time=6165731.1 ms 64 bytes from 10.0.3.1: icmp_seq=4 ttl=255 time=3211900.8 ms 64 bytes from 10.0.3.1: icmp_seq=2 ttl=255 time=5124922.8 ms 64 bytes from 10.0.3.1: icmp_seq=1 ttl=255 time=6388671.9 ms

往返时间大约六千秒。对一只鸽子来说，这其实不算差了。

温斯顿鸽子 vs. Telkom（2009 年）

快进到 2009 年，南非。金融服务业公司 The Unlimited Group 有两个相距 80 公里的分支，受够了当地电信 Telkom 慢如蜗牛的 ADSL。一名员工开玩笑说鸽子更快。于是他们测试了。🐦

他们将一张 4 GB 的记忆卡绑在温斯顿（一只 11 个月大的信鸽）身上，让他飞行 80 公里，从 Howick 到 Hillcrest。温斯顿耗时 1 小时 8 分钟 完成飞行；算上将记忆卡卸载到计算机的时间，整个传输大约用了 2 小时 6 分 57 秒。

与此同时，同样的 4 GB 文件正在通过 Telkom 的 ADSL 并行上传。当温斯顿降落时，大约 100 MB 已经传输完成。约 4%。预计完成上传的时间可能长达两天。

温斯顿赢了，而且赢得毫无悬念。公司 IT 主管 Kevin Rolfe 表示，这一噱头是为了开启关于南非宽带现状的对话，而非针对 Telkom。任务完成。

RFC 2549：鸽子，但带服务质量 (1999)

自然，如此重要的协议需要续集。RFC 2549 为鸟类载体增加了服务质量 (QoS) [4]。它定义了服务等级（头等舱、商务舱和经济舱），用蜡纸来防水数据报，并将躲避风暴重新归类为路由问题。头等舱的载体甚至还能加密，通过将数据卷藏在羽毛内部。

最棒的是，其中包含了加权公平队列实现的真实 ASCII 艺术——一只站在秤上的鸽子：

__ _____/-----\ / o\ <____ _____\_/ >-- +-----+ \ / /______/ | 10g | /|:||/ +-----+ /____/| | 10g | | +-----+ .. X =============================== ^ | =========

两个十克砝码、一只鸽子和一个水平秤，这样你就知道数据包正好重二十克，可以相应排队了。

RFC 3514：邪恶位 (2003)

这可能是整个系列中我最喜欢的讽刺作品，因为它精准地嘲讽了一个真正的难题。

防火墙的全部工作就是区分恶意流量和良性流量。这很困难。所以在 2003 年，Steve Bellovin 提出了一个绝妙的简单修复方案 [5]。IPv4 头部有一个未使用的比特位，预留供将来使用（如果你想回顾一下，可以参考我之前的文章 (https://www.freecodecamp.org/news/how-ipv4-works-a-handbook-for-developers/)）。Bellovin 为它找到了用途：邪恶位。

• 发送良性数据包？将该位设为 0。
• 发送恶意数据包？你必须将该位设为 1。

防火墙只需丢弃所有设置了邪恶位的数据包。问题解决。所有网络安全，就此达成。整个安全模型，按照 RFC 的描述，就是这样：

0 +-+ |E| +-+

RFC 1925：网络十二定律 (1996)

1996 年，Ross Callon 发布了一份关于网络“基本真理”的清单 [6]。它完全以直白的方式写成，与任何真实标准一样包含摘要和编号章节。幽默完全来自于严肃的包装与内部内容之间的反差。我最喜欢的一些：

• (2) “无论你多么努力推动，无论优先级多高，你都无法增加光速。”
• (4) “生活中有些事情，除非亲身经历，否则永远无法完全欣赏或理解。”
• (7a) “好、快、便宜：任选两个（你不能三者兼得）。”
• (11) “每个旧想法都会以不同的名称和不同的呈现方式被重新提出，不管它是否有效。”

如果你在这个行业待过一段时间，第 11 条大概会有点扎心。🙌🏻

RFC 2324：咖啡壶与状态码 418 (1998) ☕

你很可能见过这个笑话的结局，却不知道它来自哪里。

一个棕色陶瓷茶壶放在黑色笔记本电脑上，代表一个联网咖啡壶。图片来源：Joseph, Royal Holloway (https://commons.wikimedia.org/wiki/File:HTCPCP_Pot.jpg) / CC BY-SA 3.0 (https://creativecommons.org/licenses/by-sa/3.0/)。(来源：Brief (https://youtu.be/Pv3AyfFzUss))

1998 年，Larry Masinter 提出了超文本咖啡壶控制协议 (HTCPCP)，用于通过 HTTP 控制、监控和诊断咖啡壶 [7]。它为 HTTP 增加了两个方法，BREW 和 WHEN（后者告诉壶停止倒牛奶），并引入了一个新的状态码：

418 I’m a Teapot。 如果茶壶被要求煮咖啡，应响应 418。

所有以 4 开头的 HTTP 状态码（例如 400、401）都是客户端错误，所以这表示：如果你让茶壶做咖啡，那是你的错误。而这个虚构的状态码如此受欢迎，以至于真实的软件都采用了它。

不死的 418

一个内置树莓派电路板的陶瓷茶壶，盖子被打开，一根电线伸出。图片来源：A. Cilia (https://commons.wikimedia.org/wiki/File:Htcpcp_teapot.jpg) / CC BY-SA 3.0 (https://creativecommons.org/licenses/by-sa/3.0/)。(来源：Brief (https://youtu.be/Pv3AyfFzUss))

在手机上访问 google.com/teapot 并倾斜设备：小茶壶会倾倒并倒出液体，同时返回 HTTP 状态 418。Node.js、Python、Go 以及许多其他技术栈都在其 HTTP 库中内置了 418。

2017 年，IETF HTTP 工作组主席 Mark Nottingham 发起运动移除 418，认为一个玩笑代码不应存在于真实实现中。社区强烈反击：save418.com 集结了开发者，418 幸存了下来 [8]。源自愚人节 RFC 的虚构状态码，如今已成为网络上最广为人知的代码之一。后来它甚至被扩展用于茶，见 RFC 7168 [9]。

ASCII 的艺术：RFC 8140 (2017)

2017 年，Adrian Farrel，一位撰写了大量严肃 RFC 的作者，用 RFC 8140 结束了没有玩笑的 2016 年。其完整标题故意拼写出来像古英文：“The Arte of ASCII: Or, An True and Accurate Representation of an Menagerie of Thynges Fabulous and Wonderful in Ye Forme of Character” [10]。

古英文风格本身就是笑点的一部分。整个 RFC 全是