【RFC6191 使用 TCP 时间戳减少 TIME-WAIT 状态】（翻译）

本文档描述了一种用于处理传入 SYN 段的算法，当传入 SYN 段中存在 TCP 时间戳选项时，该算法允许任何两个 TCP 端点之间的更高连接建立速率。本文档仅修改了对 TIME-WAIT 状态下的连接接收的 SYN 段的处理；所有其他状态的处理没有变化。

目录

   1. 简介
   2. 改进的对传入连接请求的处理
   3. 与各种时间戳生成算法的交互
   4. 与各种 ISN 生成算法的交互
   5. 安全考虑
   6. 致谢
   7. 参考文献
     7.1.规范参考
     7.2.参考资料
   附录 A. 拟议机制在特定情况下的行为
     A.1.系统重启后的连接请求

1. 简介

RFC 1323 [RFC1323] 中指定的时间戳选项允许 TCP 在其段中包含时间戳值，该值可用于执行两个功能：往返时间​​测量 (RTTM) 和防回绕序列号 (PAWS)。

出于 PAWS 的目的，在连接上发送的时间戳需要单调递增。虽然不要求时间戳在 TCP 连接之间单调增加，但生成时间戳使得它们在相同的两个端点之间的连接之间单调增加允许使用时间戳来改进对接收到的 SYN 段的处理，当相应的四个-tuple 处于 TIME-WAIT 状态。也就是说，时间戳选项可用于执行试探以确定是否允许创建处于 TIME-WAIT 状态的连接的新化身。

TCP 时间戳的这种使用只是出于相同目的使用初始序列号 (ISN) 的一种推断，正如 RFC 1122 [RFC1122] 所允许的那样，并且它已被合并到许多 TCP 实现中，例如包含在Linux 内核 [Linux]。

2. 改进的对传入连接请求的处理

在许多场景中，当相应的四元组在远端 TCP 对等体中仍处于 TIME-WAIT 状态时，可能需要重用套接字对。例如，访问主机上的某些服务的客户端可能会尝试创建先前连接的新化身，而相应的四元组在远端TCP 对等方（服务器）处仍处于 TIME-WAIT 状态。如果临时端口号被重用太快，可能会发生这种情况，要么是因为选择临时端口的策略不正确，要么仅仅是因为到相应服务的连接速率很高。在这种情况下，重用处于 TIME-WAIT 状态的四元组的新连接的建立将失败。这个问题在[INFOCOM-99]中有详细讨论。

为了避免这个问题，RFC 1122 [RFC1122] 的第 4.2.2.13 节规定，当接收到处于 TIME-WAIT 状态的四元组的连接请求时，如果传入的 SYN 段的序列号大于在连接的前一个化身中看到的最后一个序列号（对于数据传输的那个方向），连接请求可能被接受。此要求的目标是防止连接的旧版本和新版本的序列号空间重叠，以便新版本不接受来自旧版本的片段是有效的。

可以将相同的策略外推到 TCP 时间戳。也就是说，当接收到一个四元组处于 TIME-WAIT 状态的连接请求时，如果传入 SYN 段的时间戳大于在前一个化身中看到的最后一个时间戳，则可以接受连接请求（对于数据传输的那个方向）。

以下段落总结了在 TIME-WAIT 状态下为连接接收的 SYN 段的处理。为所有其他状态的连接接收的 SYN 段的处理保持不变。传入 SYN 段的 ISN（初始序列号）和时间戳选项（如果存在）都包含在为允许高连接建立率而执行的试探中。

处理为处于 TIME-WAIT 状态的连接接收的 SYN 段应该如下进行：

o 如果连接的前一个化身使用时间戳，则：

      * 如果 TCP 时间戳将为连接的新化身启用，并且传入 SYN 段中包含的时间戳大于在连接的前一个化身上看到的最后一个时间戳（对于数据传输的那个方向），请遵守连接请求（创建处于 SYN-RECEIVED 状态的连接）。

      * 如果 TCP 时间戳将为连接的新化身启用，传入 SYN 段中包含的时间戳等于在连接的前一个化身上看到的最后一个时间戳（对于数据传输的那个方向），以及传入 SYN 段的序列号大于在连接的前一个化身（对于数据传输的那个方向）上看到的最后一个序列号，接受连接请求（在 SYN-RECEIVED 状态下创建连接）。

      * 如果不会为连接的新化身启用 TCP 时间戳，但传入 SYN 段的序列号大于在连接的前一个化身上看到的最后一个序列号（对于相同的数据传输方向） , 接受连接请求（创建处于 SYN-RECEIVED 状态的连接）。

      * 否则，静默删除传入的 SYN 段，从而使连接的前一个化身处于 TIME-WAIT 状态。

o 如果连接的前一个化身没有使用时间戳，则：

      * 如果要为连接的新化身启用 TCP 时间戳，则接受传入的连接请求（在 SYN-RECEIVED 状态下创建连接）。

     * 如果不会为连接的新化身启用 TCP 时间戳，但传入 SYN 段的序列号大于在连接的前一个化身上看到的最后一个序列号（对于相同的数据传输方向） ，接受传入的连接请求（创建处于 SYN-RECEIVED 状态的连接）。

   * 否则，静默删除传入的 SYN 段，从而使连接的前一个化身处于 TIME-WAIT 状态。

注意：

在上面的解释中，短语“TCP Timestamps would be enabled for the new incarnation for the connection”意味着传入的 SYN 段包含一个 TCP Timestamps 选项（即客户端已启用 TCP Timestamps），并且响应它而发送的SYN/ACK 段也将包含时间戳选项（即，服务器已启用 TCP 时间戳）。在这种情况下，将为连接的新化身启用 TCP 时间戳。

