【RFC7414 传输控制协议 (TCP) 规范文档的路线图】（翻译）

原文 rfc7414 (ietf.org)   A Roadmap for Transmission Control Protocol (TCP) Specification Documents  传输控制协议 (TCP) 规范文档的路线图 

概述

本文档包含与 Internet 的传输控制协议 (TCP) 相关的征求意见 (RFC) 文档的路线图。 该路线图提供了定义 TCP 和各种 TCP 扩展的文档的简要摘要，这些文档在 RFC 系列中积累。 这可以作为 TCP 实施者和其他需要包含在 TCP 相关 RFC 中的信息的各方的指南和快速参考。

本文档废弃了 RFC 4614。

目录

   1. 简介
   2. 核心功能
   3. 强烈鼓励的改进
      3.1.根本性变化
      3.2.拥塞控制扩展
      3.3.丢失恢复扩展
      3.4.虚假重传的检测和预防
      3.5.路径 MTU 发现
      3.6.头部压缩
      3.7.防御欺骗和洪水攻击
   4. 实验扩展
      4.1.架构指南
      4.2.根本性变化
      4.3.拥塞控制扩展
      4.4.丢失恢复扩展
      4.5.虚假重传的检测和预防
      4.6.TCP 超时
      4.7.多路径 TCP
   5. IANA 的 TCP 参数
   6. 历史和未部署的扩展
   7. 支持文档
      7.1.基础工作
      7.2.架构指南
      7.3.困难的网络环境
      7.4.开发、分析和评估 TCP 的指南
      7.5.实施建议
      7.6.工具和教程
      7.7.MIB 模块
      7.8.实例探究
   8. 未公开的 TCP 特性
   9. 安全考虑
   10. 参考文献
      10.1.规范参考
      10.2.参考资料
   致谢
   作者地址

1. 简介

正确有效地实现传输控制协议 (TCP) 是大多数 Internet 主机软件的关键部分。随着 TCP 多年来的发展，许多不同的文档已成为 TCP 公认标准的一部分。同时，RFC 系列中还发布了大量对 TCP 的实验性修改，以及信息说明、案例研究和其他建议。

作为对新手的介绍和为老手组织大量信息的尝试，本文档包含与 TCP 相关的 RFC 的路线图。它提供了定义 TCP 的 RFC 文档的简要摘要。这应该就与 TCP 相关的标准跟踪扩展、信息说明和最佳当前实践的相关性和重要性向实施者提供指导。

本文档不是 RFC 1122 [RFC1122] 的更新，也不是 TCP 需要实现的严格标准。本文档只是一个信息路线图，它捕获、组织和总结了 TCP 实施者、实验者或学生应该了解的大多数 RFC 文档。本文档对个别机制和行为的具体评论或广泛分类不应被视为确定性的，本文档的内容也不应单独影响实施决策。

该路线图包括对每个 TCP 相关 RFC 内容的简要说明。在某些情况下，我们只是提供文本中的摘要或关键摘要句子作为简洁的描述。此外，RFC 编号后面的字母代码表示其在 RFC 系列中的类别（有关这些类别的解释，请参阅 BCP 9 [RFC2026]）：

   S - 标准跟踪（提议标准、标准草案或互联网标准）
   E - 实验性
   I - 信息性
   H - 历史的
   B - 当前最佳实践
   U - 未知（未正式定义）

请注意，RFC 的类别不一定反映其当前的相关性。例如，RFC 5681 [RFC5681] 被认为是 TCP 所需核心功能的一部分，尽管 RFC 只是一个草案标准。类似地，一些信息性 RFC 包含用于更改 TCP 的重要技术建议。

最后，如果在 RFC 发布后（在撰写本文时）发现技术内容中的错误，则该事实由 RFC 描述标题中的术语“（勘误表）”表示。勘误的内容可以通过RFC勘误页面[勘误]找到。

