【RFC7413 TCP快速打开】（翻译）

原文 https://datatracker.ietf.org/doc/html/rfc7413 TCP Fast Open TCP快速打开

概述

本文档描述了一种称为 TCP Fast Open (TFO) 的实验性 TCP 机制。 TFO 允许在 SYN 和 SYN-ACK 数据包中携带数据并在初始连接握手期间由接收端消耗，并且与标准 TCP 相比，最多可以节省一个完整的往返时间 (RTT)，后者需要三次握手（3WHS）完成之前可以交换数据。 然而，TFO 偏离了标准的 TCP 语义，因为 SYN 中的数据可能会在极少数情况下重放给应用程序。
应用程序不应使用 TFO，除非它们可以容忍此问题，如适用性部分所述。

目录

   1. 简介
      1.1. 术语
   2. SYN 中的数据
      2.1. 放宽重复 SYN 上的 TCP 语义
      2.2. 带有欺骗性 IP 地址的 SYN
   3. 协议概述
   4. 协议详情
      4.1. 快速打开Cookie
           4.1.1.快速打开选项
           4.1.2.服务器 Cookie 处理
           4.1.3.客户端 Cookie 处理
                  4.1.3.1.客户端缓存消极响应
      4.2.快速打开协议
           4.2.1.快速打开 Cookie 请求
           4.2.2. TCP快速打开
   5. 安全考虑
      5.1. SYN Flood 使用有效 Cookie 进行资源耗尽攻击
           5.1.1.来自共享公共 IP (NAT) 背后的攻击
      5.2. 对随机主机的放大反射攻击
   6. TFO 适用性
      6.1. SYN 中的重复数据
      6.2. 潜在的性能改进
      6.3. 示例：Web 客户端和服务器
           6.3.1. HTTP 请求重放
           6.3.2. 基于 TLS 的 HTTP (HTTPS)
           6.3.3. 与 HTTP 持久连接的比较
           6.3.4. 负载均衡器和服务器群
   7. 开放试验区
      7.1. Middleboxes 和 NAT 对性能的影响
      7.2. 对拥塞控制的影响
      7.3.无 Cookie 快速打开
   八、相关工作
      8.1. T/TCP
      8.2. 针对 SYN Flood 攻击的常见防御措施
      8.3. 应用程序的推测连接
      8.4. 快速打开 Cookie-in-FIN
      8.5. TCP Cookie 事务 (TCPCT)
   9. IANA 考虑
   10. 参考文献
      10.1. 规范参考
      10.2. 参考资料
   附录 A. 支持 TFO 的套接字 API 更改示例
    A.1. 主动打开
    A.2. 被动打开
   致谢
   作者地址

1. 简介

TCP Fast Open (TFO) 是 TCP 的实验性更新，它使数据能够在 TCP 的连接握手期间安全地交换。本文档描述了一种设计，该设计使应用程序能够节省往返时间，同时避免严重的安全后果。 TFO 的核心是一个安全 cookie，服务器端使用它来验证启动 TFO 连接的客户端。本文档涵盖了 TCP 初始握手期间交换数据的详细信息、TFO cookie 协议、潜在的新安全漏洞及其缓解措施，以及新的套接字 API。

TFO 的动机是当今 Web 应用程序的性能需求。当前的 TCP 仅允许在三次握手（3WHS）[RFC793] 之后进行数据交换，这为网络延迟增加了一个 RTT。对于短时间的 Web 传输，即使 HTTP 持久连接被广泛使用，这个额外的 RTT 也是整个网络延迟的重要组成部分。例如，Chrome 浏览器 [Chrome] 使 TCP 连接空闲长达 5 分钟，但 35% 的 HTTP 请求是在新的 TCP 连接上进行的 [RCCJR11]。对于此类 Web 和类 Web 应用程序，将数据放入 SYN 可以显着改善延迟。接下来，我们将描述我们如何解决这样做时出现的挑战。

2. SYN 中的数据

标准 TCP 已经允许在 SYN 数据包中携带数据（[RFC793]，第 3.4 节），但禁止接收方在 3WHS 完成之前将其传送给应用程序。这是因为 TCP 的初始握手用于捕获旧的或重复的 SYN。

为了使应用程序能够在 TCP 握手中交换数据，TFO 删除了约束并允许将 SYN 数据包中的数据传送到应用程序。对 TCP 语义的这种更改引发了两个问题
（在以下小节中讨论）使 TFO 不适用于某些应用。

因此，TCP 实现在默认情况下不得使用 TFO，而仅在应用程序在每个服务端口的基础上明确请求时才使用 TFO。在使用 TFO 之前，应用程序需要按照第 6 节所述评估 TFO 适用性。

2.1.放宽重复 SYN 上的 TCP 语义

TFO 允许在 3WHS 完成之前将数据交付给应用程序，因此在以下两种情况中的任何一种情况下都会面临数据完整性问题：

   a) 接收方主机在忘记接收到原始 SYN 后（例如，由于重新启动）接收到重复 SYN 中的数据；

   b) 在原始 SYN 创建的连接关闭并且关闭是由发送方发起的（因此接收方将不受 TIME-WAIT 2 MSL 状态保护）后接收到副本。

现在已过时的 T/TCP [RFC1644]（已被 [RFC6247] 废弃）试图解决这些问题。由于第 8 节“相关工作”中描述的各种漏洞，它没有成功并且没有部署。与其试图捕获所有可疑的 SYN 数据包以使 TFO 100% 与 TCP 语义兼容，我们更早地做出了一个设计决定，即接受带有数据的旧 SYN 数据包，即，将 TFO 的使用限制为一类应用程序（第 6 节）可以容忍带有数据的重复 SYN 数据包。我们相信这是正确的设计权衡：平衡复杂性和实用性。

2.2.带有欺骗性 IP 地址的 SYN

标准 TCP 遭受 SYN flood 攻击 [RFC4987]，因为带有欺骗源 IP 地址的 SYN 数据包很容易填满侦听器的小队列，导致服务端口完全阻塞。

TFO 更进一步，允许服务器端 TCP 在 3WHS 完成之前向应用层发送数据。这会带来严重的新漏洞。为启用 TFO 的端口提供服务的应用程序可能会浪费大量 CPU 和内存资源来处理请求和产生响应。如果响应比请求大得多，攻击者可以进一步对 TFO 服务器本身之外的受害者发起放大反射攻击。

存在许多针对常规 SYN 泛洪攻击的缓解技术，并且已被详细记录 [RFC4987]。不幸的是，没有一个适用于 TFO。我们在第 3 节中提出了一个服务器提供的 cookie 来缓解这些新漏洞，并在第 7 节中评估防御的有效性。

3. 协议概述

TFO 的关键组件是 Fast Open Cookie (cookie)，服务器生成的消息验证码 (MAC) 标签。客户端在一个常规 TCP 连接中请求 cookie，然后将其用于未来的 TCP 连接以在 3WHS 期间交换数据：

请求快速打开 Cookie：

   1. 客户端发送一个带有快速打开选项的 SYN 和一个空的 cookie 字段来请求一个 cookie。

   2. 服务器生成 cookie并通过SYN-ACK数据包的Fast Open选项发送。

   3. 客户端缓存 cookie 以备将来 TCP Fast Open 连接使用（见下文）。

执行 TCP 快速打开：

   1. 客户端在 Fast Open 选项中发送带