Internet Engineering Task Force (IETF) Y. Cheng
Request for Comments: 7413 J. Chu
Category: Experimental S. Radhakrishnan
ISSN: 2070-1721 A. Jain
Google
December 2014
Internet Engineering Task Force (IETF) Y. Cheng
Request for Comments: 7413 J. Chu
Category: Experimental S. Radhakrishnan
ISSN: 2070-1721 A. Jain
Google
December 2014
TCP Fast Open
TCP快速打开
Abstract
摘要
This document describes an experimental TCP mechanism called TCP Fast Open (TFO). TFO allows data to be carried in the SYN and SYN-ACK packets and consumed by the receiving end during the initial connection handshake, and saves up to one full round-trip time (RTT) compared to the standard TCP, which requires a three-way handshake (3WHS) to complete before data can be exchanged. However, TFO deviates from the standard TCP semantics, since the data in the SYN could be replayed to an application in some rare circumstances. Applications should not use TFO unless they can tolerate this issue, as detailed in the Applicability section.
本文档描述了一种称为TCP快速开放（TFO）的实验性TCP机制。TFO允许数据在SYN和SYN-ACK数据包中传输，并在初始连接握手期间由接收端使用，与标准TCP相比，TFO最多节省一次完整的往返时间（RTT），标准TCP要求在交换数据之前完成三次握手（3WHS）。但是，TFO偏离了标准TCP语义，因为在某些罕见的情况下，SYN中的数据可以重放到应用程序中。应用程序不应使用TFO，除非它们能够容忍此问题，如适用性部分所述。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7413.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7413.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Terminology ................................................4
2. Data in SYN .....................................................4
2.1. Relaxing TCP Semantics on Duplicated SYNs ..................4
2.2. SYNs with Spoofed IP Addresses .............................5
3. Protocol Overview ...............................................5
4. Protocol Details ................................................7
4.1. Fast Open Cookie ...........................................7
4.1.1. Fast Open Option ....................................8
4.1.2. Server Cookie Handling ..............................8
4.1.3. Client Cookie Handling ..............................9
4.1.3.1. Client Caching Negative Responses .........10
4.2. Fast Open Protocol ........................................11
4.2.1. Fast Open Cookie Request ...........................11
4.2.2. TCP Fast Open ......................................12
5. Security Considerations ........................................14
5.1. Resource Exhaustion Attack by SYN Flood with Valid
Cookies ...................................................14
5.1.1. Attacks from behind Shared Public IPs (NATs) .......15
5.2. Amplified Reflection Attack to Random Host ................16
6. TFO Applicability ..............................................17
6.1. Duplicate Data in SYNs ....................................17
6.2. Potential Performance Improvement .........................17
6.3. Example: Web Clients and Servers ..........................18
6.3.1. HTTP Request Replay ................................18
6.3.2. HTTP over TLS (HTTPS) ..............................18
6.3.3. Comparison with HTTP Persistent Connections ........18
6.3.4. Load Balancers and Server Farms ....................19
1. Introduction ....................................................3
1.1. Terminology ................................................4
2. Data in SYN .....................................................4
2.1. Relaxing TCP Semantics on Duplicated SYNs ..................4
2.2. SYNs with Spoofed IP Addresses .............................5
3. Protocol Overview ...............................................5
4. Protocol Details ................................................7
4.1. Fast Open Cookie ...........................................7
4.1.1. Fast Open Option ....................................8
4.1.2. Server Cookie Handling ..............................8
4.1.3. Client Cookie Handling ..............................9
4.1.3.1. Client Caching Negative Responses .........10
4.2. Fast Open Protocol ........................................11
4.2.1. Fast Open Cookie Request ...........................11
4.2.2. TCP Fast Open ......................................12
5. Security Considerations ........................................14
5.1. Resource Exhaustion Attack by SYN Flood with Valid
Cookies ...................................................14
5.1.1. Attacks from behind Shared Public IPs (NATs) .......15
5.2. Amplified Reflection Attack to Random Host ................16
6. TFO Applicability ..............................................17
6.1. Duplicate Data in SYNs ....................................17
6.2. Potential Performance Improvement .........................17
6.3. Example: Web Clients and Servers ..........................18
6.3.1. HTTP Request Replay ................................18
6.3.2. HTTP over TLS (HTTPS) ..............................18
6.3.3. Comparison with HTTP Persistent Connections ........18
6.3.4. Load Balancers and Server Farms ....................19
7. Open Areas for Experimentation .................................19
7.1. Performance Impact Due to Middleboxes and NAT .............19
7.2. Impact on Congestion Control ..............................20
7.3. Cookie-less Fast Open .....................................20
8. Related Work ...................................................20
8.1. T/TCP .....................................................20
8.2. Common Defenses against SYN Flood Attacks .................21
8.3. Speculative Connections by the Applications ...............21
8.4. Fast Open Cookie-in-FIN ...................................21
8.5. TCP Cookie Transaction (TCPCT) ............................21
9. IANA Considerations ............................................22
10. References ....................................................22
10.1. Normative References .....................................22
10.2. Informative References ...................................23
Appendix A. Example Socket API Changes to Support TFO .............25
A.1. Active Open .................................................25
A.2. Passive Open ................................................25
Acknowledgments ...................................................26
Authors' Addresses ................................................26
7. Open Areas for Experimentation .................................19
7.1. Performance Impact Due to Middleboxes and NAT .............19
7.2. Impact on Congestion Control ..............................20
7.3. Cookie-less Fast Open .....................................20
8. Related Work ...................................................20
8.1. T/TCP .....................................................20
8.2. Common Defenses against SYN Flood Attacks .................21
8.3. Speculative Connections by the Applications ...............21
8.4. Fast Open Cookie-in-FIN ...................................21
8.5. TCP Cookie Transaction (TCPCT) ............................21
9. IANA Considerations ............................................22
10. References ....................................................22
10.1. Normative References .....................................22
10.2. Informative References ...................................23
Appendix A. Example Socket API Changes to Support TFO .............25
A.1. Active Open .................................................25
A.2. Passive Open ................................................25
Acknowledgments ...................................................26
Authors' Addresses ................................................26
TCP Fast Open (TFO) is an experimental update to TCP that enables data to be exchanged safely during TCP's connection handshake. This document describes a design that enables applications to save a round trip while avoiding severe security ramifications. At the core of TFO is a security cookie used by the server side to authenticate a client initiating a TFO connection. This document covers the details of exchanging data during TCP's initial handshake, the protocol for TFO cookies, potential new security vulnerabilities and their mitigation, and the new socket API.
TCP Fast Open（TFO）是对TCP的实验性更新，它使数据能够在TCP的连接握手期间安全地交换。本文档描述了一种设计，使应用程序能够在避免严重安全后果的同时节省往返时间。TFO的核心是服务器端用来验证启动TFO连接的客户端的安全cookie。本文档涵盖TCP初始握手期间交换数据的详细信息、TFO Cookie协议、潜在的新安全漏洞及其缓解措施，以及新的套接字API。
TFO is motivated by the performance needs of today's Web applications. Current TCP only permits data exchange after the three-way handshake (3WHS) [RFC793], which adds one RTT to network latency. For short Web transfers this additional RTT is a significant portion of overall network latency, even when HTTP persistent connection is widely used. For example, the Chrome browser [Chrome] keeps TCP connections idle for up to 5 minutes, but 35% of HTTP requests are made on new TCP connections [RCCJR11]. For such Web and Web-like applications, placing data in the SYN can yield significant latency improvements. Next we describe how we resolve the challenges that arise upon doing so.
TFO的动机是当今Web应用程序的性能需求。当前的TCP只允许在三方握手（3WHS）[RFC793]之后进行数据交换，这会给网络延迟增加一个RTT。对于简短的Web传输，即使广泛使用HTTP持久连接，这种额外的RTT也是整个网络延迟的重要部分。例如，Chrome浏览器[Chrome]使TCP连接保持空闲长达5分钟，但35%的HTTP请求是在新的TCP连接[RCCJR11]上发出的。对于此类Web和类似Web的应用程序，将数据放置在SYN中可以显著提高延迟。接下来，我们将描述我们如何解决这样做时出现的挑战。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
"TFO" refers to TCP Fast Open. "Client" refers to TCP's active open side, and "server" refers to TCP's passive open side.
“TFO”指TCP快速打开。“客户端”是指TCP的主动开放端，“服务器”是指TCP的被动开放端。
Standard TCP already allows data to be carried in SYN packets ([RFC793], Section 3.4) but forbids the receiver from delivering it to the application until the 3WHS is completed. This is because TCP's initial handshake serves to capture old or duplicate SYNs.
标准TCP已经允许在SYN数据包中传输数据（[RFC793]，第3.4节），但在3WHS完成之前，禁止接收方将数据传输到应用程序。这是因为TCP的初始握手用于捕获旧的或重复的SYN。
To enable applications to exchange data in a TCP handshake, TFO removes the constraint and allows data in SYN packets to be delivered to the application. This change to TCP semantic raises two issues (discussed in the following subsections) that make TFO unsuitable for certain applications.
为了使应用程序能够在TCP握手中交换数据，TFO消除了该约束，并允许将SYN数据包中的数据传递给应用程序。对TCP语义的这一更改引发了两个问题（将在以下小节中讨论），使TFO不适合某些应用程序。
Therefore, TCP implementations MUST NOT use TFO by default, but only use TFO if requested explicitly by the application on a per-service-port basis. Applications need to evaluate TFO applicability as described in Section 6 before using TFO.
因此，TCP实现在默认情况下不能使用TFO，而只能在应用程序基于每个服务端口明确请求时使用TFO。在使用TFO之前，应用程序需要按照第6节所述评估TFO的适用性。
TFO allows data to be delivered to the application before the 3WHS is completed, thus opening itself to a data integrity issue in either of the two cases below:
TFO允许在3WHS完成之前将数据交付给应用程序，因此在以下两种情况下都会出现数据完整性问题：
a) the receiver host receives data in a duplicate SYN after it has forgotten it received the original SYN (e.g., due to a reboot);
a) 接收器主机在忘记接收到原始SYN后（例如，由于重新启动），以重复SYN的形式接收数据；
b) the duplicate is received after the connection created by the original SYN has been closed and the close was initiated by the sender (so the receiver will not be protected by the TIME-WAIT 2 MSL state).
b) 在原始SYN创建的连接已关闭且发送方已启动关闭后（因此，接收方将不受TIME-WAIT 2 MSL状态的保护），将接收到副本。
The now obsoleted T/TCP [RFC1644] (obsoleted by [RFC6247]) attempted to address these issues. It was not successful and not deployed due to various vulnerabilities as described in Section 8, "Related Work". Rather than trying to capture all dubious SYN packets to make TFO 100% compatible with TCP semantics, we made a design decision early on to accept old SYN packets with data, i.e., to restrict TFO use to
现在被淘汰的T/TCP[RFC1644]（被[RFC6247]淘汰）试图解决这些问题。由于第8节“相关工作”中所述的各种漏洞，它未成功部署。我们没有试图捕获所有可疑的SYN数据包以使TFO 100%与TCP语义兼容，而是在早期做出了一个设计决策，即接受带有数据的旧SYN数据包，即限制TFO的使用
a class of applications (Section 6) that are tolerant of duplicate SYN packets with data. We believe this is the right design trade-off: balancing complexity with usefulness.
一类应用程序（第6节），可容忍包含数据的重复SYN数据包。我们相信这是正确的设计权衡：平衡复杂性和实用性。
Standard TCP suffers from the SYN flood attack [RFC4987] because SYN packets with spoofed source IP addresses can easily fill up a listener's small queue, causing a service port to be blocked completely.
标准TCP遭受SYN洪水攻击[RFC4987]，因为带有伪造源IP地址的SYN数据包很容易填满侦听器的小队列，导致服务端口完全阻塞。
TFO goes one step further to allow server-side TCP to send up data to the application layer before the 3WHS is completed. This opens up serious new vulnerabilities. Applications serving ports that have TFO enabled may waste lots of CPU and memory resources processing the requests and producing the responses. If the response is much larger than the request, the attacker can further mount an amplified reflection attack against victims of choice beyond the TFO server itself.
TFO进一步允许服务器端TCP在3WHS完成之前向应用层发送数据。这带来了严重的新漏洞。为启用TFO的端口提供服务的应用程序可能会浪费大量CPU和内存资源来处理请求和生成响应。如果响应比请求大得多，攻击者可以针对TFO服务器本身以外的受害者进一步发起放大反射攻击。
Numerous mitigation techniques against regular SYN flood attacks exist and have been well documented [RFC4987]. Unfortunately, none are applicable to TFO. We propose a server-supplied cookie to mitigate these new vulnerabilities in Section 3 and evaluate the effectiveness of the defense in Section 7.
存在许多针对常规SYN洪水攻击的缓解技术，这些技术已得到充分证明[RFC4987]。不幸的是，没有一个适用于TFO。我们在第3节中提出了一个服务器提供的cookie来缓解这些新漏洞，并在第7节中评估防御的有效性。
The key component of TFO is the Fast Open Cookie (cookie), a message authentication code (MAC) tag generated by the server. The client requests a cookie in one regular TCP connection, then uses it for future TCP connections to exchange data during the 3WHS:
TFO的关键组件是快速打开Cookie（Cookie），这是服务器生成的消息身份验证代码（MAC）标记。客户端在一个常规TCP连接中请求cookie，然后将其用于未来的TCP连接，以在3WHS期间交换数据：
Requesting a Fast Open Cookie:
请求快速打开Cookie：
1. The client sends a SYN with a Fast Open option with an empty cookie field to request a cookie.
1. 客户端发送一个带有快速打开选项（带有空cookie字段）的SYN来请求cookie。
2. The server generates a cookie and sends it through the Fast Open option of a SYN-ACK packet.
2. 服务器生成cookie并通过SYN-ACK数据包的快速打开选项发送。
3. The client caches the cookie for future TCP Fast Open connections (see below).
3. 客户端缓存cookie，以备将来使用TCP快速打开连接（请参见下文）。
Performing TCP Fast Open:
正在执行TCP快速打开：
1. The client sends a SYN with data and the cookie in the Fast Open option.
1. 客户端发送一个SYN，其中包含数据和快速打开选项中的cookie。
2. The server validates the cookie:
2. 服务器验证cookie：
a. If the cookie is valid, the server sends a SYN-ACK acknowledging both the SYN and the data. The server then delivers the data to the application.
a. 如果cookie有效，服务器将发送SYN-ACK，确认SYN和数据。然后，服务器将数据传递给应用程序。
b. Otherwise, the server drops the data and sends a SYN-ACK acknowledging only the SYN sequence number.
b. 否则，服务器将丢弃数据并发送SYN-ACK，仅确认SYN序列号。
3. If the server accepts the data in the SYN packet, it may send the response data before the handshake finishes. The maximum amount is governed by TCP's congestion control [RFC5681].
3. 如果服务器接受SYN数据包中的数据，它可能会在握手完成之前发送响应数据。最大数量由TCP的拥塞控制[RFC5681]控制。
4. The client sends an ACK acknowledging the SYN and the server data. If the client's data is not acknowledged, the client retransmits the data in the ACK packet.
4. 客户端发送确认SYN和服务器数据的ACK。如果客户机的数据未被确认，则客户机重新传输ACK数据包中的数据。
5. The rest of the connection proceeds like a normal TCP connection. The client can repeat many Fast Open operations once it acquires a cookie (until the cookie is expired by the server). Thus, TFO is useful for applications that have temporal locality on client and server connections.
5. 其余的连接将像正常的TCP连接一样进行。客户机可以在获取cookie后重复许多快速打开操作（直到服务器终止cookie）。因此，TFO对于在客户端和服务器连接上具有时间局部性的应用程序非常有用。
Requesting Fast Open Cookie in connection 1:
正在连接1中请求快速打开Cookie：
TCP A (Client) TCP B (Server)
______________ ______________
CLOSED LISTEN
TCP A (Client) TCP B (Server)
______________ ______________
CLOSED LISTEN
#1 SYN-SENT ----- <SYN,CookieOpt=NIL> ----------> SYN-RCVD
#1 SYN-SENT ----- <SYN,CookieOpt=NIL> ----------> SYN-RCVD
#2 ESTABLISHED <---- <SYN,ACK,CookieOpt=C> ---------- SYN-RCVD
(caches cookie C)
#2 ESTABLISHED <---- <SYN,ACK,CookieOpt=C> ---------- SYN-RCVD
(caches cookie C)
Performing TCP Fast Open in connection 2:
正在连接2中执行TCP快速打开：
TCP A (Client) TCP B (Server)
______________ ______________
CLOSED LISTEN
TCP A (Client) TCP B (Server)
______________ ______________
CLOSED LISTEN
#1 SYN-SENT ----- <SYN=x,CookieOpt=C,DATA_A> ----> SYN-RCVD
#1 SYN-SENT ----- <SYN=x,CookieOpt=C,DATA_A> ----> SYN-RCVD
#2 ESTABLISHED <---- <SYN=y,ACK=x+len(DATA_A)+1> ---- SYN-RCVD
#2 ESTABLISHED <---- <SYN=y,ACK=x+len(DATA_A)+1> ---- SYN-RCVD
#3 ESTABLISHED <---- <ACK=x+len(DATA_A)+1,DATA_B>---- SYN-RCVD
#3 ESTABLISHED <---- <ACK=x+len(DATA_A)+1,DATA_B>---- SYN-RCVD
#4 ESTABLISHED ----- <ACK=y+1>--------------------> ESTABLISHED
#4 ESTABLISHED ----- <ACK=y+1>--------------------> ESTABLISHED
#5 ESTABLISHED --- <ACK=y+len(DATA_B)+1>----------> ESTABLISHED
#5 ESTABLISHED --- <ACK=y+len(DATA_B)+1>----------> ESTABLISHED
The Fast Open Cookie is designed to mitigate new security vulnerabilities in order to enable data exchange during a handshake. The cookie is a MAC tag generated by the server and is opaque to the client; the client simply caches the cookie and passes it back on subsequent SYN packets to open new connections. The server can expire the cookie at any time to enhance security.
Fast Open Cookie旨在缓解新的安全漏洞，以便在握手过程中实现数据交换。cookie是服务器生成的MAC标签，对客户端不透明；客户端只是缓存cookie并将其传递回后续SYN数据包以打开新连接。服务器可以随时使cookie过期以增强安全性。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Kind 1 byte: value = 34 Length 1 byte: range 6 to 18 (bytes); limited by remaining space in the options field. The number MUST be even. Cookie 0, or 4 to 16 bytes (Length - 2)
种类1字节：值=34长度1字节：范围6到18（字节）；受限于选项字段中的剩余空间。数字必须是偶数。Cookie 0或4到16字节（长度-2）
The Fast Open option is used to request or to send a Fast Open Cookie. When a cookie is not present or is empty, the option is used by the client to request a cookie from the server. When the cookie is present, the option is used to pass the cookie from the server to the client or from the client back to the server (to perform a Fast Open).
快速打开选项用于请求或发送快速打开Cookie。当cookie不存在或为空时，客户端将使用该选项从服务器请求cookie。当cookie存在时，该选项用于将cookie从服务器传递到客户端或从客户端传递回服务器（以执行快速打开）。
The minimum cookie size is 4 bytes. Although the diagram shows a cookie aligned on 32-bit boundaries, alignment is not required. Options with invalid Length values or without the SYN flag set MUST be ignored.
最小cookie大小为4字节。尽管该图显示了在32位边界上对齐的cookie，但不需要对齐。必须忽略长度值无效或未设置SYN标志的选项。
The server is in charge of cookie generation and authentication. The cookie SHOULD be a MAC tag with the following properties. We use "SHOULD" because, in some cases, the cookie may be trivially generated as discussed in Section 7.3.
服务器负责cookie生成和身份验证。cookie应该是具有以下属性的MAC标记。我们使用“应该”是因为，在某些情况下，cookie可能会像第7.3节中讨论的那样生成。
1. The cookie authenticates the client's (source) IP address of the SYN packet. The IP address may be an IPv4 or IPv6 address.
1. cookie验证SYN数据包的客户端（源）IP地址。IP地址可以是IPv4或IPv6地址。
2. The cookie can only be generated by the server and cannot be fabricated by any other parties, including the client.
2. cookie只能由服务器生成，不能由任何其他方（包括客户端）制作。
3. The generation and verification are fast relative to the rest of SYN and SYN-ACK processing.
3. 相对于SYN和SYN-ACK处理的其余部分，生成和验证速度更快。
4. A server may encode other information in the cookie and accept more than one valid cookie per client at any given time. But this is server-implementation dependent and transparent to the client.
4. 服务器可以对cookie中的其他信息进行编码，并在任何给定时间为每个客户端接受多个有效cookie。但这依赖于服务器实现，并且对客户端是透明的。
5. The cookie expires after a certain amount of time. The reason for cookie expiration is detailed in the "Security Considerations" section (Section 5). This can be done by either periodically changing the server key used to generate cookies or including a timestamp when generating the cookie.
5. cookie在一定时间后过期。cookie过期的原因在“安全注意事项”部分（第5节）中有详细说明。这可以通过定期更改用于生成cookie的服务器密钥或在生成cookie时包含时间戳来实现。
To gradually invalidate cookies over time, the server can implement key rotation to generate and verify cookies using multiple keys. This approach is useful for large-scale servers to retain Fast Open rolling key updates. We do not specify a particular mechanism because the implementation is server specific.
为了随着时间的推移逐渐使cookie无效，服务器可以实现密钥轮换，以使用多个密钥生成和验证cookie。这种方法对于大型服务器保留快速打开滚动键更新非常有用。我们没有指定特定的机制，因为实现是特定于服务器的。
The server supports the cookie-generation and verification operations:
服务器支持cookie生成和验证操作：
- GetCookie(IP_Address): returns a (new) cookie.
- GetCookie（IP_地址）：返回一个（新的）cookie。
- IsCookieValid(IP_Address, Cookie): checks if the cookie is valid, i.e., it has not expired and the cookie authenticates the client IP address.
- IsCookieValid（IP_地址，Cookie）：检查Cookie是否有效，即它尚未过期，Cookie验证客户端IP地址。
Example Implementation: a simple implementation is to use AES_128 to encrypt the IPv4 (with padding) or IPv6 address and truncate to 64 bits. The server can periodically update the key to expire the cookies. AES encryption on recent processors is fast and takes only a few hundred nanoseconds [RCCJR11].
示例实现：一个简单的实现是使用AES_128加密IPv4（带填充）或IPv6地址，并截断为64位。服务器可以定期更新密钥以使cookie过期。最新处理器上的AES加密速度快，只需几百纳秒[RCCJR11]。
If only one valid cookie is allowed per IP, and the server can regenerate the cookie independently, the best validation process is to simply regenerate a valid cookie and compare it against the incoming cookie. In that case, if the incoming cookie fails the check, a valid cookie is readily available to be sent to the client.
如果每个IP只允许一个有效的cookie，并且服务器可以独立地重新生成cookie，那么最好的验证过程就是简单地重新生成一个有效的cookie，并将其与传入的cookie进行比较。在这种情况下，如果传入的cookie未通过检查，则可以随时向客户端发送有效的cookie。
The client MUST cache cookies from servers for later Fast Open connections. For a multihomed client, the cookies are dependent on the client and server IP addresses. Hence, the client should cache at most one (most recently received) cookie per client and server IP address pair.
客户端必须缓存来自服务器的cookie，以便以后快速打开连接。对于多主机客户端，cookie取决于客户端和服务器IP地址。因此，客户机应该为每个客户机和服务器IP地址对缓存最多一个（最近收到的）cookie。
When caching cookies, we recommend that the client also cache the Maximum Segment Size (MSS) advertised by the server. The client can cache the MSS advertised by the server in order to determine the maximum amount of data that the client can fit in the SYN packet in subsequent TFO connections. Caching the server MSS is useful because, with Fast Open, a client sends data in the SYN packet before
缓存cookie时，我们建议客户端也缓存服务器公布的最大段大小（MSS）。客户机可以缓存服务器播发的MSS，以确定客户机在后续TFO连接中可容纳在SYN数据包中的最大数据量。缓存服务器MSS很有用，因为使用Fast Open时，客户机会在之前发送SYN数据包中的数据
the server announces its MSS in the SYN-ACK packet. If the client sends more data in the SYN packet than the server will accept, this will likely require the client to retransmit some or all of the data. Hence, caching the server MSS can enhance performance.
服务器在SYN-ACK数据包中宣布其MSS。如果客户端在SYN数据包中发送的数据多于服务器所能接受的数据，则可能需要客户端重新传输部分或全部数据。因此，缓存服务器MSS可以提高性能。
Without a cached server MSS, the amount of data in the SYN packet is limited to the default MSS of 536 bytes for IPv4 [RFC1122] and 1220 bytes for IPv6 [RFC2460]. Even if the client complies with this limit when sending the SYN, it is known that an IPv4 receiver advertising an MSS less than 536 bytes can receive a segment larger than it is expecting.
在没有缓存服务器MSS的情况下，SYN数据包中的数据量限制为默认MSS，IPv4[RFC1122]为536字节，IPv6[RFC2460]为1220字节。即使客户端在发送SYN时遵守此限制，也可以知道，向小于536字节的MSS发送广告的IPv4接收器可以接收比预期大的段。
If the cached MSS is larger than the typical size (1460 bytes for IPv4 or 1440 bytes for IPv6), then the excess data in the SYN packet may cause problems that offset the performance benefit of Fast Open. For example, the unusually large SYN may trigger IP fragmentation and may confuse firewalls or middleboxes, causing SYN retransmission and other side effects. Therefore, the client MAY limit the cached MSS to 1460 bytes for IPv4 or 1440 for IPv6.
如果缓存的MSS大于典型大小（对于IPv4为1460字节，对于IPv6为1440字节），则SYN数据包中的多余数据可能会导致问题，从而抵消Fast Open的性能优势。例如，异常大的SYN可能触发IP碎片，并可能混淆防火墙或中间盒，导致SYN重新传输和其他副作用。因此，对于IPv4，客户端可以将缓存的MSS限制为1460字节，对于IPv6，客户端可以将缓存的MSS限制为1440字节。
The client MUST cache negative responses from the server in order to avoid potential connection failures. Negative responses include the server not acknowledging the data in the SYN, ICMP error messages, and (most importantly) no response (SYN-ACK) from the server at all, i.e., connection timeout. The last case is likely due to incompatible middleboxes or firewall blocking the connection completely after processing the SYN packet with data. If the client does not react to these negative responses and continues to retry Fast Open, the client may never be able to connect to the specific server.
客户端必须缓存来自服务器的否定响应，以避免潜在的连接故障。负面响应包括服务器未确认SYN中的数据、ICMP错误消息，以及（最重要的）服务器根本没有响应（SYN-ACK），即连接超时。最后一种情况可能是由于不兼容的中间盒或防火墙在处理带有数据的SYN数据包后完全阻塞了连接。如果客户端对这些负面响应没有反应，并继续重试Fast Open，则客户端可能永远无法连接到特定服务器。
For any negative responses, the client SHOULD disable Fast Open on the specific path (the source and destination IP addresses and ports) at least temporarily. Since TFO is enabled on a per-service-port basis, but cookies are independent of service ports, the client's cache should include remote port numbers, too.
对于任何负面响应，客户端应至少暂时禁用特定路径（源和目标IP地址和端口）上的Fast Open。由于TFO是基于每个服务端口启用的，但Cookie独立于服务端口，因此客户端的缓存也应该包括远程端口号。
One predominant requirement of TFO is to be fully compatible with existing TCP implementations, on both the client and server sides.
TFO的一个主要要求是在客户端和服务器端与现有的TCP实现完全兼容。
The server keeps two variables per listening socket (IP address and port):
服务器为每个侦听套接字保留两个变量（IP地址和端口）：
FastOpenEnabled: default is off. It MUST be turned on explicitly by the application. When this flag is off, the server does not perform any TFO-related operations and MUST ignore all cookie options.
FastOpenEnabled：默认设置为关闭。它必须由应用程序显式打开。关闭此标志时，服务器不执行任何与TFO相关的操作，必须忽略所有cookie选项。
PendingFastOpenRequests: tracks the number of TFO connections in SYN-RCVD state. If this variable goes over a preset system limit, the server MUST disable TFO for all new connection requests until PendingFastOpenRequests drops below the system limit. This variable is used for defending some vulnerabilities discussed in the "Security Considerations" section (Section 5).
PendingFastOpenRequests：跟踪处于SYN-RCVD状态的TFO连接数。如果此变量超过预设的系统限制，服务器必须为所有新连接请求禁用TFO，直到PendingFastOpenRequests降至系统限制以下。此变量用于防御“安全注意事项”部分（第5节）中讨论的某些漏洞。
The server keeps a FastOpened flag per connection to mark if a connection has successfully performed a TFO.
服务器为每个连接保留一个FastOpen标志，以标记连接是否已成功执行TFO。
Any client attempting TFO MUST first request a cookie from the server with the following steps:
任何尝试TFO的客户端必须首先通过以下步骤从服务器请求cookie：
1. The client sends a SYN packet with a Fast Open option with a Length field of 0 (empty cookie field).
1. 客户端发送一个带有快速打开选项的SYN数据包，长度字段为0（空cookie字段）。
2. The server responds with a SYN-ACK based on the procedures in the "Server Cookie Handling" section (Section 4.1.2). This SYN-ACK may contain a Fast Open option if the server currently supports TFO for this listener port.
2. 服务器根据“服务器Cookie处理”一节（第4.1.2节）中的程序以SYN-ACK响应。如果服务器当前支持此侦听器端口的TFO，则此SYN-ACK可能包含快速打开选项。
3. If the SYN-ACK has a Fast Open option with a cookie, the client replaces the cookie and other information as described in the "Client Cookie Handling" section (Section 4.1.3). Otherwise, if the SYN-ACK is first seen and not a (spurious) retransmission, the client MAY remove the server information from the cookie cache. If the SYN-ACK is a spurious retransmission, the client does nothing to the cookie cache for the reasons below.
3. 如果SYN-ACK具有带cookie的快速打开选项，则客户端将替换cookie和“客户端cookie处理”部分（第4.1.3节）中所述的其他信息。否则，如果首先看到SYN-ACK而不是（虚假）重传，则客户端可能会从cookie缓存中删除服务器信息。如果SYN-ACK是一次虚假的重新传输，则客户端不会对cookie缓存进行任何操作，原因如下。
The network or servers may drop the SYN or SYN-ACK packets with the new cookie options, which will cause SYN or SYN-ACK timeouts. We RECOMMEND both the client and the server to retransmit SYN and SYN-ACK packets without the cookie options on timeouts. This ensures the
网络或服务器可能会丢弃带有新cookie选项的SYN或SYN-ACK数据包，这将导致SYN或SYN-ACK超时。我们建议客户端和服务器在超时时重新传输SYN和SYN-ACK数据包，而不使用cookie选项。这确保了
connections of cookie requests will go through and lowers the latency penalty (of dropped SYN/SYN-ACK packets). The obvious downside for maximum compatibility is that any regular SYN drop will fail the cookie (although one can argue the delay in the data transmission until after the 3WHS is justified if the SYN drop is due to network congestion). The next section describes a heuristic to detect such drops when the client receives the SYN-ACK.
cookie请求的连接将通过并降低延迟惩罚（丢弃的SYN/SYN-ACK数据包）。最大兼容性的明显缺点是，任何常规的SYN丢弃都会使cookie失败（尽管有人可能认为，如果SYN丢弃是由于网络拥塞造成的，则在3WHS之后的数据传输延迟是合理的）。下一节描述当客户端接收到SYN-ACK时检测此类丢弃的启发式方法。
We also RECOMMEND the client to record the set of servers that failed to respond to cookie requests and only attempt another cookie request after a certain period.
我们还建议客户机记录未能响应cookie请求的服务器集，并仅在一定时间后尝试另一个cookie请求。
Once the client obtains the cookie from the target server, it can perform subsequent TFO connections until the cookie is expired by the server.
一旦客户机从目标服务器获得cookie，它就可以执行后续的TFO连接，直到服务器终止cookie。
Client: Sending SYN
客户端：正在发送SYN
To open a TFO connection, the client MUST have obtained a cookie from the server:
要打开TFO连接，客户端必须已从服务器获取cookie：
1. Send a SYN packet.
1. 发送一个SYN数据包。
a. If the SYN packet does not have enough option space for the Fast Open option, abort TFO and fall back to the regular 3WHS.
a. 如果SYN数据包没有足够的选项空间用于快速打开选项，则中止TFO并退回到常规3WHS。
b. Otherwise, include the Fast Open option with the cookie of the server. Include any data up to the cached server MSS or default 536 bytes.
b. 否则，请在服务器的cookie中包含快速打开选项。包括缓存到服务器MSS或默认536字节的任何数据。
2. Advance to SYN-SENT state and update SND.NXT to include the data accordingly.
2. 前进到SYN-SENT状态并更新SND.NXT以包含相应的数据。
To deal with network or servers dropping SYN packets with payload or unknown options, when the SYN timer fires, the client SHOULD retransmit a SYN packet without data and Fast Open options.
要处理网络或服务器丢弃带有效负载或未知选项的SYN数据包，当SYN计时器启动时，客户端应重新传输不带数据和快速打开选项的SYN数据包。
Server: Receiving SYN and responding with SYN-ACK
服务器：接收SYN并使用SYN-ACK进行响应
Upon receiving the SYN packet with Fast Open option:
在接收到带有快速打开选项的SYN数据包时：
1. Initialize and reset a local FastOpened flag. If FastOpenEnabled is false, go to step 5.
1. 初始化并重置本地快速打开标志。如果FastOpenEnabled为false，请转至步骤5。
2. If PendingFastOpenRequests is over the system limit, go to step 5.
2. 如果PendingFastOpenRequests超过系统限制，请转至步骤5。
3. If IsCookieValid() (in Section 4.1.2) returns false, go to step 5.
3. 如果IsCookieValid（）（在第4.1.2节中）返回false，请转至步骤5。
4. Buffer the data and notify the application. Set the FastOpened flag and increment PendingFastOpenRequests.
4. 缓冲数据并通知应用程序。设置FastOpen标志和增量PendingFastOpenRequests。
5. Send the SYN-ACK packet. The packet MAY include a Fast Open option. If the FastOpened flag is set, the packet acknowledges the SYN and data sequence. Otherwise, it acknowledges only the SYN sequence. The server MAY include data in the SYN-ACK packet if the response data is readily available. Some applications may favor delaying the SYN-ACK, allowing the application to process the request in order to produce a response, but this is left up to the implementation.
5. 发送SYN-ACK数据包。该分组可以包括快速打开选项。如果设置了FastOpen标志，则数据包确认SYN和数据序列。否则，它只确认SYN序列。如果响应数据随时可用，则服务器可以在SYN-ACK分组中包括数据。一些应用程序可能倾向于延迟SYN-ACK，允许应用程序处理请求以产生响应，但这取决于实现。
6. Advance to the SYN-RCVD state. If the FastOpened flag is set, the server MUST follow [RFC5681] (based on [RFC3390]) to set the initial congestion window for sending more data packets.
6. 进入SYN-RCVD状态。如果设置了FastOpen标志，服务器必须遵循[RFC5681]（基于[RFC3390]）设置初始拥塞窗口以发送更多数据包。
If the SYN-ACK timer fires, the server SHOULD retransmit a SYN-ACK segment with neither data nor Fast Open options for compatibility reasons.
如果触发SYN-ACK计时器，出于兼容性原因，服务器应重新传输既没有数据也没有快速打开选项的SYN-ACK段。
A special case is simultaneous open where the SYN receiver is a client in SYN-SENT state. The protocol remains the same because [RFC793] already supports both data in the SYN and simultaneous open. But the client's socket may have data available to read before it's connected. This document does not cover the corresponding API change.
一种特殊情况是同时打开，其中SYN接收器是处于SYN-SENT状态的客户端。协议保持不变，因为[RFC793]已经支持SYN中的数据和同时打开的数据。但是客户端的套接字在连接之前可能有可读取的数据。本文件不包括相应的API变更。
Client: Receiving SYN-ACK
客户端：接收SYN-ACK
The client SHOULD perform the following steps upon receiving the SYN-ACK:
客户端在收到SYN-ACK后应执行以下步骤：
1. If the SYN-ACK has a Fast Open option, an MSS option, or both, update the corresponding cookie and MSS information in the cookie cache.
1. 如果SYN-ACK具有快速打开选项、MSS选项或两者，则更新cookie缓存中相应的cookie和MSS信息。
2. Send an ACK packet. Set acknowledgment number to RCV.NXT and include the data after SND.UNA if data is available.
2. 发送一个ACK数据包。将确认号设置为RCV.NXT，如果数据可用，则在SND.UNA之后包含数据。
3. Advance to the ESTABLISHED state.
3. 进入既定状态。
Note there is no latency penalty if the server does not acknowledge the data in the original SYN packet. The client SHOULD retransmit any unacknowledged data in the first ACK packet in step 2. The data exchange will start after the handshake like a regular TCP connection.
注意：如果服务器不确认原始SYN数据包中的数据，则没有延迟惩罚。在步骤2中，客户端应重新传输第一个ACK数据包中的任何未确认数据。数据交换将在握手后开始，就像常规TCP连接一样。
If the client has timed out and retransmitted only regular SYN packets, it can heuristically detect paths that intentionally drop SYNs with the Fast Open option or data. If the SYN-ACK acknowledges only the initial sequence and does not carry a Fast Open cookie option, presumably it is triggered by a retransmitted (regular) SYN and the original SYN or the corresponding SYN-ACK was lost.
如果客户端超时并仅重新传输常规SYN数据包，它可以试探性地检测有意使用Fast Open选项或数据丢弃SYN的路径。如果SYN-ACK仅确认初始序列，并且不携带快速打开cookie选项，则可能是由重新传输的（常规）SYN触发的，并且原始SYN或相应的SYN-ACK丢失。
Server: Receiving ACK
服务器：正在接收ACK
Upon receiving an ACK acknowledging the SYN sequence, the server decrements PendingFastOpenRequests and advances to the ESTABLISHED state. No special handling is required further.
在接收到确认SYN序列的ACK后，服务器减少PendingFastOpenRequests并进入已建立状态。无需进一步特殊处理。
The Fast Open Cookie stops an attacker from trivially flooding spoofed SYN packets with data to burn server resources or to mount an amplified reflection attack on random hosts. The server can defend against spoofed SYN floods with invalid cookies using existing techniques [RFC4987]. We note that although generating bogus cookies is cost free, the cost of validating the cookies, inherent to any authentication scheme, may be substantial compared to processing a regular SYN packet. We describe these new vulnerabilities of TFO and the countermeasures in detail below.
Fast Open Cookie可阻止攻击者以数据淹没伪造的SYN数据包，从而烧毁服务器资源或在随机主机上发起放大反射攻击。服务器可以使用现有技术防止使用无效cookie欺骗SYN洪水[RFC4987]。我们注意到，尽管生成虚假cookie是免费的，但是与处理常规SYN数据包相比，验证cookie的成本（任何身份验证方案固有的）可能是巨大的。我们将在下文详细描述TFO的这些新漏洞和应对措施。
An attacker may still obtain cookies from some compromised hosts, then flood spoofed SYN packets with data and "valid" cookies (from these hosts or other vantage points). Like regular TCP handshakes, TFO is vulnerable to such an attack. But the potential damage can be much more severe. Besides causing temporary disruption to service ports under attack, it may exhaust server CPU and memory resources. Such an attack will show up on application server logs as an application-level DoS from botnets, triggering other defenses and alerts.
攻击者仍可能从某些受损主机获取cookie，然后用数据和“有效”cookie（从这些主机或其他有利位置）淹没伪造的SYN数据包。与常规TCP握手一样，TFO也容易受到此类攻击。但潜在的损害可能要严重得多。除了对受攻击的服务端口造成暂时中断外，它还可能耗尽服务器CPU和内存资源。此类攻击将在应用程序服务器日志上显示为来自僵尸网络的应用程序级DoS，触发其他防御和警报。
To protect the server, it is important to limit the maximum number of total pending TFO connection requests, i.e., PendingFastOpenRequests (Section 4.2). When the limit is exceeded, the server temporarily disables TFO entirely as described in "Server Cookie Handling" (Section 4.1.2). Then, subsequent TFO requests will be downgraded to regular connection requests, i.e., with the data dropped and only SYNs acknowledged. This allows regular SYN flood defense techniques [RFC4987] like SYN cookies to kick in and prevent further service disruption.
为了保护服务器，必须限制挂起的TFO连接请求的最大总数，即挂起的FastOpenRequests（第4.2节）。当超过该限制时，服务器将按照“服务器Cookie处理”（第4.1.2节）中的说明暂时完全禁用TFO。然后，随后的TFO请求将降级为常规连接请求，即，删除数据并且只确认SYN。这使得常规的SYN洪水防御技术[RFC4987]如SYN Cookie能够启动并防止进一步的服务中断。
The main impact of SYN floods against the standard TCP stack is not directly from the floods themselves costing TCP processing overhead or host memory, but rather from the spoofed SYN packets filling up the often small listener's queue.
SYN洪泛对标准TCP堆栈的主要影响不是直接来自洪泛本身造成的TCP处理开销或主机内存成本，而是来自填满通常较小的侦听器队列的伪造SYN数据包。
On the other hand, TFO SYN floods can cause damage directly if admitted without limit into the stack. The reset (RST) packets from the spoofed host will fuel rather than defeat the SYN floods as compared to the non-TFO case, because the attacker can flood more SYNs with data and incur more cost in terms of data processing resources. For this reason, a TFO server needs to monitor the connections in SYN-RCVD being reset in addition to imposing a reasonable max queue length. Implementations may combine the two, e.g., by continuing to account for those connection requests that have just been reset against the listener's PendingFastOpenRequests until a timeout period has passed.
另一方面，如果无限制进入烟囱，TFO SYN洪水会直接造成损害。与非TFO情况相比，来自欺骗主机的重置（RST）数据包将助长而不是挫败SYN洪水，因为攻击者可以用数据淹没更多SYN，并在数据处理资源方面产生更多成本。出于这个原因，TFO服务器需要监控SYN-RCVD中正在重置的连接，此外还需要施加合理的最大队列长度。实现可以将两者结合起来，例如，通过继续说明那些刚刚根据侦听器的PendingFastOpenRequests重置的连接请求，直到超时时间过去。
Limiting the maximum number of pending TFO connection requests does make it easy for an attacker to overflow the queue, causing TFO to be disabled. We argue that causing TFO to be disabled is unlikely to be of interest to attackers because the service will remain intact without TFO; hence, there is hardly any real damage.
限制挂起TFO连接请求的最大数量确实会使攻击者很容易使队列溢出，从而导致TFO被禁用。我们认为，攻击者不太可能对禁用TFO感兴趣，因为没有TFO，服务将保持完整；因此，几乎没有任何真正的损害。
An attacker behind a NAT can easily obtain valid cookies to launch the above attack to hurt other clients that share the path. [BRISCOE12] suggested that the server can extend cookie generation to include the TCP timestamp -- GetCookie(IP_Address, Timestamp) -- and implement it by encrypting the concatenation of the two values to generate the cookie. The client stores both the cookie and its corresponding timestamp, and it echoes both in the SYN. The server then implements IsCookieValid(IP_Address, Timestamp, Cookie) by encrypting the IP and timestamp data and comparing it with the cookie value.
NAT背后的攻击者可以轻松获取有效的cookie，以发起上述攻击，从而伤害共享该路径的其他客户端。[BRISCOE12]建议服务器可以扩展cookie生成，以包括TCP时间戳——GetCookie（IP_地址，时间戳）——并通过加密两个值的串联来生成cookie来实现。客户机同时存储cookie及其相应的时间戳，并在SYN中对两者进行回响。然后，服务器通过加密IP和时间戳数据并将其与Cookie值进行比较来实现IsCookieValid（IP_地址、时间戳、Cookie）。
This enables the server to issue different cookies to clients that share the same IP address; hence, it can selectively discard those misused cookies from the attacker. However, the attacker can simply repeat the attack with new cookies. The server would eventually need to throttle all requests from the IP address just like the current approach. Moreover, this approach requires modifying [RFC1323] (obsoleted by [RFC7323]) to send a non-zero Timestamp Echo Reply in the SYN, potentially causing firewall issues. Therefore, we believe the benefit does not outweigh the drawbacks.
这使服务器能够向共享相同IP地址的客户端发出不同的cookie；因此，它可以有选择地从攻击者处丢弃那些误用的cookie。但是，攻击者可以简单地使用新cookie重复攻击。服务器最终需要限制来自IP地址的所有请求，就像当前的方法一样。此外，这种方法需要修改[RFC1323]（已被[RFC7323]淘汰）以在SYN中发送非零时间戳回送回复，这可能会导致防火墙问题。因此，我们认为利大于弊。
Limiting PendingFastOpenRequests with a system limit can be done without Fast Open cookies and would protect the server from resource exhaustion. It would also limit how much damage an attacker can cause through an amplified reflection attack from that server. However, it would still be vulnerable to an amplified reflection attack from a large number of servers. An attacker can easily cause damage by tricking many servers to respond with data packets at once to any spoofed victim IP address of choice.
使用系统限制限制PendingFastOpenRequests可以在没有Fast Open Cookie的情况下完成，这将保护服务器免受资源耗尽的影响。它还将限制攻击者通过来自该服务器的放大反射攻击造成的伤害。但是，它仍然容易受到来自大量服务器的放大反射攻击。攻击者可以通过诱骗多台服务器立即用数据包响应所选的任何伪造的受害者IP地址，从而很容易造成损害。
With the use of Fast Open cookies, the attacker would first have to steal a valid cookie from its target victim. This likely requires the attacker to compromise the victim host or network first. But, in some cases, it may be relatively easy.
使用Fast Open cookie，攻击者首先必须从其目标受害者处窃取有效的cookie。这可能需要攻击者首先危害受害者主机或网络。但是，在某些情况下，这可能相对容易。
The attacker here has little interest in mounting an attack on the victim host that has already been compromised. But it may be motivated to disrupt the victim's network. Since a stolen cookie is only valid for a single server, it has to steal valid cookies from a large number of servers and use them before they expire to cause sufficient damage without triggering the defense.
这里的攻击者对在已被破坏的受害主机上发起攻击兴趣不大。但它可能是为了破坏受害者的网络。由于被盗的cookie仅对单个服务器有效，因此它必须从大量服务器中窃取有效cookie，并在其过期之前使用这些cookie，以便在不触发防御的情况下造成足够的损害。
One can argue that if the attacker has compromised the target network or hosts, it could perform a similar but simpler attack by injecting bits directly. The degree of damage will be identical, but a TFO-specific attack allows the attacker to remain anonymous and disguises the attack as from other servers.
有人可能会说，如果攻击者破坏了目标网络或主机，它可以通过直接注入比特来执行类似但更简单的攻击。破坏程度相同，但特定于TFO的攻击允许攻击者保持匿名，并将攻击伪装为来自其他服务器的攻击。
For example, with DHCP, an attacker can obtain cookies when he (or the host he has compromised) owns a particular IP address by performing regular Fast Open to servers supporting TFO and he can collect valid cookies. Then, the attacker actively or passively releases his IP address. When the IP address is reassigned to another host (victim) via DHCP, the attacker then floods spoofed Fast Open requests with valid cookies to the servers. Since the cookies are valid, these servers accept the requests and respond with a SYN-ACK plus data packets to the victim instead of the attacker. Thus, the attacker is able to launch amplified reflection attacks to other hosts that share IP addresses.
例如，使用DHCP，攻击者可以通过对支持TFO的服务器执行定期快速打开，在他（或他已泄露的主机）拥有特定IP地址时获取Cookie，并且可以收集有效的Cookie。然后，攻击者主动或被动释放其IP地址。当IP地址通过DHCP重新分配给另一台主机（受害者）时，攻击者随后向服务器发送带有有效cookie的欺骗快速打开请求。由于Cookie是有效的，这些服务器接受请求并向受害者而不是攻击者发送SYN-ACK和数据包。因此，攻击者能够对共享IP地址的其他主机发起放大反射攻击。
The best defense is for the server not to respond with data until the handshake finishes. In this case, the risk of an amplification reflection attack is completely eliminated. But the potential latency saving from TFO may diminish if the server application produces responses earlier before the handshake completes.
最好的防御措施是服务器在握手结束之前不响应数据。在这种情况下，完全消除了放大反射攻击的风险。但是，如果服务器应用程序在握手完成之前提前生成响应，则TFO节省的潜在延迟可能会减少。
This section is to help applications considering TFO to evaluate TFO's benefits and drawbacks using the Web client and server applications as an example throughout. Applications here refer specifically to the process that writes data into the socket -- for example, a JavaScript process that sends data to the server. A proposed socket API change is provided in the Appendix.
本节以Web客户端和服务器应用程序为例，帮助考虑TFO的应用程序评估TFO的优点和缺点。这里的应用程序专门指将数据写入套接字的进程——例如，向服务器发送数据的JavaScript进程。附录中提供了建议的套接字API更改。
It is possible that using TFO results in the first data written to a socket to be delivered more than once to the application on the remote host (Section 2.1). This replay potential only applies to data in the SYN but not subsequent data exchanges.
使用TFO可能会导致写入套接字的第一个数据多次传递到远程主机上的应用程序（第2.1节）。这种重播可能性仅适用于SYN中的数据，而不适用于后续的数据交换。
Empirically, [JIDKT07] showed the packet duplication on a Tier-1 network is rare. Since the replay only happens specifically when the SYN data packet is duplicated and also the duplicate arrives after the receiver has cleared the original SYN's connection state, the replay is thought to be uncommon in practice. Nevertheless, a client that cannot handle receiving the same SYN data more than once MUST NOT enable TFO to send data in a SYN. Similarly, a server that cannot accept receiving the same SYN data more than once MUST NOT enable TFO to receive data in a SYN. Further investigation is needed to judge the probability of receiving duplicated SYN or SYN-ACK packets with data in networks that are not Tier 1.
根据经验，[JIDKT07]表明，在第1层网络上，数据包复制是罕见的。由于重放仅在SYN数据包被复制时发生，并且在接收器清除原始SYN的连接状态之后，重放也到达，因此重放在实践中被认为是不常见的。然而，不能多次接收同一SYN数据的客户机不能使TFO在SYN中发送数据。类似地，不能接受多次接收同一SYN数据的服务器不得允许TFO在SYN中接收数据。需要进一步调查，以判断在非第1层的网络中使用数据接收重复的SYN或SYN-ACK数据包的概率。
TFO is designed for latency-conscious applications that are sensitive to TCP's initial connection setup delay. To benefit from TFO, the first application data unit (e.g., an HTTP request) needs to be no more than TCP's maximum segment size (minus options used in the SYN). Otherwise, the remote server can only process the client's application data unit once the rest of it is delivered after the initial handshake, diminishing TFO's benefit.
TFO设计用于对TCP初始连接设置延迟敏感的延迟敏感应用程序。为了从TFO中获益，第一个应用程序数据单元（例如HTTP请求）需要不超过TCP的最大段大小（减去SYN中使用的选项）。否则，远程服务器只能在初始握手后交付客户机的其余应用程序数据单元后处理该应用程序数据单元，这会降低TFO的好处。
To the extent possible, applications SHOULD reuse the connection to take advantage of TCP's built-in congestion control and reduce connection setup overhead. An application that employs too many short-lived connections will negatively impact network stability, as these connections often exit before TCP's congestion control algorithm takes effect.
在可能的范围内，应用程序应该重用连接以利用TCP内置的拥塞控制并减少连接设置开销。使用过多短命连接的应用程序将对网络稳定性产生负面影响，因为这些连接通常在TCP拥塞控制算法生效之前退出。
While TFO is motivated by Web applications, the browser should not use TFO to send requests in SYNs if those requests cannot tolerate replays. One example is POST requests without application-layer transaction protection (e.g., a unique identifier in the request header).
虽然TFO是由Web应用程序驱动的，但如果这些请求不能容忍重播，则浏览器不应使用TFO在SYN中发送请求。一个例子是没有应用层事务保护的POST请求（例如，请求头中的唯一标识符）。
On the other hand, TFO is particularly useful for GET requests. GET request replay could happen across striped TCP connections: after a server receives an HTTP request but before the ACKs of the requests reach the browser, the browser may time out and retry the same request on another (possibly new) TCP connection. This differs from a TFO replay only in that the replay is initiated by the browser, not by the TCP stack.
另一方面，TFO对于GET请求特别有用。获取请求重播可能会跨条带化TCP连接进行：在服务器收到HTTP请求后，但在请求的ACK到达浏览器之前，浏览器可能会超时，并在另一个（可能是新的）TCP连接上重试相同的请求。这与TFO重播的不同之处在于重播是由浏览器启动的，而不是由TCP堆栈启动的。
For Transport Layer Security (TLS) over TCP, it is safe and useful to include a TLS client_hello in the SYN packet to save one RTT in the TLS handshake. There is no concern about violating idempotency. In particular, it can be used alone with the speculative connection above.
对于TCP上的传输层安全性（TLS），在SYN数据包中包含一个TLS客户端_hello以在TLS握手中保存一个RTT是安全且有用的。不必担心违反幂等性。特别是，它可以单独与上面的推测连接一起使用。
Is TFO useful given the wide deployment of HTTP persistent connections? The short answer is yes. Studies ([RCCJR11] [AERG11]) show that the average number of transactions per connection is between 2 and 4, based on large-scale measurements from both servers and clients. In these studies, the servers and clients both kept idle connections up to several minutes, well into "human think" time.
考虑到HTTP持久连接的广泛部署，TFO有用吗？简而言之，答案是肯定的。研究（[RCCJR11][AERG11]）表明，基于服务器和客户端的大规模测量，每个连接的平均事务数在2到4之间。在这些研究中，服务器和客户机都保持空闲连接长达几分钟，这已经进入了“人类思考”时间。
Keeping connections open and idle even longer risks a greater performance penalty. [HNESSK10] and [MQXMZ11] show that the majority of home routers and ISPs fail to meet the 124-minute idle timeout mandated in [RFC5382]. In [MQXMZ11], 35% of mobile ISPs silently time out idle connections within 30 minutes. End hosts, unaware of silent middlebox timeouts, suffer multi-minute TCP timeouts upon using those long-idle connections.
保持连接打开和空闲的时间更长可能会带来更大的性能损失。[HNESSK10]和[MQXMZ11]表明，大多数家庭路由器和ISP无法满足[RFC5382]中规定的124分钟空闲超时。在[MQXMZ11]中，35%的移动ISP在30分钟内静默超时空闲连接。终端主机不知道无提示的中间盒超时，在使用这些长空闲连接时会遭受多分钟的TCP超时。
To circumvent this problem, some applications send frequent TCP keep-alive probes. However, this technique drains power on mobile devices [MQXMZ11]. In fact, power has become such a prominent issue in modern Long Term Evolution (LTE) devices that mobile browsers close HTTP connections within seconds or even immediately [SOUDERS11].
为了避免这个问题，一些应用程序发送频繁的TCP保持活动探测。然而，这种技术会消耗移动设备的电力[MQXMZ11]。事实上，电源已经成为现代长期演进（LTE）设备中的一个突出问题，移动浏览器在几秒钟内甚至立即关闭HTTP连接[SOUDERS11]。
[RCCJR11] studied the performance of the Chrome browser [Chrome] based on 28 days of global statistics. The Chrome browser keeps idle HTTP persistent connections for 5 to 10 minutes. However, the average number of the transactions per connection is only 3.3, and the TCP 3WHS accounts for up to 25% of the HTTP transaction network latency. The authors estimated that TFO improves page load time by 10% to 40% on selected popular Web sites.
[RCCJR11]根据28天的全球统计数据研究了Chrome浏览器[Chrome]的性能。Chrome浏览器将空闲HTTP持久连接保持5到10分钟。然而，每个连接的平均事务数只有3.3，TCP 3WHS占HTTP事务网络延迟的25%。作者们估计，在选定的热门网站上，TFO将页面加载时间缩短了10%到40%。
Servers behind load balancers that accept connection requests to the same server IP address should use the same key such that they generate identical Fast Open cookies for a particular client IP address. Otherwise, a client may get different cookies across connections; its Fast Open attempts would fall back to the regular 3WHS.
负载平衡器后面的服务器接受到相同服务器IP地址的连接请求，它们应该使用相同的密钥，以便为特定客户端IP地址生成相同的快速打开cookie。否则，客户端可能会跨连接获得不同的cookie；它的快速开放尝试将回落到常规的3WH。
We now outline some areas that need experimentation in the Internet and under different network scenarios. These experiments should help evaluate Fast Open benefits and risks and its related protocols.
我们现在概述了一些需要在互联网和不同网络场景下进行实验的领域。这些实验应有助于评估快速开放的好处和风险及其相关协议。
[MAF04] found that some middleboxes and end hosts may drop packets with unknown TCP options. Studies ([LANGLEY06] [HNRGHT11]) have found that 6% of the probed paths on the Internet drop SYN packets with data or with unknown TCP options. The TFO protocol deals with this problem by falling back to the regular TCP handshake and retransmitting the SYN without data or cookie options after the initial SYN timeout. Moreover, the implementation is recommended to negatively cache such incidents to avoid recurring timeouts. Further study is required to evaluate the performance impact of these drop behaviors.
[MAF04]发现一些中间盒和终端主机可能丢弃具有未知TCP选项的数据包。研究（[LANGLEY06][HNRGHT11]）发现，互联网上6%的探测路径丢弃带有数据或未知TCP选项的SYN数据包。TFO协议通过退回到常规TCP握手并在初始SYN超时后在没有数据或cookie选项的情况下重新传输SYN来处理此问题。此外，建议实现对此类事件进行负面缓存，以避免重复出现超时。需要进一步研究，以评估这些跌落行为对性能的影响。
Another interesting study is the loss of TFO performance benefit behind certain Carrier-Grade NAT (CGN). Typically, hosts behind a NAT sharing the same IP address will get the same cookie for the same server. This will not prevent TFO from working. But, on some CGN configurations where every new TCP connection from the same physical host uses a different public IP address, TFO does not provide latency benefits. However, there is no performance penalty either, as described in the "Client: Receiving SYN-ACK" text in Section 4.2.2.
另一个有趣的研究是某些载波级NAT（CGN）背后TFO性能优势的损失。通常，共享相同IP地址的NAT后面的主机将为同一服务器获得相同的cookie。这不会阻止TFO工作。但是，在某些CGN配置中，来自同一物理主机的每个新TCP连接使用不同的公共IP地址，TFO不提供延迟优势。但是，如第4.2.2节“客户机：接收SYN-ACK”文本所述，也没有性能损失。
Although TFO does not directly change TCP's congestion control, there are subtle cases where it could do so. When a SYN-ACK times out, regular TCP reduces the initial congestion window before sending any data [RFC5681]. However, in TFO, the server may have already sent up to an initial window of data.
虽然TFO不会直接改变TCP的拥塞控制，但在一些微妙的情况下它可以这样做。当SYN-ACK超时时，常规TCP在发送任何数据之前减少初始拥塞窗口[RFC5681]。但是，在TFO中，服务器可能已经发送到初始数据窗口。
If the server serves mostly short connections, then the losses of SYN-ACKs are not as effective as regular TCP on reducing the congestion window. This could result in an unstable network condition. The connections that experience losses may attempt again and add more load under congestion. A potential solution is to temporarily disable Fast Open if the server observes many SYN-ACK or data losses during the handshake across connections. Further experimentation regarding the congestion control impact will be useful.
如果服务器主要提供短连接，那么SYN ACK的丢失在减少拥塞窗口方面不如常规TCP有效。这可能导致网络状况不稳定。遇到损失的连接可能会再次尝试，并在拥塞情况下增加更多负载。一个潜在的解决方案是，如果服务器在连接之间的握手过程中观察到许多SYN-ACK或数据丢失，则临时禁用Fast Open。关于拥塞控制影响的进一步实验将是有用的。
The cookie mechanism mitigates resource exhaustion and amplification attacks. However, cookies are not necessary if the server has application-level protection or is immune to these attacks. For example, a Web server that only replies with a simple HTTP redirect response that fits in the SYN-ACK packet may not care about resource exhaustion.
cookie机制缓解了资源耗尽和放大攻击。但是，如果服务器具有应用程序级保护或对这些攻击免疫，则不需要cookie。例如，仅使用适合SYN-ACK数据包的简单HTTP重定向响应进行响应的Web服务器可能不关心资源耗尽。
For such applications the server may choose to generate a trivial or even a zero-length cookie to improve performance by avoiding the cookie generation and verification. If the server believes it's under a DoS attack through other defense mechanisms, it can switch to regular Fast Open for listener sockets.
对于这样的应用程序，服务器可以选择生成一个普通的甚至是零长度的cookie，以通过避免cookie的生成和验证来提高性能。如果服务器认为它通过其他防御机制受到DoS攻击，它可以切换到常规快速打开侦听器套接字。
TCP Extensions for Transactions [RFC1644] attempted to bypass the 3WHS, among other things; hence, it shared the same goal but also the same set of issues as TFO. It focused most of its effort battling old or duplicate SYNs, but paid no attention to security vulnerabilities it introduced when bypassing the 3WHS [PHRACK98].
用于事务的TCP扩展[RFC1644]试图绕过3WH等；因此，它与TFO有着相同的目标，但也有着相同的问题。它将大部分精力集中在对付旧的或重复的SYN上，但没有注意绕过3WHS时引入的安全漏洞[PHRACK98]。
As stated earlier, we take a practical approach to focus TFO on the security aspect, while allowing old, duplicate SYN packets with data after recognizing that 100% TCP semantics is likely infeasible. We believe this approach strikes the right trade-off and makes TFO much simpler and more appealing to TCP implementers and users.
如前所述，我们采取了一种实用的方法将TFO重点放在安全方面，同时在认识到100%TCP语义可能不可行之后，允许使用旧的、重复的SYN数据包。我们相信这种方法找到了正确的平衡点，使TFO更简单，对TCP实现者和用户更具吸引力。
[RFC4987] studies the mitigation of attacks from regular SYN floods, i.e., SYNs without data. But from the stateless SYN cookies to the stateful SYN Cache, none can preserve data sent with SYNs safely while still providing an effective defense.
[RFC4987]研究常规SYN洪水（即没有数据的SYN）的攻击缓解。但是，从无状态SYN cookies到有状态SYN缓存，没有一个能够在提供有效防御的同时安全地保存与SYN一起发送的数据。
The best defense may be simply to disable TFO when a host is suspected to be under a SYN flood attack, e.g., the SYN backlog is filled. Once TFO is disabled, normal SYN flood defenses can be applied. The "Security Considerations" section (Section 5) contains a thorough discussion on this topic.
最好的防御措施可能只是在主机被怀疑受到SYN洪水攻击时禁用TFO，例如，SYN积压已满。一旦TFO被禁用，可以应用正常的SYN洪水防御。“安全注意事项”一节（第5节）对此主题进行了深入讨论。
Some Web browsers maintain a history of the domains for frequently visited Web pages. The browsers then speculatively pre-open TCP connections to these domains before the user initiates any requests for them [BELSHE11]. While this technique also saves the handshake latency, it wastes server and network resources by initiating and maintaining idle connections.
一些Web浏览器维护经常访问的Web页面的域历史记录。然后，浏览器会在用户发起任何请求之前，推测性地预先打开到这些域的TCP连接[BELSHE11]。虽然这项技术还节省了握手延迟，但它通过启动和维护空闲连接浪费了服务器和网络资源。
An alternate proposal is to request a TFO cookie in the FIN instead, since FIN-drop by incompatible middleboxes does not affect latency. However, paths that block SYN cookies may be more likely to drop a later SYN packet with data, and many applications close a connection with RST instead anyway.
另一种建议是在FIN中请求TFO cookie，因为不兼容的中间盒丢弃FIN不会影响延迟。但是，阻止SYN Cookie的路径可能更可能丢弃包含数据的较新SYN数据包，并且许多应用程序无论如何都会关闭与RST的连接。
Although cookie-in-FIN may not improve robustness, it would give clients using a single connection a latency advantage over clients opening multiple parallel connections. If experiments with TFO find that it leads to increased connection-sharding, cookie-in-FIN may prove to be a useful alternative.
尽管FIN中的cookie可能不会提高健壮性，但它会使使用单个连接的客户端比打开多个并行连接的客户端具有延迟优势。如果TFO的实验发现它会增加连接切分，那么FIN中的cookie可能是一个有用的替代方案。
TCPCT [RFC6013] eliminates server state during the initial handshake and defends spoofing DoS attacks. Like TFO, TCPCT allows SYN and SYN-ACK packets to carry data. But the server can only send up to MSS bytes of data during the handshake instead of the initial congestion window, unlike TFO. Therefore, the latency of applications (e.g., Web applications) may be worse than with TFO.
TCPCT[RFC6013]在初始握手期间消除服务器状态，并防御欺骗DoS攻击。与TFO一样，TCPCT允许SYN和SYN-ACK数据包携带数据。但与TFO不同的是，服务器在握手过程中最多只能发送MSS字节的数据，而不是初始拥塞窗口。因此，应用程序（例如Web应用程序）的延迟可能比TFO更差。
IANA has allocated one value, 34, in the "TCP Option Kind Numbers" registry. See Section 4.1.1. The length of this new TCP option is variable, and the Meaning as shown in the "TCP Option Kind Numbers" registry is set to "TCP Fast Open Cookie". Current and new implementations SHOULD use option (34). Existing implementations that are using experimental option 254 per [RFC6994] with magic number 0xF989 (16 bits) as allocated in the IANA "TCP Experimental Option Experiment Identifiers (TCP ExIDs)" registry by this document, SHOULD migrate to use this new option (34) by default.
IANA在“TCP选项种类号”注册表中分配了一个值34。见第4.1.1节。这个新TCP选项的长度是可变的，“TCP选项种类号”注册表中显示的含义设置为“TCP快速打开Cookie”。当前和新的实现应该使用选项（34）。按照本文档在IANA“TCP实验选项实验标识符（TCP ExIDs）”注册表中分配的幻数为0xF989（16位）的[RFC6994]使用实验选项254的现有实现，默认情况下应迁移到使用此新选项（34）。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981, <http://www.rfc-editor.org/info/rfc793>.
[RFC793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月<http://www.rfc-editor.org/info/rfc793>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989, <http://www.rfc-editor.org/info/rfc1122>.
[RFC1122]Braden，R.，Ed.“互联网主机的要求-通信层”，STD 3，RFC 1122，1989年10月<http://www.rfc-editor.org/info/rfc1122>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's Initial Window", RFC 3390, October 2002, <http://www.rfc-editor.org/info/rfc3390>.
[RFC3390]奥尔曼，M.，弗洛伊德，S.和C.帕特里奇，“增加TCP的初始窗口”，RFC3902002年10月<http://www.rfc-editor.org/info/rfc3390>.
[RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008, <http://www.rfc-editor.org/info/rfc5382>.
[RFC5382]Guha，S.，Ed.，Biswas，K.，Ford，B.，Sivakumar，S.，和P.Srisuresh，“TCP的NAT行为要求”，BCP 142，RFC 5382，2008年10月<http://www.rfc-editor.org/info/rfc5382>.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, September 2009, <http://www.rfc-editor.org/info/rfc5681>.
[RFC5681]Allman，M.，Paxson，V.和E.Blanton，“TCP拥塞控制”，RFC 56812009年9月<http://www.rfc-editor.org/info/rfc5681>.
[RFC6994] Touch, J., "Shared Use of Experimental TCP Options", RFC 6994, August 2013, <http://www.rfc-editor.org/info/rfc6994>.
[RFC6994]Touch，J.，“实验TCP选项的共享使用”，RFC 69942013年8月<http://www.rfc-editor.org/info/rfc6994>.
[AERG11] Al-Fares, M., Elmeleegy, K., Reed, B., and I. Gashinsky, "Overclocking the Yahoo! CDN for Faster Web Page Loads", in Proceedings of Internet Measurement Conference, November 2011.
[AERG11]Al Fares，M.，Elmelegy，K.，Reed，B.，和I.Gashinsky，“超频Yahoo！CDN以实现更快的网页加载”，《互联网测量会议记录》，2011年11月。
[BELSHE11] Belshe, M., "The Era of Browser Preconnect", February 2011, <http://www.belshe.com/2011/02/10/ the-era-of-browser-preconnect/>.
[BELSHE11]Belshe，M.，“浏览器预连接时代”，2011年2月<http://www.belshe.com/2011/02/10/ 浏览器预连接/>的时代。
[BRISCOE12] Briscoe, B., "Some ideas building on draft-ietf-tcpm-fastopen-01", message to the tcpm mailing list, July 2012, <http://www.ietf.org/mail-archive/ web/tcpm/current/msg07192.html>.
[BRISCOE12]Briscoe，B.，“基于草案-ietf-tcpm-fastopen-01的一些想法”，给tcpm邮件列表的信息，2012年7月<http://www.ietf.org/mail-archive/ web/tcpm/current/msg07192.html>。
[Chrome] Google Chrome, <https://www.google.com/intl/en-US/chrome/browser/>.
[Chrome]谷歌浏览器<https://www.google.com/intl/en-US/chrome/browser/>.
[HNESSK10] Haetoenen, S., Nyrhinen, A., Eggert, L., Strowes, S., Sarolahti, P., and M. Kojo, "An Experimental Study of Home Gateway Characteristics", in Proceedings of Internet Measurement Conference, October 2010.
[HNESSK10]Haetoenen，S.，Nyrhinen，A.，Eggert，L.，Strowes，S.，Sarolahti，P.，和M.Kojo，“家庭网关特性的实验研究”，互联网测量会议记录，2010年10月。
[HNRGHT11] Honda, M., Nishida, Y., Raiciu, C., Greenhalgh, A., Handley, M., and H. Tokuda, "Is it Still Possible to Extend TCP?", in Proceedings of Internet Measurement Conference, November 2011.
[HNRGHT11]本田，M.，西田，Y.，雷丘，C.，格林哈勒，A.，汉德利，M.，和H.德田，“是否仍然有可能扩展TCP？”，载于《互联网测量会议记录》，2011年11月。
[JIDKT07] Jaiswal, S., Iannaccone, G., Diot, C., Kurose, J., and D. Towsley, "Measurement and Classification of Out-of-Sequence Packets in a Tier-1 IP Backbone" IEEE/ACM Transactions on Networking (TON), Volume 15, Issue 1, pp 54-66.
[JIDKT07]Jaiswal，S.，Iannacone，G.，Diot，C.，Kurose，J.，和D.Towsley，“一级IP主干网中无序数据包的测量和分类”，IEEE/ACM网络事务（TON），第15卷，第1期，第54-66页。
[LANGLEY06] Langley, A., "Probing the viability of TCP extensions", <http://www.imperialviolet.org/binary/ecntest.pdf>.
[LANGLEY06]Langley，A.，“探索TCP扩展的可行性”<http://www.imperialviolet.org/binary/ecntest.pdf>.
[MAF04] Medina, A., Allman, M., and S. Floyd, "Measuring Interactions Between Transport Protocols and Middleboxes", in Proceedings of Internet Measurement Conference, October 2004.
[MAF04]Medina，A.，Allman，M.，和S.Floyd，“测量传输协议和中间盒之间的相互作用”，互联网测量会议记录，2004年10月。
[MQXMZ11] Wang, Z., Qian, Z., Xu, Q., Mao, Z., and M. Zhang, "An Untold Story of Middleboxes in Cellular Networks", in Proceedings of SIGCOMM, August 2011.
[MQXMZ11]Wang，Z.，Qian，Z.，Xu，Q.，Mao，Z.，和M.Zhang，“蜂窝网络中的中间盒的不为人知的故事”，载于SIGCOMM学报，2011年8月。
[PHRACK98] "T/TCP vulnerabilities", Phrack Magazine, Volume 8, Issue 53, Article 6, July 8, 1998, <http://www.phrack.com/issues.html?issue=53&id=6>.
[PHRACK98]“T/TCP漏洞”，Phrack杂志，第8卷，第53期，第6条，1998年7月8日<http://www.phrack.com/issues.html?issue=53&id=6>.
[RCCJR11] Radhakrishnan, S., Cheng, Y., Chu, J., Jain, A., and B. Raghavan, "TCP Fast Open", in Proceedings of the 7th ACM CoNEXT Conference, December 2011.
[RCCJR11]Radhakrishnan，S.，Cheng，Y.，Chu，J.，Jain，A.，和B.Raghavan，“TCP快速开放”，第七届ACM大会论文集，2011年12月。
[RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992, <http://www.rfc-editor.org/info/rfc1323>.
[RFC1323]Jacobson，V.，Braden，R.，和D.Borman，“高性能TCP扩展”，RFC 1323，1992年5月<http://www.rfc-editor.org/info/rfc1323>.
[RFC1644] Braden, R., "T/TCP -- TCP Extensions for Transactions Functional Specification", RFC 1644, July 1994, <http://www.rfc-editor.org/info/rfc1644>.
[RFC1644]Braden，R.，“T/TCP——事务功能规范的TCP扩展”，RFC16441994年7月<http://www.rfc-editor.org/info/rfc1644>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月<http://www.rfc-editor.org/info/rfc2460>.
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, August 2007, <http://www.rfc-editor.org/info/rfc4987>.
[RFC4987]Eddy，W.“TCP SYN洪泛攻击和常见缓解措施”，RFC 4987，2007年8月<http://www.rfc-editor.org/info/rfc4987>.
[RFC6013] Simpson, W., "TCP Cookie Transactions (TCPCT)", RFC 6013, January 2011, <http://www.rfc-editor.org/info/rfc6013>.
[RFC6013]辛普森，W.“TCP Cookie事务（TCPCT）”，RFC6013，2011年1月<http://www.rfc-editor.org/info/rfc6013>.
[RFC6247] Eggert, L., "Moving the Undeployed TCP Extensions RFC 1072, RFC 1106, RFC 1110, RFC 1145, RFC 1146, RFC 1379, RFC 1644, and RFC 1693 to Historic Status", RFC 6247, May 2011, <http://www.rfc-editor.org/info/rfc6247>.
[RFC6247]Eggert，L.“将未部署的TCP扩展RFC 1072、RFC 1106、RFC 1110、RFC 1145、RFC 1146、RFC 1379、RFC 1644和RFC 1693移动到历史状态”，RFC 6247，2011年5月<http://www.rfc-editor.org/info/rfc6247>.
[RFC7323] Borman, D., Braden, B., Jacobson, V., and R. Scheffenegger, Ed., "TCP Extensions for High Performance", RFC 7323, September 2014, <http://www.rfc-editor.org/info/rfc7323>.
[RFC7323]Borman，D.，Braden，B.，Jacobson，V.，和R.Scheffenegger，Ed.，“高性能TCP扩展”，RFC 73232014年9月<http://www.rfc-editor.org/info/rfc7323>.
[SOUDERS11] Souders, S., "Making A Mobile Connection", <http://www.stevesouders.com/blog/2011/09/21/ making-a-mobile-connection/>.
[SOUDERS11]Souders，S.，“建立移动连接”<http://www.stevesouders.com/blog/2011/09/21/ 建立移动连接/>。
The active open side involves changing or replacing the connect() call, which does not take a user data buffer argument. We recommend replacing the connect() call to minimize API changes, and, hence, applications to reduce the deployment hurdle.
活动的开放端涉及更改或替换connect（）调用，该调用不接受用户数据缓冲区参数。我们建议替换connect（）调用以最小化API更改，从而减少应用程序的部署障碍。
One solution implemented in Linux 3.7 is introducing a new flag, MSG_FASTOPEN, for sendto() or sendmsg(). MSG_FASTOPEN marks the attempt to send data in the SYN like a combination of connect() and sendto(), by performing an implicit connect() operation. It blocks until the handshake has completed and the data is buffered.
Linux 3.7中实现的一个解决方案是为sendto（）或sendmsg（）引入一个新标志MSG_FASTOPEN。MSG_FASTOPEN通过执行隐式connect（）操作，将试图在SYN中发送数据的行为标记为connect（）和sendto（）的组合。它会一直阻塞，直到握手完成并缓冲数据。
For a non-blocking socket, it returns the number of bytes buffered and sent in the SYN packet. If the cookie is not available locally, it returns -1 with errno EINPROGRESS, and sends a SYN with a TFO cookie request automatically. The caller needs to write the data again when the socket is connected. On errors, it returns the same errno as connect() if the handshake fails.
对于非阻塞套接字，它返回SYN数据包中缓冲和发送的字节数。如果cookie在本地不可用，它将返回-1（带有errno EINPROGRESS），并自动发送带有TFO cookie请求的SYN。连接套接字时，调用方需要再次写入数据。在出现错误时，如果握手失败，它将返回与connect（）相同的errno。
An implementation may prefer not to change the sendmsg() call because TFO is a TCP-specific feature. A solution is to add a new socket option, TCP_FASTOPEN, for TCP sockets. When the option is enabled before a connect() operation, sendmsg() or sendto() will perform a Fast Open operation similar to the MSG_FASTOPEN flag described above. This approach, however, requires an extra setsockopt() system call.
实现可能不希望更改sendmsg（）调用，因为TFO是TCP特有的功能。解决方案是为TCP套接字添加一个新的套接字选项TCP_FASTOPEN。在connect（）操作之前启用该选项时，sendmsg（）或sendto（）将执行与上述MSG_FASTOPEN标志类似的快速打开操作。但是，这种方法需要额外的setsockopt（）系统调用。
The passive open side change is simpler compared to the active open side. The application only needs to enable the reception of Fast Open requests via a new TCP_FASTOPEN setsockopt() socket option before listen().
与主动开放侧相比，被动开放侧变化更简单。在侦听（）之前，应用程序只需通过新的TCP_FASTOPEN setsockopt（）套接字选项启用快速打开请求的接收。
The option enables Fast Open on the listener socket. The option value specifies the PendingFastOpenRequests threshold, i.e., the maximum length of pending SYNs with data payload. Once enabled, the TCP implementation will respond with TFO cookies per request.
该选项启用侦听器套接字上的快速打开。选项值指定PendingFastOpenRequests阈值，即具有数据负载的挂起SYN的最大长度。一旦启用，TCP实现将对每个请求使用TFO cookies进行响应。
Traditionally, accept() returns only after a socket is connected. But, for a Fast Open connection, accept() returns upon receiving a SYN with a valid Fast Open cookie and data, and the data is available to be read through, e.g., recvmsg(), read().
传统上，accept（）仅在连接套接字后返回。但是，对于快速打开连接，accept（）在接收到带有有效快速打开cookie和数据的SYN时返回，并且数据可供读取，例如recvmsg（），read（）。
Acknowledgments
致谢
We thank Bob Briscoe, Michael Scharf, Gorry Fairhurst, Rick Jones, Roberto Peon, William Chan, Adam Langley, Neal Cardwell, Eric Dumazet, and Matt Mathis for their feedback. We especially thank Barath Raghavan for his contribution on the security design of Fast Open and proofreading this document numerous times.
我们感谢Bob Briscoe、Michael Scharf、Gorry Fairhurst、Rick Jones、Roberto Paon、William Chan、Adam Langley、Neal Cardwell、Eric Dumazet和Matt Mathis的反馈。我们特别感谢Barath Raghavan对Fast Open的安全设计所做的贡献，并多次校对本文件。
Authors' Addresses
作者地址
Yuchung Cheng Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 United States
美国加利福尼亚州山景公园道1600圆形剧场谷歌公司，邮编94043
EMail: ycheng@google.com
EMail: ycheng@google.com
Jerry Chu Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 United States
Jerry Chu Google，Inc.美国加利福尼亚州山景大道1600号圆形剧场，邮编94043
EMail: hkchu@google.com
EMail: hkchu@google.com
Sivasankar Radhakrishnan Department of Computer Science and Engineering University of California, San Diego 9500 Gilman Drive La Jolla, CA 92093-0404 United States
加利福尼亚大学计算机科学与工程系，圣地亚哥9500吉尔曼大道拉霍拉，加州92093-0404美国
EMail: sivasankar@cs.ucsd.edu
EMail: sivasankar@cs.ucsd.edu
Arvind Jain Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 United States
Arvind Jain Google，Inc.美国加利福尼亚州山景大道1600号圆形剧场，邮编94043
EMail: arvind@google.com
EMail: arvind@google.com