[译] 如何阅读 RFC 文档

栏目: IT资讯 · 发布时间: 5年前

内容简介：原文：作者：译者：西楼听雨

作者： Mark Nottingham 发表时间 ：31 July 2018

译者：西楼听雨 发表时间： 2018/11/19 ( 转载请注明出处 )

For better or worse, Requests for Comments (RFCs) are how we specify many protocols on the Internet. These documents are alternatively treated as holy texts by developers who parse them for hidden meanings, then shunned as irrelevant because they can’t be understood. This often leads to frustration and – more significantly – interoperability and security issues.

不论好坏，互联网上的许多协议都是通过 Requests for Comments (RFC) 来规范的。开发人员在分析这些文本的含义时会把其看成像圣经一样，然后就会刻意回避，因为他们无法理解这些文本。这样常常就会产生挫败感，更严重的是会出现交流障碍和安全性问题。

However, with some insight into how they’re constructed and published, it’s a bit easier to understand what you’re looking at. Here’s my take, informed from my experiences with HTTP and a fewother things.

虽然如此，如果对他们的构建和发布方式进行一定了解的话，其实要理解你所看到的东西也是比较容易的。下面就是我的心得，主要来自我在 HTTP 和其他一些东西上的经验。

从什么地方开始

The canonical place to find RFCs is theRFC Editor Web Site. However, as we’ll see below, some key information is missing there, so most people usetools.ietf.org.

找寻 RFC 规范，权威的渠道就是RFC Editor 网站。但就像下面我们会将看到的那样，这个网站缺失了一些信息，所以大多数人会选择使用tools.ietf.org。

Even finding the right RFC can be difficult since there are so many (currently, nearly 9,000!). Obviously you can find them with general Web search engines, and the RFC Editor has an excellent search facility on their site.

因为 RFC 文档量多（目前接近9000！），所以要找到所需的 RFC 是比较困难的。不过你当然可以通过网络搜索引擎来找寻，以及 RFC Editor 网站的搜索设施来找寻。

Another option isEveryRFC, which I put together to allow searching RFCs by their titles and keywords, and exploration by tags.

另外一种途径是EveryRFC 网站，这个网站允许你通过 RFC 的标题和关键字来查找，以及通过标签分类来导航。

It’s no secret that plain text RFCs are difficult to read bordering on ugly, but things are about to improve; the RFC Editor is wrapping up anew RFC format, with much more pleasing presentation and the option for customisation. In the meantime, if you want more usable RFCs, you can use third-party repositories for selected ones; for example,greenbytes keeps a list of WebDAV-related RFCs, and theHTTP Working Group maintains a selection of those related to HTTP.

大家都知道阅读近乎丑陋的纯文本 RFC 是比较困难，不过幸好事情正在好转——RFC Editor 网站正在用一种新的 RFC 格式来进行包装，这种新的格式的展示方式更加令人舒服，并提供了自定义的选项。另外，如果你想找到更有用的 RFC ，可以使用第三方的仓库；例如，greenbytes 上就保有一份 WebDAV 相关的 RFC 列表，HTTP Working Group 也维护了一份 HTTP 相关的文档。

RFC 的类型是什么？

All RFCs have a banner at the top that looks something like this:

所有 RFC 文档的顶部都有一块“横幅”，类似下面这样：

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
复制代码

At the top left, this one says “Internet Engineering Task Force (IETF)”. That indicates that this is a product of the IETF; although it’s not widely known, there are other ways to publish an RFC that don’t require IETF consensus; for example, theindependent stream.

最顶部的左侧，写着“Internet Engineering Task Force (IETF) ”，意思是说这是 IETF (因特网工程任务组) 组织的作品。虽然不广为人知，但其实除此之外还有其他的方式可以发布一份 RFC，例如，独立发布流。

In fact, there are a number of “streams” that a document can be published on. Only the IETF stream indicates that the entire IETF has reviewed and has declared consensus on a protocol’s specification .

其实还有许多的“发布流”。只有 IETF 的发布流才表示 IETF 组织对该协议的规范进行了审核并达成了共识。