该路线图分为三个主要部分。第 2 节列出了 RFC，这些 RFC 描述了正确运行和互操作性所必需的 TCP 行为。第 3 节列出了描述强烈鼓励但非必要的行为的更多 RFC。第 4 节描述了尚未成为标准实践但可能在未来成为标准实践的实验性扩展。

读者可能会注意到，这三个部分大致等同于 MUST/SHOULD/MAY 规范（根据 RFC 2119 [RFC2119]），尽管作者支持这种直觉，但本文档只是描述性的；它不代表具有约束力的标准跟踪位置。个别实施者仍然需要自己检查标准跟踪 RFC 以评估特定的需求级别。

第 5 节描述了 Internet 编号分配机构 (IANA) 使用的程序和 RFC 作者在请求和最终分配新 TCP 参数时应遵循的程序。

第 6 节指出了少数尚未广泛实施、部署和使用的较旧的实验性扩展。第 7 节描述了许多其他与 TCP 的开发、实施和部署相关的支持文档。

第 8 节列出了少数相当普遍的重要实现实践，这些实践目前没有记录在 RFC 系列中。

在每个部分中，RFC 都按其发布日期的时间顺序列出。

2. 核心功能

少数文档构成了 TCP 的核心规范。这些定义了 TCP 报头解析、状态机、拥塞控制和重传超时计算所需的核心功能。为了互操作性，必须正确遵循这些基本规范。

RFC 793 S：“传输控制协议”，STD 7（1981 年 9 月）（勘误表）

这是基本的 TCP 规范文档 [RFC793]。作为 Internet 协议套件核心的一部分，由 Jon Postel 编写，它描述了 TCP 数据包格式、TCP 状态机和事件处理，以及 TCP 的数据传输、可靠性、流量控制、多路复用和确认的语义。

RFC 793 的第 3.6 节描述了 TCP 对 IP 优先级和安全隔间的处理，在今天几乎不相关。
RFC 2873（稍后在下面的第 2 节中讨论）更改了 IP 优先级处理，并且不再实施或使用 API 的安全隔间部分。此外，RFC 793 没有描述任何拥塞控制机制。然而，除此之外，该文档的大部分内容仍然准确地描述了现代 TCP。 RFC 793 是一系列发展中的 TCP 规范中的最后一个，从 Internet 实验说明 (IEN) 开始并在 RFC 系列中继续。

RFC 1122 S：“Internet 主机要求 - 通信层”（1989 年 10 月）

本文档 [RFC1122] 更新并澄清了 RFC 793（见上文第 2 节），修复了一些规范错误和疏忽。它还解释了一些特性，例如 keep-alives 和 Karn's and Jacobson's 的 RTO 估计算法 [KP87][Jac88][JK92]。提到了 ICMP 交互，并给出了一些有效实施的技巧。 RFC 1122 是一个适用性声明，列出了在符合标准的 TCP 实现中必须、应该、可以、不应该和不得出现的各种特性。与纯粹的信息路线图不同，本适用性声明是一份标准文件，并给出了正式的实施规则。

RFC 2460 S：“Internet 协议，版本 6 (IPv6) 规范”（1998 年 12 月）（勘误表）

本文档 [RFC2460] 与 TCP 相关，因为它定义了当使用 128 位 IPv6 地址而不是 32 位 IPv4 地址时，如何导出 TCP 校验和计算的伪头部。此外，RFC 2675（请参阅本文档的第 3.1 节）描述了支持 IPv6 跳转图所需的 TCP 更改。

RFC 2873 S：“IPv4 优先级字段的 TCP 处理”（2000 年 6 月）（勘误表）

本文档 [RFC2873] 从 TCP 规范中删除了对 IP 报头的 TOS 字节的优先位的所有处理。这解决了 RFC 793（见上文第 2 节）和差分服务 [RFC2474] 之间使用这些位的冲突。

RFC 5681 S：“TCP 拥塞控制”（2009 年 8 月）

