如何阅读RFC

July 14, 2024

rfc

原文：How to Read an RFC by.Mark Nottingham
此文也被 IETF 官方博客刊载

无论好坏，RFC 是我们指定许多互联网协议的方式。这些文件有时被开发者视为圣典，仔细解析寻找隐藏的意义；而有时又被忽视，因为它们难以理解。
这常常令人沮丧，更重要的是，导致互操作性和安全问题。

然而，如果对它们的构建和发布有一些了解，就更容易理解你在看什么。以下是我的看法，基于我在 HTTP 和一些其它事情上的经验。

从哪里开始？

找到 RFC 的标准位置是 RFC Editor 网站。然而，正如我们将在下面看到的，它缺少一些重要信息，所以大多数人使用 tools.ietf.org。

找到正确的 RFC 可能很困难，因为数量很多（目前接近 9000 个！）。显然，你可以使用通用的网络搜索引擎找到它们，RFC Editor 网站上也有一个优秀的搜索功能。

另一个选择是我创建的 rfc.fyi，可通过标题和关键词搜索 RFC，并通过标签进行探索。

众所周知，纯文本的 RFC 难以阅读，甚至可以说很难看，但情况即将改善；RFC Editor 正在完成一个新的 RFC 格式，呈现更加美观，同时还有自定义选项。同时，如果你想要更易用的 RFC，可以使用第三方存储库；例如，greenbytes 保留了一份与 WebDAV 相关的 RFC 列表，[HTTP 工作组] (https://httpwg.org/specs/)维护了一些与 HTTP 相关的 RFC。

这是什么类型的 RFC？

所有 RFC 的顶部都有一个横幅，看起来像这样：

plain

Internet Engineering Task Force (IETF)                  R. Fielding, Ed.
Request for Comments: 7230                              Adobe
Obsoletes: 2145, 2616                                   J. Reschke, Ed.
Updates: 2817, 2818                                     greenbytes
Category: Standards Track                               June 2014
ISSN: 2070-1721

在左上角，这里写着“Internet Engineering Task Force (IETF, 互联网工程特别工作组)”。这表明这是 IETF 的产品；尽管不广为人知，还有其它不需要 IETF 共识就可以发布 RFC 的方式，例如独立流。

实际上，有许多“流”可以发布文档。只有 IETF 流表明整个 IETF 已经审查并对协议的规范达成共识。

较旧的文档（大约在 RFC5705 之前）在那里写着“网络工作组 (Network Working Group)”，所以你需要更多地挖掘才能确定它们是否代表 IETF 共识；首先查看“备忘录状态”部分，以及RFC 编辑器网站。

在那之下是“Request for Comments”编号。如果此处写着的是“Internet-Draft (互联网草案)”，那么它就不是 RFC；它只是一个提案，任何人都可以写一个。若某物仅仅是互联网草案并不意味着它会被 IETF 采纳。

**Category (类别)**可以是“Standards Track”、“Informational”、“Experimental”或“Best Current Practice”之一。这些之间的区别有时是模糊的，但如果是由 IETF 生产的（见上文），那么它已经经过了足够量的审查。然而，请注意，Informational 和 Experimental 不是标准，即使由 IETF 共识发布。

最后，**authors (作者)**列在标题的右侧。与学术界不同，这不是一份全面的贡献者名单；通常，这在文档底部的“Acknowledgments (致谢)”部分完成。在 RFC 中，这字面意思是“谁写了这篇文档”。通常，你会看到“Ed. (编辑)”附在后面，这表明他们是以编辑身份行事，通常是因为文本是预先存在的（例如，当 RFC 被修订时）。

它是最新的吗？

RFC 是一系列存档文档；它们不能改变，甚至一个字符都不能（以 RFC7158 和 RFC7159 之间的差异作为极端示例；它们把年份弄错了。

因此，知道你正在查看正确的文档很重要。标题包含一些有助于此的元数据：

**Obsoletes (废止)**列出该文档完全取代的 RFC；即，你应该使用这个文档，而不是那个。注意，当较新的版本出现时，旧版本的协议不一定被废止；例如，HTTP/2 没有废止 HTTP/1.1，因为实现旧协议仍然是合法的（也是必要的）。然而，RFC7230 确实废止了 RFC2616，因为它是该协议的参考。
**Updates (更新)**列出该文档对其进行了实质性更改的 RFC；换句话说，如果你在阅读那个其它文档，你也应该阅读这个。

不幸的是，ASCII 文本 RFC（例如，在 RFC 编辑器网站上）不会告诉你更新或废止了你当前查看的文档。这就是为什么大多数人使用 tools.ietf.org 上的 RFC 存储库，它将此信息放在一个横幅中：

plain

[Docs] [txt|pdf] [draft-ietf-http...] [Tracker] [Diff1] [Diff2] [Errata]

Obsoleted by: 7230, 7231, 7232, 7233, 7234, 7235          DRAFT STANDARD
Updated by: 2817, 5785, 6266, 6585                          Errata Exist

tools 页面上的每个数字都是一个链接，所以你可以轻松找到当前的文档。

即使是最新的 RFC 也常常有问题。在 tools 横幅上，你还会看到右侧有一个警告“勘误存在”，以及上面的勘误链接。

**Errata (勘误)**是对文档的更正和澄清，不值得发布新的 RFC。有时它们会对 RFC 的实现产生重大影响（例如，如果规范中的错误导致了重大误解），所以它们值得一读。

例如，这里是 RFC7230 的勘误。阅读勘误时，请记住它们的状态；许多被拒绝，因为有人误读了规范。

理解上下文

比你想象的更常见的是，开发者看了 RFC 中的一句话，按照他们看到的实现，结果做了与作者意图相反的事情。

这是因为很难以一种当被选择性阅读时不会被误解的方式编写规范（就像任何圣典一样）。

因此，有必要不仅阅读直接相关的文本，还要（至少）阅读它引用的任何内容，无论是在同一规范中还是在不同的规范中。必要时，阅读任何可能相关的部分会有很大帮助，如果你不能阅读整个文档的话。

例如，HTTP 消息头被定义为用 CRLF 分隔，但如果你向下跳到这里，你会看到“接收者可以将单个 LF 识别为行终止符，并忽略任何前面的 CR。”很明显，对吧？

还要记住，许多协议设置了IANA 注册表来管理它们的扩展点；这些，而不是规范，是事实的来源。例如，HTTP 方法的规范列表在这个注册表中，而不是任何 HTTP 规范。

解释要求

几乎所有的 RFC 在顶部附近都有类似这样的样板：

plain

本文件中的关键字 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", 和
"OPTIONAL" 应按照 BCP 14 [RFC2119] [RFC8174] 中的描述进行解释，当且仅当
它们以全大写形式出现时，如此处所示。

这些 RFC2119 关键字有助于定义互操作性，但它们有时也会让开发者感到困惑。很常见的是，规范会说：

plain

Foo 消息 不得(MUST NOT) 包含 Bar 标头。

这个要求是针对协议工件“Foo 消息”的。如果你发送一个，很明显它需要不包含 Bar 标头；如果你包括了一个，它就不是一个符合规范的消息。

然而，接收者的行为就不那么清晰了；如果你看到一个包含 Bar 标头的 Foo 消息，你该怎么办？

有些开发者会拒绝包含它的消息，即使规范没有说要这样做。其他人仍会处理消息，但会去掉 Bar 标头，或者忽略它——即使规范明确说所有头都需要处理。

所有这些都可能无意中导致互操作性问题。正确的做法是按照正常的标头处理流程，除非有具体要求相反。

这是因为一般来说，规范是这样编写的：行为是明确规定的；换句话说，所有没有明确禁止的行为都是允许的。因此，过度解读规范可能会无意中造成伤害，因为你会引入新的行为，其他人不得不绕过。

在理想的世界中，规范将以处理消息的人的行为为基础定义，如下所示：

plain

发送 Foo 消息的发送者 不得(MUST NOT) 包含 Bar 标头。
接收包含 Bar 标头的 Foo 消息的接收者 必须(MUST) 忽略 Bar 标头，但不得删除它。

在没有这种情况的情况下，最好在规范的其它地方寻找关于错误处理的更一般的建议（例如，HTTP 的一致性和错误处理部分）。

此外，记住要求的目标；大多数规范都有一套高度发达的术语，用于区分协议中的不同角色。

例如，HTTP 有代理，它们是一种中介，既实现了客户端又实现了服务器（但不是用户代理或源服务器）；它们需要注意针对所有这些角色的要求。

同样，HTTP 在某些要求中区分了“生成”消息和仅仅“转发”消息，具体情况而定。注意这种特定术语可以节省你很多猜测。

SHOULD

是的，SHOULD 值得有自己的部分。这个模棱两可的术语困扰着许多 RFC，尽管有努力在消除它。RFC2119 将其描述为：

plain

SHOULD 这个词，或形容词 "RECOMMENDED (推荐)"，意味着在特定情况下可能存在忽略某个条目的有效理由，
       但必须理解并仔细权衡所有影响，然后选择不同的做法。

在实践中，作者经常使用 SHOULD 和 SHOULD NOT 来表示 “我们希望你这样做，但我们知道不能总是要求这样做。”

例如，在HTTP 方法概述中，我们看到：

plain

当收到一个未被识别或未由源服务器实现的请求方法时，源服务器 应(SHOULD) 响应 501 (未实现) 状态码。
当收到一个源服务器知道但不允许用于目标资源的请求方法时，源服务器 应(SHOULD) 响应 405 (方法不允许) 状态码。

这些是 SHOULD 而不是 MUST，因为服务器可能会合理地决定采取其它行动；如果请求来自被认为是攻击者的客户端，它可能会断开连接，或者如果资源需要 HTTP 身份验证，它可能会在到达 405 之前用 401 (未认证) 强制执行。

SHOULD 不意味着服务器可以随意忽略一个要求，仅因为它不想遵守。

有时，我们会看到一个 SHOULD，像这样：

plain

生成包含有效负载主体的消息的发送者 应(SHOULD) 生成该消息中的 Content-Type 标头字段，除非发送者不知道所包含表示的预期媒体类型。

注意“除非”一词，它指定了 SHOULD 允许的“特定情况”。可以说，这可以指定为 MUST，因为除非条款仍然适用，但这种规范风格相当常见。

阅读示例

另一个非常常见的陷阱是浏览规范中的示例，并按照它们所做的实现。

不幸的是，示例通常是作者最少关注的部分，因为它们需要随着协议的每次更改而更新。

因此，它们通常是规范中最不可靠的部分。是的，作者在发布前应该绝对仔细检查示例，但错误确实会溜进去。

此外，即使是完美的示例也可能不是为了说明你正在寻找的协议方面；它们通常为了简洁而被截断，或者在解码步骤之后显示。

尽管需要花费更多时间，但最好阅读实际文本；示例不是规范。

关于 ABNF

增强 BNF 经常用于定义协议工件。例如：

plain

FooHeader = 1#foo
foo       = 1*9DIGIT [ ";" "bar" ]

一旦习惯了，ABNF 提供了一种易于理解的协议元素的草图。

然而，ABNF 是“理想化的”——它识别了消息的理想形式，而你生成的那些消息确实需要匹配它。它没有指定如何处理不匹配的接收消息。事实上，许多规范根本没有说明 ABNF 与处理要求的关系。

如果你试图严格执行 ABNF，大多数协议会严重失败，但有时这很重要。在上面的例子中，空格不允许出现在分号周围，但你可以打赌，有些人会把它放在那里，有些实现会接受它。

所以，一定要阅读 ABNF 周围的文本以获取附加要求或上下文，并意识到在没有直接要求的情况下，你可能需要调整解析以比 ABNF 暗示的更宽容地接受输入。

一些规范开始承认 ABNF 的理想化性质，并指定包含错误处理的显式解析算法。当指定时，应严格遵循这些算法，以确保互操作性。

安全考虑

自从 RFC3552 以来，RFC 样板中包含了“Security Considerations (安全考虑)”部分。

因此，很少有 RFC 在没有大量安全部分的情况下发布；审查过程不允许草案仅仅说“该协议没有安全考虑”。

所以，无论你是在实现还是部署协议，都值得阅读并确保理解安全考虑部分；如果你不这样做，很可能会在未来的某个时候遇到问题。

跟随其引用（如果有的话）也是一个好主意。如果没有，尝试查找使用的一些术语，以了解所讨论的问题。

了解更多

如果 RFC 没有回答你的问题，或者你不确定其文本的意图，最好的做法是找到最相关的工作组，并在他们的邮件列表中提问。如果没有活跃的工作组覆盖相关主题，尝试适当的领域的邮件列表。

提交勘误通常不是你应该采取的第一步——先和某人谈谈。

许多工作组现在使用 Github 来管理他们的规范；如果你对一个活跃的规范有问题，可以提出一个问题。如果它已经是 RFC，通常最好使用邮件列表，除非你找到相反的指示。

我相信还有更多关于如何阅读 RFC 的内容可以写，有些人会质疑我在这里写的内容，但这是我对它们的看法。希望它对你有用。

←Back to home

This work is licensed under CC BY-NC-SA 4.0