Older documents (before about RFC5705) say “Network Working Group” there, so you have to dig a bit more to find out whether they represent IETF consensus; look at the “Status of this Memo” section for a start, as well as theRFC Editor site.

年代较远的文档（RFC5705之前的那些）写着的是“Network Working Group”，所以你需要更一步发掘看看是否他们代表了 IETF 的共识；关于这一点，我们可以把“Status of this Memo”作为切入点，还有RFC Editor 网站。

Under that is the “Request for Comments” number. If it says “Internet-Draft” instead, it’s not an RFC ; it’s just a proposal, and anyone can write one. Just because something is an Internet-Draft doesn’t mean it’ll ever be adopted by the IETF.

再接着往下则是“Request for Comments”编号。如果这一栏写着“Internet-Draft”，则表示这个文档并不是一个 RFC 文档，它只是一份提议而已，任何人都可以写一份，因为 Internet-Draft 并不意味着它已经被 IETF 所采用。

Categoryis one of “Standards Track”, “Informational”, “Experimental”, or “Best Current Practice”. The distinctions between these are sometimes fuzzy, but if it’s produced by the IETF (see above), it’s had a reasonable amount of review. However, note that Informational and Experimental are not standards, even if there’s IETF consensus to publish.

Category（目录）分为“Standard Track”（标准）、“Informational”（信息性的）、“Experimental”（实验性的）、“Best Current Practice”（当前最佳实践）。它们之间的区别有时候比较模糊，但可以确信的是，如果是由 IETF 制作的，肯定经过了大量的审核。不过要注意，Informational 和 Experiment 并不属于标准，即便是经过 IETF 批准发布的。

Finally, the authors of the document are listed on the right side of the header. Unlike in academia, this is not a comprehensive list of who contributed to the document; often, that’s done near the bottom in an “Acknowledgments” section. In RFCs, this is literally “who wrote the document.” Often, you’ll see “Ed.” appended, which indicates that they were acting as an editor, often because the text was pre-existing (like when an RFC is revised).

最后，列在“横幅”右边的是这个文档的作者。和学术文章不一样，这个列表列出的并不是对这份文档做出了贡献的人员列表，在 RFC 中，这块信息位于文档尾部的“Acknowledgets (鸣谢)”一节；在 RFC 中，表示的只是“文档是谁写的”。

如何确定是否为最新版本？

RFCs are an archival series of documents; they can’t change, even by one character (see the diff between RFC7158 and RFC7159 for an example of this taken to the extreme; they got the year wrong ;).

RFC 是一种存档性质的系列文档，确定了就不能变动，哪怕只是一个字符（见 RFC7158 和 RFC7159 之前的比较这个极端的例子——他们把年份搞错了）。

As a result, it’s important to know that you’re looking at the right document. The header contains a couple of bits of metadata that help here:

所以，知道你现在正在查看的是否找对了是非常重要的。这一点从文档的顶部所包含的一些元信息中可以获得一些帮助：

Obsoletes: lists the RFCs that this document completely replaces; i.e., you should be using this document, not that one. Note that an old version of a protocol isn’t necessarily obsoleted when a newer one comes out; for example, HTTP/2 doesn’t obsolete HTTP/1.1, because it’s still legitimate (and necessary) to implement the older protocol. However, RFC7230 did obsolete RFC2616, because it’s the reference for that protocol.

列出了被这个文档所彻底取代的 RFC 。它说的是，你应该使用当前的这个文档，而不是这些。注意：老版本的协议不一定就会被新版本的取代；例如，HTTP/2 并没有淘汰 HTTP/1.1，因为它仍然是合法的（且是必要的），不过 RFC7230 淘汰了 RFC2616，因为他是那个协议的一个引用。
Updates：lists the RFCs that this document makes substantive changes to; in other words, if you’re reading that other document, you should probably read this one too.

列出了被这个文档实质性更新到的 RFC。意思就是说，如果你阅读这些文档，那么同时也应该阅读这个。