尽管 RFC 793（见上文第 2 节）不包含任何拥塞控制机制，但如今拥塞控制是 TCP 实现的必需组件。本文档 [RFC5681] 基于 Van Jacobson 1988 年的 SIGCOMM 论文 [Jac88]，定义了 TCP 的拥塞避免和控制机制。

RFC 5681 中描述了共同构成社区所称的“Reno TCP”的许多行为。名称“Reno”来自 4.3 BSD 操作系统的 Net/2 版本。这通常被认为是目前在 Internet 主机上运行的 TCP 风格中最不常见的。 Reno TCP 包含慢启动、拥塞避免、快速重传和快速恢复的拥塞控制特性。

RFC 5681 详细说明了当前接受的拥塞控制机制，而 RFC 1122（见上文第 2 节）要求必须实施此类拥塞控制机制。 RFC 5681 与本节中列出的其他文档略有不同，因为它不影响两个 TCP 端点的通信能力；然而，拥塞控制仍然是任何广泛部署的 TCP 实现的关键组成部分，并且是避免拥塞崩溃和确保竞争流之间的公平所必需的。

RFC 2001 和 2581 是 RFC 5681 的概念先驱。与 RFC 2581 相关的最重要的变化是：

      (a) 初始窗口要求已更改，以允许 [RFC3390] 中标准化的更大的初始窗口（参见本文档的第 3.2 节）。
      (b) 在慢启动和拥塞避免期间，明确推荐使用适当的字节计数 [RFC3465]（参见本文档的第 3.2 节）。
      (c) 现在推荐使用有限传输 [RFC3042]（参见本文档的第 3.3 节）。

RFC 6093 S：“关于 TCP 紧急机制的实施”（2011 年 1 月）

本文档 [RFC6093] 分析了当前 TCP 堆栈如何处理 TCP 紧急指示，以及广泛部署的中间盒的行为如何影响紧急指示处理。该文件更新了相关规范，以适应当前处理 TCP 紧急指示的做法。最后，该文件提高了对 Internet 中 TCP 紧急指示可靠性的认识，并建议不要使用紧急机制。

RFC 6298 S：“计算 TCP 的重传计时器”（2011 年 6 月）

RFC 6298 [RFC6298] 摘要：“本文档定义了传输控制协议 (TCP) 发送方用于计算和管理其重传计时器的标准算法。它扩展了 RFC 1122 的第 4.2.3.1 节中的讨论并进行了升级支持算法从应该到必须的要求。” RFC 6298 通过将初始 RTO 从 3s 更改为 1s 来更新 RFC 2988。

RFC 6691 I：“TCP 选项和最大分段大小 (MSS)”（2012 年 7 月）

本文档 [RFC6691] 阐明了在使用 IP 和 TCP 选项时与 TCP 最大分段大小 (MSS) 选项一起使用的值。

3. 强烈鼓励的改进

本节介绍了改进性能和安全性的推荐的TCP 修改。第 3.1 节表示协议的根本变化。第 3.2 节和第 3.3 节列出了对 RFC5681 中指定的拥塞控制和丢失恢复机制的改进（参见第 2 节）。 3.4 节描述了允许 TCP 发送方检测它是否已虚假地进入丢失恢复的算法。

3.5 节包括路径 MTU 发现机制。 3.6 节列出了 TCP/IP 报头压缩方案。最后，第 3.7 节处理防止接受伪造段和泛洪攻击的问题。

3.1.根本性变化

RFC 2675 和 7323 通过重新定义基本 TCP 头部和选项部分的解释方式，代表了 TCP 的根本变化。 RFC7323 定义了 Window Scale 选项，它重新解释了通告的接收窗口。 RFC 2675 指定要特别处理值为 65,535 的 MSS 选项和紧急指针字段。

RFC 2675 S：“IPv6 跳转图”（1999 年 8 月）（勘误表）