“在连接的前一个化身（用于数据传输的相同方向）上看到的最后一个序列号”是指连接的前一个化身（用于数据传输的相同方向）使用的最后一个序列号，不是在相应段的序列号字段中看到的最后一个值。也就是说，它指的是与连接的前一个化身的 FIN 标志对应的序列号，用于数据传输的那个方向。

许多实现在执行上述启发式算法时不包括 TCP 时间戳选项，因此对初始序列号的生成、连接的平均数据传输速率以及与它们一起传输的数据量施加了更严格的限制。 RFC 793 [RFC0793] 指出 ISN 生成器应该大约每四微秒递增一次（即大约每秒 250,000 次）。因此，任何以超过 250 KB/秒的速度传输超过 250,000 字节数据的连接都可能导致在进入 TIME-WAIT 状态的连接上看到的最后一个序列号仍然大于旨在创建相同连接的新化身的传入 SYN 段的序列号的情况。在这些情况下，ISN 试探将失败，因此连接请求通常会超时。通过在上述启发式中包含 TCP Timestamps 选项，所有这些限制都大大放宽了。

很明显，将 TCP 时间戳用于上述启发式方法受益于在相同的两个 TCP 端点之间的连接之间单调增加的时间戳。

注意：
即将到来的 RFC 1323 修订版 [1323bis] 建议选择时间戳，以便它们在连接之间单调增加。可以在 [TS-Generation] 中找到此类时间戳生成方案的示例。

3. 与各种时间戳生成算法的交互

第 2 节中提出的算法显然受益于在到同一端点的连接之间单调增加的时间戳。特别是，生成单调递增的时间戳对于执行主动打开的 TCP 实例很重要，因为这些时间戳将用于所提出的算法。

虽然单调递增的时间戳确保所提出的算法能够减少一个连接的先前化身的 TIME-WAIT 状态，但该算法的实现（本身）并不意味着对其他 TCP 实现的时间戳生成算法的要求。

在最坏的情况下，与 TIME-WAIT 中连接的新化身相对应的传入 SYN 包含的时间戳小于在连接的前一个化身上看到的最后一个时间戳，启发式失败，结果是不比现在的状况更糟。也就是说，SYN 段被忽略（如 [RFC1337] 中规定的），因此连接请求超时，或者在 SYN 的未来重传后被接受。
某些堆栈可能会实现时间戳生成算法，这些算法不会导致具有相同远程端点的连接之间的时间戳单调增加。此类算法的一个示例是 [RFC4987] 和 [Opperman] 中描述的算法，它允许实现扩展的 TCP SYN cookie.

Note：
需要注意的是，“扩展的 TCP SYN cookies”可以与生成时间戳的算法共存，使它们单调递增。可以为执行主动打开的 TCP 实例生成单调递增的时间戳，而可以根据 [Opperman] 为执行被动打开的 TCP 实例生成时间戳.

一些堆栈（尤其是 OpenBSD）实现了时间戳随机化算法，这些算法不会导致跨连接的 ISN 单调增加。如 [Silbersack] 中所述，此类随机化方案可能会阻止本文档中提出的对处于 TIME-WAIT 状态的连接的回收机制。然而，正如本节前面提到的，在最坏的情况下，试探法失败了，结果并不比当前的情况更糟。

4. 与各种 ISN 生成算法的交互

[RFC0793] 建议 TCP 连接的 ISN 由全局计时器生成，以便它们在连接之间单调增加。然而，这种 ISN 生成方案导致可预测的 ISN，其具有众所周知的安全隐患 [CPNI-TCP]。 [RFC1948] 提出了一种替代的 ISN 生成方案，该方案会导致跨连接的 ISN 单调增加，这些连接不容易被路径外攻击者预测。

一些堆栈（尤其是 OpenBSD）实现了 ISN 随机化算法，这些算法不会导致跨连接的 ISN 单调增加。如 [Silbersack] 中所述，此类 ISN 随机化方案破坏了 BSD 对为处于 TIME-WAIT 状态的连接接收到的 SYN 段的改进处理。

本文档中提出的机制的实现将启用 TIME-WAIT 状态的回收，即使存在跨连接不单调增加的 ISN，除非传入 SYN 中包含的时间戳等于在网络上看到的最后一个时间戳。处于 TIME-WAIT 状态的连接（对于数据传输的那个方向）。

5. 安全考虑

[TCP-Security] 包含对 TCP 时间戳和不同时间戳生成算法的安全影响的详细讨论。

6. 致谢（略）

附录 A. 拟议机制在特定情况下的行为

A.1.系统重启后的连接请求

本节阐明了在计算机重新启动、保持相同 IP 地址、丢失先前时间戳的内存，然后尝试重新建立先前连接的情况下，该算法将如何运行。

首先，如 [RFC0793] 中所规定，主机在启动后的 2*MSL（最大段生存期）期间不得建立新连接（这是“静默时间”概念）。因此，就规范而言，这种情况不应该发生。

如果主机不符合“静默时间概念”，则连接请求可能会发送到远程主机，而远程主机上的同一连接的先前化身处于 TIME-WAIT 状态。在这种情况下，由于丢失了先前时间戳的内存，结果时间戳可能不会单调增加，因此所提出的算法可能无法回收处于 TIME-WAIT 状态的连接的先前化身。这种情况对应于没有本文档中提出的算法的当前事态。