Unfortunately, the ASCII text RFCs (e.g., at the RFC Editor site) don’t tell you what documents update or obsolete the document you’re currently looking at. This is why most people use the RFC repository attools.ietf.org, which puts this information in abanner like this:

不过遗憾的时，RFC 的纯文本展示版本（如 RFC Editor 网站上的文档）不会给出哪些文档对你正在阅读的这个文档造成了更新或者淘汰。这也是为什么许多人宁愿使用tools.ietf.org 网站上的 RFC 文档库，因为它会在文档顶部给出这块信息，就像这样：

[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
复制代码

Each of the numbers on the tools page is a link, so you can easily find the current document.

上面这些数字都是一个链接，所以你可以轻易找到目前最新的文档。

Even the most current RFC often has issues. In the tools banner, you’ll also see a warning on the right that “Errata Exist” along with a link to Errata above it.

即便是最新的 RFC 文档也常存在错漏，所以在这个工具栏的右侧你还可以看到一个“Errata Exsit (存在勘误)”的字样，在其上面则是关于勘误信息的链接。

Errataare corrections and clarifications to the document that aren’t worthy of publishing a new RFC. Sometimes they can have a substantial impact on how the RFC is implemented (for example, if a bug in the spec led to a significant misinterpretation), so they’re worth going through.

Errata是一些关于这个文档的纠正和澄清，但还没到值得重新发布一个新的 RFC 的程度。不过有个时候他们会对 RFC 规范的实现造成一定影响（例如，这个规范中存在一个 bug，就会产生严重的误解），所以这还是值得一览的。

For example, here are theerrata for RFC7230. When reading errata, keep their status in mind; many are rejected because someone just misread the spec.

举个例子，这是 RFC7230 的勘误列表。在阅读时要留意他们的状态，许多的没被采纳的其实是因为人们的误解。

理解上下文

It’s more common than you might think for a developer to look at a statement in an RFC, implement what they see, and do the opposite of what the authors intended.

开发人员在查看了 RFC 中的某条语句后，在实现他们所看到的时，违背规范作者的用意的情况，会比你想象的还要普遍。

This is because it’s extremely difficult to write a specification in a manner that can’t be misinterpreted when reading it selectively (as is the case with any holy text).

这是因为要写出一份在选择性阅读的情况下不会产生误解的规范是极端困难的（就像任何圣经中的语句一样）。

As a result, it’s necessary to read not only the directly relevant text but also (at a minimum) anything that it references, whether that’s in the same spec or a different one. In a pinch, reading any potentially related sections will help immensely, if you can’t read the whole document.

因此，不只是要阅读直接相关的那些文本，还要阅读它所引用的文本，不管引用的是规范之内的，还是其他规范的。在比较赶的情况下，如果不能把整个文档读一遍，那么把那些可能相关的段落都阅读一遍会有极大的帮助。

For example, HTTP message headers aredefined to be separated by CRLF, but if you skip downhere, you’ll see that “a recipient MAY recognize a single LF as a line terminator and ignore any preceding CR.” Obvious, right?

例如，HTTP 的消息头定义中使用的是以 CRLF 进行分割，但如果往下看到这的话，你会看到“a recipient MAY recognize a single LF as a line terminator and ignore any preceding CR.（接收方可以用单个 LF 字符作为行结束符并忽略紧接在它之前的 CR）”这样一句话，显然这也是对的？

It’s also important to keep in mind that many protocols set upIANA registries to manage their extension points; these, not the specifications, are the sources of truth. For example, the canonical list of HTTP methods is inthis registry, not any of the HTTP specifications.

另外一个也比较重要的点是，许多协议都设有 IANA 注册表用于管理他们本身的可扩展点，这些才是实际的事实，而不是规范文档。例如，HTTP 方法列表的权威位于这个注册表中，而不是什么 HTTP 规范。

解读规则文本

Almost all RFCs have boilerplate that looks something like this near the top:

几乎所有 RFC 文档的顶部附近都有一段像下面这样的模板式文本：

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
复制代码

TheseRFC2119 keywords help define interoperability, but they also sometimes confuse developers. It’s very common to see a specification say something like:

RFC2119 定义的这些关键字有助于交流，但有时候也会给开发人员带来困惑。经常会在规范中看到下面这样的话：

The Foo message MUST NOT contain a Bar header.
Foo 消息**一定**不能包含 Bar 消息头。
复制代码

This requirement is placed upon a protocol artefact, the” Foo message”. If you’re sending one, it’s pretty clear it needs to not contain a Bar header; if you include one, it won’t be a conformant message.

这个要求描述的是协议中的一条消息，即“Foo 消息”。如果你发要出这样一条消息，它说的很明确，不需要包含 Bar 消息头；如果你包含了，那就不是一条符合规范的消息。

However, the behaviour of the recipient is much less clear; if you see a Foo message with a Bar header, what do you do?

不过，对于消息的接收方来说，它就没有明确说明；假如你收到了一条带有 Bar 消息头的 Foo 消息，你该怎么做呢？

Some developers will reject a message that contains it, even though the specification says nothing about doing so. Others will still process the message, but strip the Bar header, or ignore it – even when the spec explicitly says that all headers need to be processed.

某些开发人员会选择拒绝这样一条消息——虽然规范文档中没有对该采取什么动作有明确规定；另外一些开发人员则会选择继续处理这条消息，但会先把 Bar 消息头剔除掉，或者忽视掉——即便规范文档明确说明了所有的消息头都需要进行处理。

All of these things can – unintentionally – cause interoperability issues. The correct thing to do is to follow normal processing for the header unless there’s a specific requirement to the contrary.

以上所述的这些就可能造成预料之外的消息交流问题。正确的做法应该是遵循正常的消息头处理规则，除非规范中有特别说明。

That’s because in general, specifications are written so that behaviours are overtly specified; in other words, everything that is not explicitly disallowed is allowed. Therefore, reading too much into specifications can unintentionally cause harm, since you’ll be introducing new behaviours that others will have to work around.

这是因为，规范定义的比较宽泛的话，行为就会比较宽泛；言外之意就是说，所有没有明确说明不允许做的事情都是允许的。因此，越是对规范解读的过多就越可能发生意外的影响，因为这样你会倾向于引入更多的行为，而这样其他人就需要想办法避开这些行为。

In an ideal world, the specification would be defined in terms of the behaviours of those who handle the message, like this:

理想而情况是，规范为文档在做定义时都是以处理这些消息的人的行为角度来的，就像这样：

Senders of the Foo message MUST NOT include a Bar header. Recipients
of a Foo message that includes a Bar header MUST ignore the Bar header,
but MUST NOT remove it.
Foo 消息的发送者**一定**不能包含 Bar 消息头；接收到一条包含 Bar 消息头的 Foo 消息的接受者**一定**要忽略掉 Bar 消息头，但**一定**不能剔除它。
复制代码

Absent that, it’s best to look for more general advice about error handling elsewhere in the specification (e.g., HTTP’s Conformance and Error Handling section).

如果不是这样描述的的话，最好是查看一下规范中关于错误处理的更宽泛的建议（例如，HTTP 规范的“ Conformance and Error Handling 行为规范及异常处理”一节）

Also, keep in mind the target of requirements; most specifications have a highly developed set of terms that they use to distinguish between different roles in the protocol.

另外，始终要记住规则所规定的要求；许多规范都有一套精心制作的术语，这些术语可以很好地界定协议中不同角色的职责。

For example, HTTP hasproxies, which are a kind of intermediary, which implement both a client and a server (but not a User-Agent or an origin server); they need to pay attention to requirements targeted at all of those roles.

例如 HTTP 的代理，这是一种中间层，既充当客户端又充当服务端（但并不真的是一个 User-Agent (用户代理) 和源头服务器），需要关注所有这两种角色的规则要求。

Likewise, HTTP distinguishes between “generating” a message and merely “forwarding” it in some requirements, depending on the specific situation. Paying attention to this kind of specific terminology can save you a lot of guesswork.

同样，HTTP 协议是一些规则中视情况使用“generating (生成)” 一条消息或者“forwarding (转发)”消息，对它们做出清晰的界定。对这类特定的术语多关注点可以节省你许多的猜测时间。

SHOULD

Yep, SHOULD deserves its own section. This wishy-washy term plagues many RFCs, despite efforts to eradicate it. RFC2119 describes it as:

对的，SHOULD 值得用一个章节来写。这个“不清不楚”的词给许多 RFC 文档带来了“瘟疫”——尽管有尝试根除它。RFC2119 中是这样描述它的：

SHOULD  This word, or the adjective "RECOMMENDED", mean that there
        may exist valid reasons in particular circumstances to ignore a
        particular item, but the full implications must be understood and
        carefully weighed before choosing a different course.
复制代码

In practice, authors often use SHOULD and SHOULD NOT to mean “We’d like you to do this, but we know we can’t always require it.”

实际情况是，作者们偏爱使用 SHOULD 和 SHOULD NOT 的来表述“我们希望你这样做，但我们知道我们不能总要求你这样做”这样的意思。

For example, in the overview of HTTP methods , we see:

例如，在HTTP 请求方法概览一节中我们可以看到：

When a request method is received that is unrecognized or not
implemented by an origin server, the origin server SHOULD respond
with the 501 (Not Implemented) status code. When a request method
is received that is known by an origin server but not allowed for
the target resource, the origin server SHOULD respond with the 405
(Method Not Allowed) status code.
当服务器接收到一条无法识别或者未实现支持的请求方法时，服务器**应该**用 501 (Not Implementd 未实现) 状态码予以回应。当服务器接收到一条的请求方法，但其请求的目标资源不被允许访问时，服务器**应该**用 405 (Method Not Allowed 方法不被允许) 状态码予以回应。
复制代码

These SHOULDs are not MUSTs because the server might reasonably decide to take another action; if the request is from a client that is believed to be an attacker, it might drop the connection, or if HTTP authentication is required for the resource, it might enforce that with a 401 (Not Authenticated) before getting to the 405.

这段文本中的这些 SHOULD 并不是 MUST，因为服务器某些情况下有合理原因采取其他动作，例如，如果某条请求可以被确信是来自某个攻击者时，服务器可能会丢弃这条通讯连接；又或者，如果所请求的资源需要有认证，那么服务器可能会在到达 405 之前就强制回应 401 (Not Authenticated 未认证）。

SHOULD doesn’t mean that the server is free to ignore a requirement because it doesn’t feel like honouring it.

SHOULD 也并不表示如果服务器不喜欢就可以随意忽视规则的要求。

Sometimes, wesee a SHOULD that follows this form:

有时候，我们可以看到这样使用 SHOULD 的文本形式：

A sender that generates a message containing a payload body SHOULD
generate a Content-Type header field in that message unless the
intended media type of the enclosed representation is unknown to
the sender.
发送者在生成一条含有消息体的消息时，**应该**同时生成一个 Content-Type 头字段，除非发送者无法得知所发送的消息部分所属的整体消息的媒体类型。
复制代码

Notice the “unless” – it’s specifying the “particular circumstances” that the SHOULD allows. Arguably this could be specified as a MUST, since the unless clause would still apply, but this style of specification is somewhat common.

留意上面提到的“unless (除非)”一词——它指出了 SHOULD 所允许的特定条件。在这里，其实也可以使用 MUST 来表述，因为还有 unless 限制条件，但使用 SHUOLD 的会稍微通用点。

阅读示例

Another very common pitfall is to skim the specification for examples, and implement what they do.

在翻阅规范文档中示例以及示例所要实现的东西时，有一个坑需要注意。

Unfortunately, examples typically get the least amount of attention from authors, since they need to be updated with each change to the protocol.

因为有一个不好的事实就是，示例通常是作者给予关注度最小的，因为它们需要与协议的每次变动保持同步。

As a result, they’re very often the least reliable parts of the spec. Yes, the authors should absolutely double-check the examples before publication, but errors do slip through.

这样的结果就是，它们成为了规范中最不可靠的部分。对，规范的作者是应该在发布前对示例进行复核，但这并不代表不会存在漏洞。

Also, even a perfect example might not be intended to illustrate the aspect of the protocol you’re looking for; they’re often truncated for brevity, or shown after an decoding step takes place.

另外，即便某个示例比较完美，它所要展示的关于协议的某个方面也可能并不是你所要寻找的；这些示例通常为了简洁都会都被精简过，或者是展示的只是解码步骤之后的。

Even though it takes more time, it’s better to read the actual text; examples are not the specification.

所以，即便会耗费更多时间，也一定要看看文字部分——示例并不是规范。

On ABNF

Augmented BNF is often used to define protocol artefacts. For example:

协议中的内容通常使用的是增强的 BNF 范式来表示。例如：

FooHeader = 1#foo
foo       = 1*9DIGIT [ ";" "bar" ]
复制代码

Once you get used to it, ABNF offers an easy-to-understand sketch of what protocol elements should look like.

一旦你习惯了 ABNF，你会很容易理解协议中元素的应该会是什么样子。

However, ABNF is “aspirational” - it identifies an ideal form for a message, and those messages that you generate really need to match it. It doesn’t specify what to do with received messages that fail to match it. In fact, many specifications fail to say what the relationship of ABNF is to processing requirements at all .

ABNF 为消息提供了一种理想的表达形式，你生成一条消息时需要满足它的规则，但他并没有指定当收到一条不满足规则的消息时如何处理的过程。其实，许多规范都没能说清 ABNF 的角色其实是描述规则要求的处理过程的。

Most protocols will fail badly if you try to enforce their ABNF strictly, but sometimes it matters. In the example above, whitespace isn’t allowed around the semicolon, but you can bet that some people will put it there, and some implementations will accept it.

如果你严格执行 ABNF 的规则，许多协议会达不到要求，但有时候这样反而是好事。在上面的这个例子中，空白字符是不允许出现在分号前后的，但你可以确信有些人就是会在这里放置空白字符，而有些规则的实现方也会接受这种情况。

So, make sure you read the text around the ABNF for additional requirements or context, and realise that absent a direct requirement, you may have to adjust parsing to be more accepting of input than the ABNF implies.

所以，考虑到上下文及额外的规则要求，一定要看看 ABNF 前后的文本，并形成一种意识——你可能得在解析消息时放松 ABNF 的要求。

Some specifications are starting to acknowledge the aspirational nature of ABNF and specifying explicit parsing algorithms that incorporate error handling. When specified, these should be followed exactly, to ensure interoperability.

有些规范文档会更大强度地采取 ABNF 的强大性，并显式地指明解析的算法和发生错误时的处理。当出现这样的情况，你应该严格遵守，以确保交流性。

安全问题

Ever sinceRFC3552, the RFC boilerplate has included a “Security Considerations” section.

自RFC3552 发布之后，RFC 的模板就开始出现“安全考虑（Security Considerations）”章节。

As a result, it’s rare for an RFC to be published without a substantial section on security; the review process does not allow a draft to just say “There are no security considerations for this protocol”.

结果就是，之后的 RFC 很少出现没有关于安全的章节的；在审核的过程中也不会允许一个草案文件直接说“该协议不需要考虑安全性方面的问题”

So, it pays to read and make sure you understand the Security Considerations section, whether you’re implementing or deploying the protocol; if you don’t, it’s very likely that something will bite you down the road.

所以，你需要付出精力阅读一下“Security Considerations”一节——不管是在实现还是部署这个协议；如果你不这样做，很可能你会因此而“翻车”。

Following its references (if any) is also a good idea. If there aren’t any, try looking up some of the terms used to get an appreciation of the issues being discussed.

跟随它里面的引用（如果有的话）也是一个好习惯。If there aren’t any, try looking up some of the terms used to get an appreciation of the issues being discussed.