IPv6 支持比 IPv4 允许的更长的数据报。这些被称为跳转图，与 TCP 一起使用需要更改 TCP 的 MSS 和紧急字段（均为 16 位）的处理。本文档 [RFC2675] 解释了这些更改。尽管它描述了对基本报头语义的更改，但这些更改应该只影响非常大的段的使用，例如 IPv6 跳转图，目前在一般 Internet 中很少使用。

当使用 IPv4 或非跳转 IPv6 时，支持本文档中描述的行为不会影响与其他 TCP 实现的互操作性。本文档规定，只有在可以保证所有接收节点（包括端到端路径中的每个路由器）都支持跳转图时，才使用跳转图。如果即使是不支持跳转图的单个节点连接到本地网络，则该网络上的任何主机都不能使用跳转图。这解释了为什么跳转图很少使用，以及为什么本文档被视为性能优化而不是 TCP over IPv6 基本功能的一部分。

RFC 7323 S：“高性能 TCP 扩展”（2014 年 9 月）

本文档 [RFC7323] 定义了用于窗口缩放、时间戳和防止包装序列号的 TCP 扩展，以便在具有大带宽延迟产品的路径上进行高效和安全的操作。这些扩展在当前使用的系统中很常见。本文档的前身 RFC 1323 于 1992 年发布，并部署在大多数 TCP 实现中。
本文档包括基于获得的部署经验的修复和说明。本规范中解决的一个特定问题是建议如何修改用于在使用时间戳时估计平均 RTT 的算法。 RFC 1072、1185 和 1323 是 RFC 7323 的概念先驱。

3.2.拥塞控制扩展

TCP 最重要的两个方面是其拥塞控制和丢失恢复功能。 TCP 将丢失的数据包视为表示与拥塞相关的丢失，并且无法区分与拥塞相关的丢失和由于传输错误导致的丢失。即使在使用 ECN 时，拥塞控制和丢失恢复机制之间也存在相当密切的耦合。这两个功能都有几个扩展，而且通常情况下，一个特定的扩展同时适用于这两个功能。在这两个小节中，我们对 TCP 的拥塞控制的增强进行了分组，而下一个小节则侧重于 TCP 的丢失恢复。

RFC 3168 S：“将显式拥塞通知 (ECN) 添加到 IP”（2001 年 9 月）

本文档 [RFC3168] 定义了一种让终端主机在拥塞的路由器被迫丢弃数据包之前检测拥塞的方法。
尽管拥塞通知发生在 IP 级别，但 ECN 需要传输级别的支持（例如，在 TCP 中）以回显比特并调整发送速率。本文档更新了 RFC 793（请参阅本文档的第 2 节）以在 TCP 头部中定义两个以前未使用的标志位以支持 ECN。 RFC 3540（参见本文档的第 4.3 节）为更安全地使用 ECN 提供了补充（实验）方法，RFC 2884（参见本文档的第 7.8 节）提供了使用 ECN 的一些示例结果。

RFC 3390 S：“增加 TCP 的初始窗口”（2002 年 10 月）

本文档 [RFC3390] 规定在慢启动阶段，TCP 的允许初始窗口从一个段增加到三个或四个段，具体取决于段大小。

RFC 3465 E：“具有适当字节计数 (ABC) 的 TCP 拥塞控制”（2003 年 2 月）

本文档 [RFC3465] 建议拥塞控制使用确认的字节数而不是收到的确认数。在数据段和确认（例如，延迟 ACK 或ACK 丢失）并关闭 TCP 接收方可以用来诱导发送方过快增加发送速率的安全漏洞（ACK 划分 [SCWA99] [RFC3449]）。 RFC 5681 推荐使用 ABC（请参阅本文档的第 2 节）。

RFC 6633 S：“ICMP 源淬火消息的弃用”（2012 年 5 月）

本文档 [RFC6633] 正式反对通过传输协议使用 ICMP Source Quench 消息，并建议不要实施 [RFC1016]。

3.3.丢失恢复扩展