Independent Submission W. Simpson
Request for Comments: 6013 DayDreamer
Category: Experimental January 2011
ISSN: 2070-1721
Independent Submission W. Simpson
Request for Comments: 6013 DayDreamer
Category: Experimental January 2011
ISSN: 2070-1721
TCP Cookie Transactions (TCPCT)
TCP Cookie事务（TCPCT）
Abstract
摘要
TCP Cookie Transactions (TCPCT) deter spoofing of connections and prevent resource exhaustion, eliminating Responder (server) state during the initial handshake. The Initiator (client) has sole responsibility for ensuring required delays between connections. The cookie exchange may carry data, limited to inhibit amplification and reflection denial of service attacks.
TCP Cookie事务（TCPCT）阻止连接欺骗并防止资源耗尽，从而消除初始握手期间的响应者（服务器）状态。发起人（客户机）全权负责确保连接之间所需的延迟。cookie交换可能携带数据，仅限于抑制放大和反射拒绝服务攻击。
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 is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档为互联网社区定义了一个实验协议。这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见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/rfc6013.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6013.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
This document may not be modified, and derivative works of it may not be created, except to format it for publication as an RFC or to translate it into languages other than English.
不得修改本文件，也不得创建其衍生作品，除非将其格式化为RFC出版或将其翻译为英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Terminology ................................................4
2. Protocol Overview ...............................................4
2.1. Message Summary (Simplified) ...............................6
2.2. Compatibility and Transparency .............................7
2.3. Fully Loaded Cookies .......................................7
2.4. TCP Header Extension .......................................8
2.5. <SYN> Option Handling ......................................9
3. Protocol Details ................................................9
3.1. TCP Cookie Option .........................................10
3.2. TCP Cookie-Pair Standard Option ...........................10
3.3. TCP Cookie-less Option ....................................11
3.4. TCP Timestamps Extended Option ............................11
3.5. Cookie Generation .........................................13
4. Cookie Exchange ................................................16
4.1. Initiator <SYN> ...........................................16
4.2. Responder <SYN,ACK(SYN)> ..................................17
4.3. Initiator <ACK(SYN)> ......................................17
4.4. Responder <ACK> ...........................................18
4.5. Simultaneous Open .........................................18
5. Accelerated Close ..............................................19
5.1. Initiator Close ...........................................20
5.2. Responder Close ...........................................20
6. Accelerated Open ...............................................21
6.1. Initiator <SYN> Data ......................................21
6.2. Responder <SYN,ACK(SYN)> Data .............................22
6.3. Initiator <ACK(SYN)> Data .................................23
6.4. Responder <ACK> Data ......................................24
7. Advisory Reset .................................................24
8. Interactions with Other Options ................................24
8.1. TCP Selective Acknowledgment ..............................25
8.2. TCP Timestamps ............................................25
8.3. TCP Extensions for Transactions ...........................25
8.4. TCP MD5 Signature .........................................25
8.5. TCP Authentication ........................................25
9. History ........................................................26
10. Acknowledgments ...............................................27
11. IESG Considerations ...........................................27
12. Operational Considerations ....................................28
13. Security Considerations .......................................28
Appendix A. Example Headers .......................................30
A.1. Example <SYN> Options .....................................30
A.2. Example <ACK(SYN)> with Sack ..............................31
A.3. Example <ACK(SYN)> with 64-bit Timestamps .................32
Normative References ..............................................33
Informative References ............................................34
1. Introduction ....................................................4
1.1. Terminology ................................................4
2. Protocol Overview ...............................................4
2.1. Message Summary (Simplified) ...............................6
2.2. Compatibility and Transparency .............................7
2.3. Fully Loaded Cookies .......................................7
2.4. TCP Header Extension .......................................8
2.5. <SYN> Option Handling ......................................9
3. Protocol Details ................................................9
3.1. TCP Cookie Option .........................................10
3.2. TCP Cookie-Pair Standard Option ...........................10
3.3. TCP Cookie-less Option ....................................11
3.4. TCP Timestamps Extended Option ............................11
3.5. Cookie Generation .........................................13
4. Cookie Exchange ................................................16
4.1. Initiator <SYN> ...........................................16
4.2. Responder <SYN,ACK(SYN)> ..................................17
4.3. Initiator <ACK(SYN)> ......................................17
4.4. Responder <ACK> ...........................................18
4.5. Simultaneous Open .........................................18
5. Accelerated Close ..............................................19
5.1. Initiator Close ...........................................20
5.2. Responder Close ...........................................20
6. Accelerated Open ...............................................21
6.1. Initiator <SYN> Data ......................................21
6.2. Responder <SYN,ACK(SYN)> Data .............................22
6.3. Initiator <ACK(SYN)> Data .................................23
6.4. Responder <ACK> Data ......................................24
7. Advisory Reset .................................................24
8. Interactions with Other Options ................................24
8.1. TCP Selective Acknowledgment ..............................25
8.2. TCP Timestamps ............................................25
8.3. TCP Extensions for Transactions ...........................25
8.4. TCP MD5 Signature .........................................25
8.5. TCP Authentication ........................................25
9. History ........................................................26
10. Acknowledgments ...............................................27
11. IESG Considerations ...........................................27
12. Operational Considerations ....................................28
13. Security Considerations .......................................28
Appendix A. Example Headers .......................................30
A.1. Example <SYN> Options .....................................30
A.2. Example <ACK(SYN)> with Sack ..............................31
A.3. Example <ACK(SYN)> with 64-bit Timestamps .................32
Normative References ..............................................33
Informative References ............................................34
TCP Cookie Transactions (TCPCT) provide a cryptologically secure mechanism to guard against simple flooding attacks sent with bogus IP [RFC791] Sources or TCP [RFC793] Ports. The initial TCP <SYN> exchange is vulnerable to forged IP Addresses, predictable Ports, and discoverable Sequence Numbers [Morris1985] [Gont2009]. (See also [RFC2827], [RFC3704], and [RFC4953].)
TCP Cookie Transactions（TCPCT）提供了一种加密安全机制，以防止通过伪IP[RFC791]源或TCP[RFC793]端口发送的简单泛洪攻击。初始TCP<SYN>交换易受伪造IP地址、可预测端口和可发现序列号的攻击[Morris1985][Gont2009]。（另请参见[RFC2827]、[RFC3704]和[RFC4953]。）
During connection establishment, the cookie (nonce) exchange negotiates elimination of Responder (server) state. These cookies are later used to inhibit premature closing of connections, and reduce retention of state after the connection has terminated.
在建立连接期间，cookie（nonce）交换协商消除响应程序（服务器）状态。这些cookie稍后用于禁止过早关闭连接，并减少连接终止后的状态保留。
The cookie pair is much too large to fit with the other recommended options in the maximal 60 byte TCP header (40 bytes of option space). A successful option exchange signals availability of the TCP header extension, adding space for additional options.
cookie对太大，无法与最大60字节TCP标头（40字节的选项空间）中的其他推荐选项匹配。成功的选项交换表明TCP头扩展可用，为其他选项增加空间。
Also, implementations may optionally exchange limited amounts of transaction data during the initial cookie exchange, reducing network latency and host task context switching.
此外，实现可以选择在初始cookie交换期间交换有限数量的事务数据，从而减少网络延迟和主机任务上下文切换。
Finally, implementations may optionally rapidly recycle prior connections. For otherwise stateless applications, this transparently facilitates persistent connections and pipelining of requests over each connection.
最后，实现可以选择性地快速回收先前的连接。对于其他无状态的应用程序，这透明地促进了持久连接和通过每个连接的请求管道化。
Many of these ideas have been previously proposed in one form or another (see History and Acknowledgments sections). This specification integrates these improvements into a coherent whole. Further motivation and rationale were detailed in [MSV2009].
这些想法中有许多以前是以这样或那样的形式提出的（参见历史和确认部分）。本规范将这些改进整合为一个连贯的整体。[MSV2009]详细说明了进一步的动机和理由。
The key words "MAY", "MUST, "MUST NOT", "OPTIONAL", "RECOMMENDED", "REQUIRED", "SHOULD", and "SHOULD NOT" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“可能”、“必须”、“不得”、“可选”、“建议”、“必需”、“应该”和“不应该”应按照[RFC2119]中所述进行解释。
byte An 8-bit quantity; also known as "octet" in standardese.
字节是8位的数量；在标准语中也称为“八位组”。
The TCPCT extensions consist of several simple phases:
TCPCT扩展包括几个简单的阶段：
1. Each party passes a "cookie" to the other. Due to limited space, only the most basic options are included.
1. 每一方都将一块“饼干”传递给另一方。由于空间有限，仅包括最基本的选项。
The Cookie option also indicates that optional <SYN> data is acceptable. This data MAY be ignored by either party.
Cookie选项还指示可选的<SYN>数据是可接受的。任何一方均可忽略此数据。
A Responder that understands the Cookie option remains stateless.
理解Cookie选项的响应程序保持无状态。
2. During the remainder of the standard TCP three-way handshake, the Timestamps and Cookie-Pair options guard the exchange.
2. 在剩余的标准TCP三方握手过程中，时间戳和Cookie对选项保护交换。
Other options present in the original <SYN> that were successfully returned in the <SYN,ACK(SYN)> MUST be included with the <ACK(SYN)>. Additional options MAY also be included as desired.
原始<SYN>中存在的、在<SYN，ACK（SYN）>中成功返回的其他选项必须包含在<ACK（SYN）>中。还可以根据需要包括其他选项。
As there is no Responder state, it has no record of acknowledging previous data. Any optional <SYN> data MUST be retransmitted.
由于没有响应程序状态，因此它没有确认以前数据的记录。必须重新传输任何可选的<SYN>数据。
Upon verification of the Timestamps and Cookie-Pair, the Responder creates its Transport Control Block (TCB) [RFC793].
在验证时间戳和Cookie对后，响应者创建其传输控制块（TCB）[RFC793]。
Note that the Responder returns the Cookie-Pair with its initial data, but subsequent data segments need only the Timestamps.
请注意，响应程序返回Cookie对及其初始数据，但后续数据段只需要时间戳。
3. During close (or reset) of the TCP connection, the Timestamps and Cookie-Pair options guard the exchange.
3. 在TCP连接关闭（或重置）期间，时间戳和Cookie对选项保护交换。
Upon verification of the Timestamps and Cookie-Pair, the Responder removes its TCB.
在验证时间戳和Cookie对后，响应程序删除其TCB。
The sequence of messages is summarized in the diagram below.
下图总结了消息的顺序。
Initiator Responder
========= =========
<SYN> ->
base options
Timestamps
Cookie
[request data]
<- <SYN,ACK(SYN)>
base options
Timestamps
Cookie
[response data]
(stateless)
Initiator Responder
========= =========
<SYN> ->
base options
Timestamps
Cookie
[request data]
<- <SYN,ACK(SYN)>
base options
Timestamps
Cookie
[response data]
(stateless)
<ACK(SYN)> -> full options Timestamps Cookie-Pair [Sack(response)] data <- <ACK> full options Timestamps Cookie-Pair data (TCB state created) <- <ACK> Timestamps data
<ACK（SYN）>->完整选项时间戳Cookie对[Sack（response）]数据<-<ACK>完整选项时间戳Cookie对数据（TCB状态已创建）<-<ACK>时间戳数据
<- <FIN,ACK> Timestamps Cookie-Pair <FIN,ACK(FIN)> -> Timestamps Cookie-Pair <- <ACK(FIN)> Timestamps Cookie-Pair (TCB state removed) TIME-WAIT
<-<FIN，ACK>时间戳Cookie对<FIN，ACK（FIN）>->时间戳Cookie对<-<ACK（FIN）>时间戳Cookie对（TCB状态已删除）等待时间
It is usually better that data arrive slowly, than not at all.
数据到达得慢通常比完全不到达要好。
Many/most unmanaged middleboxes [RFC3234] (such as stateless firewalls, load balancers, intrusion detection systems, or network address translators [RFC3022]) cannot carry transport traffic other than TCP and UDP.
许多/大多数非托管中间盒[RFC3234]（如无状态防火墙、负载平衡器、入侵检测系统或网络地址转换器[RFC3022]）不能承载TCP和UDP以外的传输流量。
Every TCP implementation MUST ignore without error any TCP option it does not implement ([RFC1122] section 4.2.2.5). In a study of the effects of middleboxes on transport protocols [MAF2004], the vast majority of modern TCP stacks correctly handle unknown TCP options. But it is still prudent to follow the [RFC793] "general principle of robustness: be conservative in what you do, be liberal in what you accept from others."
每个TCP实现必须无误地忽略它未实现的任何TCP选项（[RFC1122]第4.2.2.5节）。在一项关于中间盒对传输协议影响的研究[MAF2004]中，绝大多数现代TCP协议栈都能正确处理未知的TCP选项。但遵循[RFC793]的“稳健性的一般原则：做事要保守，接受别人的东西要自由。”
Therefore, for each of the extensions defined here, an extension option will be sent in a <SYN,ACK(SYN)> segment only after the corresponding option was received in the original <SYN> segment.
因此，对于此处定义的每个扩展，只有在原始<SYN>段中接收到相应的选项后，才会在<SYN，ACK（SYN）>段中发送扩展选项。
Furthermore, TCP options will be sent on later segments only after an exchange of options has indicated that both parties understand the extension (see [RFC1323] [rfc1323bis] and its antecedents).
此外，只有在交换选项表明双方都理解扩展后，才会在以后的段上发送TCP选项（请参见[RFC1323][rfc1323bis]及其先行项）。
Unfortunately, not all middleware adheres to these long-standing requirements. Instead, unknown <SYN> options are copied to the <SYN,ACK(SYN)>. This is indistinguishable from a Monkey in the Middle (MITM) reflection attack.
不幸的是，并非所有中间件都符合这些长期存在的需求。相反，将未知的<SYN>选项复制到<SYN，ACK（SYN）>。这与猴子在中间（MITM）反射攻击没有什么区别。
One Kind to aid them all, One Kind to find them, One Kind to hold them all and in the header bind them.
一种是帮助他们，一种是找到他们，一种是抓住他们，在头上绑住他们。
The cookie exchange provides a singular opportunity to extend TCP with backward compatibility. Semantics for the option have been "overloaded" with a baker's dozen of capabilities and facilities.
cookie交换提供了一个独特的机会来扩展具有向后兼容性的TCP。该选项的语义已经被贝克的十几种功能和设施“过载”。
A. First and foremost, the cookie exchange improves operational security for vulnerable servers against flooding attacks. The cookie exchange indicates that the Responder (server) will discard its initial state. All other semantics are subordinate.
答：首先，cookie exchange提高了易受攻击服务器的操作安全性，以抵御洪水攻击。cookie交换表示响应程序（服务器）将放弃其初始状态。所有其他语义都是从属的。
B. Together with Sequence and Timestamp values, Cookie values protect against insertion and reflection attacks.
B.Cookie值与序列和时间戳值一起可防止插入和反射攻击。
C. Cookie values allow applications to detect replay attacks.
C.Cookie值允许应用程序检测重播攻击。
D. Cookie values MAY be used as an index or nonce for application security protocols. This facility is beyond the scope of this specification.
Cookie值可用作应用程序安全协议的索引或nonce。该设施超出了本规范的范围。
E. The <SYN> and <SYN,ACK(SYN)> MAY carry application data. This feature is entirely optional, and data is not guaranteed to pass successfully through middleware. Nor are the parties guaranteed to process this data without changes to the Application Program Interface (API). Such changes are beyond the scope of this specification.
E.<SYN>和<SYN，ACK（SYN）>可以携带应用程序数据。此功能完全是可选的，并且不能保证数据能够成功通过中间件。双方也不保证在不更改应用程序接口（API）的情况下处理这些数据。此类变更超出本规范的范围。
F. The size of the cookies precludes most other options in the standard TCP header space. The cookie exchange negotiates TCP header extension.
F.Cookie的大小排除了标准TCP标头空间中的大多数其他选项。cookie交换协商TCP标头扩展。
G. The cookie exchange and resulting TCP header extension permit negotiation of larger 64-bit (or 128-bit) Timestamps for paths with large bandwidth-delay products.
G.cookie交换和由此产生的TCP报头扩展允许为具有大带宽延迟产品的路径协商更大的64位（或128位）时间戳。
H. TCP header extension frees some space for additional options.
TCP头扩展为附加选项释放了一些空间。
I. Previously SYN-only options can be updated.
I.以前只能更新SYN选项。
J. The cookie exchange indicates agreement to use accelerated close.
J.cookie交换表示同意使用加速关闭。
K. The cookie exchange indicates agreement that only the Initiator (client) handles TIME-WAIT state.
K.cookie交换表示只有启动器（客户端）处理等待时间状态的协议。
L. The Timestamps and Cookie-Pair combination inhibits third parties from disrupting communications with <FIN> and <RST>.
L.时间戳和Cookie对组合禁止第三方中断与<FIN>和<RST>的通信。
M. The Timestamps and Cookie-Pair combination facilitates rapid reuse of the TCP Source Port with a common destination.
M.时间戳和Cookie对的组合有助于快速重用TCP源端口和公共目的地。
Once the Cookie option has been successfully exchanged, TCP header extension is permitted. The Timestamps extended option (defined below) indicates the presence of the header extension.
成功交换Cookie选项后，允许TCP头扩展。Timestamps extended选项（定义如下）指示存在报头扩展。
Validation of known timestamp values protects against data corruption by misbehaving middleboxes.
对已知时间戳值的验证可防止行为不端的中间盒导致数据损坏。
As the Responder retains no TCB state after the initial TCP <SYN> exchange, all options present in the original <SYN> MUST be repeated.
由于响应程序在初始TCP<SYN>交换后不保留TCB状态，因此必须重复原始<SYN>中存在的所有选项。
For example, an option defined in the [RFC793] original specification -- Maximum Segment Size (MSS) -- previously appeared only in a <SYN> bearing segment (including <SYN,ACK(SYN)>). If present, MSS will be repeated in the Initiator <ACK(SYN)>, together with any additional options.
例如，[RFC793]原始规范中定义的选项——最大段大小（MSS）——以前仅出现在<SYN>轴承段中（包括<SYN，ACK（SYN）>）。如果存在，MSS将与任何附加选项一起在启动器<ACK（SYN）>中重复。
Generally, the Initiator MAY propose SYN-only options -- such as MSS -- anytime both Timestamps and Cookie-Pair options are present. These options are treated the same as with an original <SYN>. The Responder acknowledges using a subsequent <ACK> segment containing both Timestamps and Cookie-Pair options (similar to <SYN,ACK(SYN)> processing).
通常，只要同时存在时间戳和Cookie对选项，发起方可能会提出仅SYN选项（如MSS）。这些选项的处理方式与原始<SYN>相同。响应者使用包含时间戳和Cookie对选项的后续<ACK>段进行确认（类似于<SYN，ACK（SYN）>处理）。
This facility allows previously SYN-only options to be updated from time to time. They take effect upon receipt.
此功能允许随时更新以前仅使用SYN的选项。收到后生效。
However, <ACK> segments without data will not be delivered reliably. Any otherwise SYN-only options sent without data MUST be retransmitted with successive segments until sent with data (or <FIN>), and an <ACK> is received.
但是，没有数据的<ACK>段将无法可靠地交付。任何在没有数据的情况下发送的仅SYN选项必须使用连续段重新传输，直到与数据一起发送（或<FIN>），并接收到<ACK>。
Another solution [RFC5452] describes use of an unpredictable Source Port. That is RECOMMENDED by this specification. See [RFC6056] for further information.
另一个解决方案[RFC5452]描述了不可预测的源端口的使用。这是本规范推荐的。有关更多信息，请参阅[RFC6056]。
An earlier solution [RFC1948] describes an unpredictable Initial Sequence Number (ISN). That is REQUIRED by this specification.
早期的解决方案[RFC1948]描述了不可预测的初始序列号（ISN）。这是本规范要求的。
Support for the (32-bit) TCP Timestamps Option [RFC1323] is REQUIRED. A TSoffset SHOULD be generated per connection [GO2010]. The Don't Fragment (DF) bit MUST be set in the IP (v4) header.
需要支持（32位）TCP时间戳选项[RFC1323]。应为每个连接生成TSoffset[GO2010]。必须在IP（v4）头中设置不分段（DF）位。
The TCP User Timeout Option [RFC5482] is RECOMMENDED.
建议使用TCP用户超时选项[RFC5482]。
Only one instance is permitted of any of the Cookie, Cookie-less, or Cookie-Pair option(s). Segments with duplicative or mutually exclusive options MUST be silently discarded.
任何Cookie、无Cookie或Cookie对选项只允许一个实例。具有重复或互斥选项的段必须以静默方式放弃。
For examples, see Appendix A.
有关示例，请参见附录A。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Kind 1 byte: constant 253 (experimental).
第1类字节：常数253（实验）。
Length 1 byte: range 10 to 18 (bytes); limited by remaining space in the options field. The number MUST be even; the cookie is a multiple of 16 bits.
长度1字节：范围为10到18（字节）；受限于选项字段中的剩余空间。数字必须是偶数；cookie是16位的倍数。
Cookie 8 to 16 bytes (Length - 2): an unpredictable value.
Cookie 8到16字节（长度-2）：一个不可预测的值。
Options with invalid Length values MUST be ignored. The minimum Cookie size is 64 bits. If there is not sufficient space for a 64-bit cookie, this option MUST NOT be used.
必须忽略长度值无效的选项。最小Cookie大小为64位。如果没有足够的空间容纳64位cookie，则不得使用此选项。
The Responder Cookie MUST be the same size as the Initiator Cookie. The cookie pair is a multiple of 32 bits.
响应程序Cookie的大小必须与启动器Cookie的大小相同。cookie对是32位的倍数。
Although the diagram shows a cookie aligned on 32-bit boundaries, that is not required.
尽管图中显示了在32位边界上对齐的cookie，但这不是必需的。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Initiator-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Responder-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Initiator-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Responder-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Kind 1 byte: constant 253 (experimental).
第1类字节：常数253（实验）。
Length 1 byte: range 18 to 34 (bytes). The number MUST be even; the cookie pair is a multiple of 32 bits.
长度1字节：范围为18到34（字节）。数字必须是偶数；cookie对是32位的倍数。
Initiator-Cookie 8 to 16 bytes, from the original <SYN>.
启动器Cookie 8到16字节，来自原始<SYN>。
Responder-Cookie 8 to 16 bytes, from the <SYN,ACK(SYN)>.
响应器Cookie 8到16字节，来自<SYN，ACK（SYN）>。
The Cookie-Pair standard option only appears after the Timestamps extended option (below).
Cookie Pair standard选项仅出现在时间戳扩展选项（下面）之后。
Options with invalid Length values MUST be ignored. As the minimum Initiator-Cookie size is 64 bits, the minimum cookie pair is 128 bits (64 bits followed by 64 bits), while the maximum is 256 bits (128 bits followed by 128 bits).
必须忽略长度值无效的选项。由于最小启动器Cookie大小为64位，因此最小Cookie对为128位（64位后接64位），而最大值为256位（128位后接128位）。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Kind 1 byte: constant 253 (experimental).
第1类字节：常数253（实验）。
Length 1 byte: constant 2 (bytes). This distinguishes the option from other Cookie options.
长度1字节：常数2（字节）。这将该选项与其他Cookie选项区分开来。
Although no cookie is attached, this indicates that other features of this specification are available, including TCP header extension, Accelerated Close, Accelerated Open, and Advisory Reset. This is intended for use with TCP authentication options, beyond the scope of this specification.
虽然没有附加cookie，但这表明此规范的其他功能可用，包括TCP头扩展、加速关闭、加速打开和建议重置。此选项用于TCP身份验证选项，超出了本规范的范围。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind | Length | Extend | R | S |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
~ TS Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TS Echo Reply ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind | Length | Extend | R | S |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
~ TS Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TS Echo Reply ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Kind 1 byte: constant 254 (experimental).
第1类字节：常数254（实验）。
Length 1 byte: constant 4 (bytes).
长度1字节：常量4（字节）。
Extend 1 byte: range 9 to 255; the data offset (in 32-bit words) following the standard TCP header. Note this value MUST include the timestamp pair indicated by (S)ize.
扩展1字节：范围9到255；标准TCP头之后的数据偏移量（32位字）。注意：此值必须包括由（S）个ize指示的时间戳对。
(R)eserved 5 bits: default zero. Reserved for future use.
（R） 保留5位：默认为零。保留供将来使用。
(S)ize 3 bits:
（S） 输入3位：
1. 32-bit timestamps.
1. 32位时间戳。
2. 64-bit timestamps.
2. 64位时间戳。
4. 128-bit timestamps.
4. 128位时间戳。
Other values are beyond the scope of this specification.
其他值超出本规范的范围。
TS Value 4, 8, or 16 bytes. The current value of the timestamp for the sender.
TS值为4、8或16字节。发送方的时间戳的当前值。
TS Echo Reply 4, 8, or 16 bytes. A copy of the most recently received TS Value.
TS回显应答4、8或16字节。最近收到的TS值的副本。
The full timestamp pair follows the TCP header (indicated by +=+ delimiters) and maintains 32-bit alignment.
完整时间戳对跟随TCP头（由+=+分隔符表示），并保持32位对齐。
This TCP header extension is ignored for sequence number computations. The Sequence Number of the first byte of segment data will be the Initial Sequence Number (ISN) plus one (1) for the <SYN>.
序列号计算忽略此TCP标头扩展。段数据的第一个字节的序列号将是初始序列号（ISN）加上<SYN>的一（1）。
Every TCPCT implementation MUST recognize a Timestamps extended option. The larger 64-bit (or 128-bit) timestamps only appear in an extended option.
每个TCPCT实现都必须识别时间戳扩展选项。较大的64位（或128位）时间戳仅出现在扩展选项中。
Segments with invalid Extend values MUST be silently discarded.
具有无效扩展值的段必须以静默方式放弃。
Only one instance is permitted of either the (32-bit) Timestamps standard option or this Timestamps extended option. Segments with duplicative or mutually exclusive options MUST be silently discarded.
（32位）时间戳标准选项或此时间戳扩展选项只允许一个实例。具有重复或互斥选项的段必须以静默方式放弃。
Implementation Notes:
实施说明：
Serendipitous alignment allows simple loads and stores, instead of slower byte by byte iterations.
偶然的对齐允许简单的加载和存储，而不是缓慢的逐字节迭代。
When the TCP header is aligned on a 32-bit boundary and this is the only option, the timestamps in the extended header SHOULD be aligned on a 64-bit boundary. For both 32-bit and 64-bit timestamps, any data following the extended header will be aligned on a 64-bit boundary.
当TCP标头在32位边界上对齐且这是唯一选项时，扩展标头中的时间戳应在64位边界上对齐。对于32位和64位时间戳，扩展头后面的任何数据都将在64位边界上对齐。
However, the 128-bit timestamps are not 128-bit aligned.
但是，128位时间戳不是128位对齐的。
The technique by which a party generates a cookie is implementation dependent. The method chosen must satisfy some basic requirements:
参与方生成cookie的技术依赖于实现。选择的方法必须满足一些基本要求：
1. The cookie MUST depend on the specific parties. This prevents an attacker from obtaining a cookie using a real IP address and TCP port, and then using it to swamp the victim with requests from randomly chosen IP addresses or ports.
1. cookie必须取决于特定的参与方。这可以防止攻击者使用真实的IP地址和TCP端口获取cookie，然后使用cookie从随机选择的IP地址或端口向受害者发送请求。
2. It MUST NOT be possible for anyone other than the issuing entity to generate cookies that will be accepted by that entity. This implies that the issuing entity will use local secret information in the generation and subsequent verification of a cookie. It must not be possible to deduce this secret information from any particular cookie.
2. 发行实体以外的任何人不得生成该实体将接受的cookie。这意味着发布实体将在cookie的生成和后续验证中使用本地机密信息。不能从任何特定的cookie推断出此机密信息。
3. The cookie generation and verification methods MUST be fast to thwart attacks intended to sabotage CPU resources.
3. cookie生成和验证方法必须快速，以阻止旨在破坏CPU资源的攻击。
A recommended technique is to use a cryptographic hashing function.
建议使用加密哈希函数。
An incoming cookie can be verified at any time by regenerating it locally from values contained in the incoming datagram and the local secret random value.
通过从传入数据报中包含的值和本地机密随机值本地重新生成传入cookie，可以随时对传入cookie进行验证。
The Initiator secret value that affects its cookie SHOULD change for each new exchange, and is thereafter internally cached per TCB. This provides improved synchronization and protection against replay attacks.
影响其cookie的启动器机密值应针对每个新交换进行更改，然后根据TCB进行内部缓存。这提供了改进的同步和防止重播攻击的保护。
An alternative is to cache the cookie instead of the secret value. Incoming cookies can be compared directly without the computational cost of regeneration.
另一种方法是缓存cookie而不是secret值。传入的cookie可以直接进行比较，而无需重新生成的计算成本。
It is RECOMMENDED that the cookie be calculated over the secret value, the IP Source and Destination addresses, the TCP Source and Destination ports, and any (optional) Initiator <SYN> segment data.
建议根据机密值、IP源和目标地址、TCP源和目标端口以及任何（可选）启动器<SYN>段数据计算cookie。
Implementation Notes:
实施说明：
Although the recommendation includes the TCP Source Port, this is very implementation specific. For example, it might not be included when the value is constant or unknown.
虽然建议包括TCP源端口，但这是非常具体的实现。例如，当值为常量或未知时，可能不包括该值。
Likewise, segment data might not be included directly. For example, a pointer to the data could be included instead, with care taken to ensure the pointer changes anytime the data changes.
同样，段数据可能不会直接包括在内。例如，可以包含指向数据的指针，但要注意确保指针在数据更改时随时更改。
However, it is important that the implementation protect mutually suspicious users of the same system from generating the same cookie.
但是，重要的是，该实现应保护同一系统中相互可疑的用户不生成相同的cookie。
The Responder secret value that affects its cookies remains the same for many different Initiators. However, this secret SHOULD be changed periodically to limit the time for use of its cookies (typically each 600 seconds).
对于许多不同的启动器，影响其Cookie的响应者机密值保持不变。但是，应定期更改此秘密，以限制其cookie的使用时间（通常每600秒一次）。
The Responder-Cookie calculation MUST include its own TCP Sequence and Acknowledgment Numbers (after updating values), its own TCP Timestamps value, and the Initiator-Cookie value. This provides improved synchronization and protection against replay attacks.
响应程序Cookie计算必须包括自己的TCP序列和确认号（更新值后）、自己的TCP时间戳值和启动器Cookie值。这提供了改进的同步和防止重播攻击的保护。
It is RECOMMENDED that the cookie be calculated over the secret value, the IP Source and Destination addresses, its own TCP Destination Port (that is, the incoming Source Port), and the required values (above), followed by the secret value again.
建议根据机密值、IP源地址和目标地址、其自身的TCP目标端口（即，传入源端口）和所需值（如上）计算cookie，然后再次计算机密值。
The cookie is not cached per Initiator to avoid saving state during the initial TCP <SYN> exchange. On receipt of a TCP <ACK(SYN)>, the Responder regenerates its cookie for validation.
不会为每个启动器缓存cookie，以避免在初始TCP<SYN>交换期间保存状态。收到TCP<ACK（SYN）>，响应者将重新生成其cookie以进行验证。
Implementation Notes:
实施说明：
Although the recommendation does not include the TCP Source Port, this is very implementation specific. It might be successfully included in some variants.
虽然建议不包括TCP源端口，但这是非常具体的实现。它可能成功地包含在某些变体中。
The Responder Cookie depends on the TCP Sequence and Acknowledgment Numbers as they will appear for future verification. The Sequence Number will be the Initial Sequence
响应器Cookie取决于TCP序列和确认号，因为它们将在将来的验证中显示。序列号将是初始序列
Number (ISN) plus one (1) for its <SYN> that will be acknowledged. The Acknowledgment Number will be the Initial Sequence Number (ISN) plus one (1) for the <SYN> that it is now acknowledging.
数字（ISN）加上一（1）个将被确认的<SYN>。确认号将是初始序列号（ISN）加上一（1），表示它现在正在确认的<SYN>。
The (32-bit) TCP Timestamps standard option MAY change to the larger 64-bit (or 128-bit) extended form; only the least significant 32 bits are included. The Initiator Timestamp field value MAY increment during the exchange; it MUST NOT be included.
（32位）TCP时间戳标准选项可以更改为更大的64位（或128位）扩展形式；仅包括最低有效32位。启动器时间戳字段值可在交换期间增加；它决不能包括在内。
The secret value is included twice to better protect against pre-calculated attacks using substitutions for variable length data. Some examples using this technique are IP-MAC and H-MAC, and it is likely that existing code could be shared.
机密值包含两次，以更好地防止使用可变长度数据替换的预先计算的攻击。使用这种技术的一些示例是IP-MAC和H-MAC，现有代码很可能可以共享。
The Responder SHOULD designate a (fixed or randomly selected) bit of its cookie to distinguish each changed secret value. The bit is set to a (fixed or randomly selected) constant 0 or 1, and checked upon receipt before further verification. This ensures that only one verification calculation is necessary (on average) during Denial of Service (DoS) attacks.
响应者应该指定其cookie的一个（固定的或随机选择的）位来区分每个更改的秘密值。该位设置为（固定或随机选择）常数0或1，并在收到后进行检查，然后进行进一步验证。这样可以确保拒绝服务（DoS）攻击期间（平均）只需要一次验证计算。
If a Responder Cookie is identical to the Initiator Cookie, the Responder SHOULD change one or more bits of its cookie to prevent its accidental appearance as a reflection attack.
如果响应程序Cookie与启动器Cookie相同，则响应程序应更改其Cookie的一个或多个位，以防止其意外出现为反射攻击。
Each Responder maintains up to two secret values concurrently for efficient secret rollover. Each secret value has 4 states:
每个响应程序同时维护最多两个秘密值，以实现高效的秘密翻转。每个秘密值有4种状态：
Generating Generates new Responder-Cookies, but not yet used for primary verification. This is a short-term state, typically lasting only one Round Trip Time (RTT).
生成生成新的响应程序cookie，但尚未用于主验证。这是一种短期状态，通常仅持续一次往返时间（RTT）。
Primary Used both for generation and primary verification.
主要用于生成和主要验证。
Retiring Used for verification, until the first failure that can be verified by the newer Generating secret. At that time, this cookie's state is changed to Secondary, and the Generating cookie's state is changed to Primary. This is a short-term state, typically lasting only one RTT.
用于验证的停用，直到可以由较新的生成密钥验证的第一个故障。此时，此cookie的状态更改为次要，生成cookie的状态更改为主要。这是一种短期状态，通常仅持续一个RTT。
Secondary Used for secondary verification, after primary verification failures. This state lasts no more than twice the Maximum Segment Lifetime (2MSL). Then, the secret is discarded.
次要验证用于次要验证，主要验证失败后。此状态持续时间不超过最大段生存期（2MSL）的两倍。然后，这个秘密就被丢弃了。
Implementation Notes:
实施说明：
Care MUST be taken to ensure that any expired secrets are promptly wiped from memory, and secrets are never saved to external storage.
必须注意确保及时从内存中删除任何过期的机密，并且从不将机密保存到外部存储器中。
The first secret after initialization begins in Primary state. The system might have shutdown and restarted rapidly during the previous first secret. Thus, the first secret MUST be partially time dependent, to ensure that it differs from previous first secrets, usually by appending a time to lengthen the first secret. Those that are not the first secret SHOULD NOT include the time.
初始化后的第一个秘密以主状态开始。在前一个第一个秘密期间，系统可能已关闭并快速重新启动。因此，第一个秘密必须部分依赖于时间，以确保它不同于以前的第一个秘密，通常通过增加时间来延长第一个秘密。那些不是第一秘密的不应该包括时间。
At the same time, there is no TCP TIME-WAIT requirement before accepting connections, and there may be pent up demand for a busy service. Also, there may be outstanding datagrams attempting to complete an earlier cookie exchange. The first secret is likely to be the weakest, as no recent entropy has been included.
同时，在接受连接之前没有TCP时间等待要求，并且可能存在对繁忙服务的被压抑的需求。此外，可能有未完成的数据报试图完成较早的cookie交换。第一个秘密可能是最薄弱的，因为最近没有熵被包括在内。
Therefore, while terminating outstanding exchanges with the first secret, a new Generating secret SHOULD be created after no more than one Maximum Segment Lifetime (1MSL). Subsequent secrets SHOULD be generated at the usual rate (typically 600 seconds).
因此，在终止与第一个秘密的未完成交换时，应在不超过一个最大段生存期（1MSL）后创建新的生成秘密。后续机密应以通常的速率生成（通常为600秒）。
The implementation SHOULD continually gather additional entropy from checksums, cookies, timestamps, and packet arrival timing.
实现应该不断地从校验和、cookie、时间戳和数据包到达时间收集额外的熵。
A successful option exchange signals availability of additional features.
成功的选项交换标志着附加功能的可用性。
The Cookie exchange MAY be initiated at any time, limited only by the frequency of the timestamp clock.
Cookie交换可以在任何时间发起，仅受时间戳时钟的频率限制。
If the TCB exists from a prior (or ongoing) connection, the timestamp MUST be incremented in the option.
如果TCB来自先前（或正在进行的）连接，则必须在选项中增加时间戳。
The Initiator generates its unpredictable cookie value, and includes the Cookie option.
启动器生成其不可预测的cookie值，并包含cookie选项。
During the initial exchange, the Initiator is solely responsible for retransmission. Although the cookie and sequence have not changed, each retransmission appears to the Responder as another original <SYN>.
在初始交换期间，发起者仅负责重新传输。尽管cookie和序列没有改变，但每次重新传输在响应者看来都是另一个原始的<SYN>。
Implementation Notes:
实施说明：
Sending the <SYN> SHOULD NOT affect any existing TCB. This allows an additional RTT for duplicate or out-of-sequence segments to drain.
发送<SYN>不应影响任何现有TCB。这允许对重复或无序段进行额外的RTT排放。
The new TCB information SHOULD be temporarily cached until a valid matching <SYN,ACK(SYN)> arrives. Then, any old TCB values are replaced.
新的TCB信息应临时缓存，直到有效的匹配<SYN，ACK（SYN）>到达。然后，替换所有旧的TCB值。
Upon receipt of the <SYN> with a Cookie option, the Responder determines whether there are sufficient resources to begin another connection.
在收到带有Cookie选项的<SYN>后，响应者确定是否有足够的资源开始另一个连接。
If the TCB exists from a prior (or ongoing) connection, the timestamp MUST be incremented in the option.
如果TCB来自先前（或正在进行的）连接，则必须在选项中增加时间戳。
Each Sequence Number MUST be randomized [RFC1948].
每个序列号必须随机化[RFC1948]。
The Responder generates its unpredictable cookie value, and includes the Cookie option.
响应程序生成其不可预测的cookie值，并包含cookie选项。
As the Responder retains no TCB state, retransmission timers are not available. Arrival of an Initiator's retransmission appears to be an original <SYN> transmission. There are no differences in processing.
由于应答器未保持TCB状态，因此重传计时器不可用。发起者的重传到达似乎是原始的<SYN>传输。在处理上没有区别。
Implementation Notes:
实施说明：
Sending the <SYN,ACK(SYN)> MUST NOT affect any existing TCB. This allows an additional RTT for duplicate or out-of-sequence segments to drain.
发送<SYN，ACK（SYN）>不得影响任何现有TCB。这允许对重复或无序段进行额外的RTT排放。
This also inhibits third parties from disrupting communications.
这也会阻止第三方中断通信。
Upon receipt of the <SYN,ACK(SYN)> with a Cookie option, the Initiator validates its cookie, timestamp, and corresponding Acknowledgment Number. The existing TCB is updated as necessary.
在收到带有Cookie选项的<SYN，ACK（SYN）>后，启动器验证其Cookie、时间戳和相应的确认号。现有TCB将根据需要进行更新。
All Initiator <SYN> options are always retransmitted on this first <ACK(SYN)>, allowing the Responder to validate its cookie and establish its state.
所有启动器<SYN>选项始终在此第一个<ACK（SYN）>上重新传输，允许响应者验证其cookie并建立其状态。
This segment contains both Timestamps and Cookie-Pair options.
此段包含时间戳和Cookie对选项。
The Initiator sends the Timestamps extended option with an appropriate Size -- chosen by a configurable parameter, or automatically based on its analysis of the bandwidth-delay product discovered through the RTT of its <SYN> timestamp. When the chosen Size is greater than 32 bits, the Initiator adds a random prefix to its own timestamp, and a random prefix to the Responder timestamp echo reply.
启动器发送具有适当大小的Timestamps extended（时间戳扩展）选项——由可配置参数选择，或根据其对通过其<SYN>时间戳的RTT发现的带宽延迟产品的分析自动选择。当所选大小大于32位时，发起方将向其自己的时间戳添加一个随机前缀，并向响应方时间戳echo reply添加一个随机前缀。
Implementation Notes:
实施说明：
A Responder Cookie identical to the Initiator Cookie MUST be discarded. This is usually an indication of a Monkey in the Middle (MITM) reflection attack or a seriously misconfigured network, and SHOULD be logged.
必须丢弃与启动器Cookie相同的响应者Cookie。这通常是指中间的猴子（MITM）反射攻击或严重错误配置的网络，并且应该被记录。
Upon receipt of the <ACK(SYN)> with a Cookie-Pair option, the Responder validates its cookie, timestamp, and corresponding Acknowledgment Number, and establishes state for the connection. Any existing TCB is updated as necessary.
在收到带有Cookie对选项的<ACK（SYN）>后，响应者验证其Cookie、时间戳和相应的确认号，并建立连接状态。根据需要更新任何现有TCB。
This segment contains both Timestamps and Cookie-Pair options.
此段包含时间戳和Cookie对选项。
However, the Responder MAY refuse to negotiate the larger 64-bit (or 128-bit) Timestamps extended option by returning the least significant bits in a smaller Timestamps extended option.
然而，响应者可以通过在较小的时间戳扩展选项中返回最低有效位来拒绝协商较大的64位（或128位）时间戳扩展选项。
Implementation Notes:
实施说明：
An <ACK(SYN)> that fails to validate MUST be discarded, and SHOULD be logged.
无法验证的<ACK（SYN）>必须丢弃，并应记录。
TCP allows two parties to simultaneously initiate the connection. Both parties send and receive an original <SYN> without an intervening <SYN,ACK(SYN)> (see [RFC793] section 3.4 and Figure 8). Each party receives a Cookie for a <Source Address, Source Port, Destination Address, Destination Port> connection that has also issued a Cookie.
TCP允许双方同时启动连接。双方发送和接收原始<SYN>，无需干预<SYN，ACK（SYN）>（参见[RFC793]第3.4节和图8）。每一方都会收到<Source Address，Source Port，Destination Address，Destination Port>连接的Cookie，该连接也发出了Cookie。
This condition will be unusual. The Source Port SHOULD be randomized [RFC5452], and SHOULD be chosen to differ from the Destination Port. In particular, the Source Port SHOULD be greater than 1024, preventing intervening network equipment from incorrectly classifying the return traffic. The Destination Port is most likely to be a well-known port less than 1024 [RFC3232].
这种情况是不寻常的。源端口应随机化[RFC5452]，并且应选择与目标端口不同的端口。特别是，源端口应大于1024，以防止干预网络设备对返回流量进行错误分类。目标端口很可能是小于1024[RFC3232]的已知端口。
In the event that these protections are insufficient, the conflict is resolved in an orderly fashion:
如果这些保护措施不充分，冲突将有序解决：
a. The lesser TCP Port number becomes the Responder;
a. 较小的TCP端口号成为响应程序；
b. The lesser IP Address becomes the Responder;
b. 较小的IP地址成为响应者；
c. The lesser Cookie becomes the Responder;
c. 较小的Cookie成为响应者；
d. All of the above being equal, there is an egregiously insufficient source of randomness, but both Initiators are probably present on the same host: the lesser TCB memory address becomes the Responder.
d. 上述所有条件相同时，随机性来源严重不足，但两个启动器可能位于同一主机上：较小的TCB内存地址成为响应者。
The Initiator silently discards the simultaneous <SYN>. The Responder revises its Cookie option, and sends the <SYN,ACK(SYN)> as usual, but without removing its existing TCB.
发起者悄悄地丢弃同步的<SYN>。响应者修改其Cookie选项，并像往常一样发送<SYN，ACK（SYN）>，但不删除其现有TCB。
Implementation Notes:
实施说明：
This is usually an indication of a Monkey in the Middle (MITM) reflection attack or a seriously misconfigured network, and SHOULD be logged.
这通常是指中间的猴子（MITM）反射攻击或严重错误配置的网络，并且应该被记录。
Support for accelerated close is REQUIRED. Accelerated close relies on the presence of cookies and timestamps. This provides improved synchronization and protection against replay attacks.
需要支持加速关闭。加速关闭依赖于cookie和时间戳的存在。这提供了改进的同步和防止重播攻击的保护。
Either party MAY close with <FIN> at any time. This <FIN> SHOULD be sent with the final data segment.
任何一方均可随时与<FIN>达成协议。此<FIN>应与最终数据段一起发送。
This segment contains both Timestamps and Cookie-Pair options.
此段包含时间戳和Cookie对选项。
When all segments preceding the <FIN> have been processed and acknowledged, each party SHOULD acknowledge the <FIN>.
当<FIN>前面的所有段都已处理并确认后，各方应确认<FIN>。
In general, <FIN> is treated as advisory. A persistent connection can be rapidly re-established. This also inhibits third parties from disrupting communications.
一般来说，<FIN>被视为顾问。可以快速重新建立持久连接。这也会阻止第三方中断通信。
Rapidly closing the connection expedites removing Responder state. Any <FIN> bearing segment SHOULD terminate delayed <ACK> [RFC5681]. Retransmit at the latest Timestamps estimated Smoothed Round Trip Time (SRTT). Backoff SHOULD NOT be used for <FIN> bearing retransmissions [RFC2988].
快速关闭连接会加速删除响应程序状态。任何<FIN>轴承段应延迟终止<ACK>[RFC5681]。在估计的平滑往返时间（SRTT）的最新时间戳处重新传输。退避不应用于<FIN>轴承重传[RFC2988]。
As the Responder retains no TCB state after closing, a successful option exchange signals the Initiator will be responsible for handling TIME-WAIT state. (For previous proposal and rationale, see [FTY1999] section 3.)
由于响应程序在关闭后没有保留TCB状态，因此成功的选项交换会发出信号，表明发起程序将负责处理等待时间状态。（有关以前的提案和理由，请参见[FTY1999]第3节。）
A new Cookie exchange MAY be initiated at any time. This facilitates persistent connections through intervening network equipment.
可以随时启动新的Cookie交换。这有助于通过中间网络设备进行持久连接。
Upon receipt of the Initiator <FIN> (and verification of the Timestamps and Cookie-Pair options), the Responder sends its <FIN,ACK(FIN)> unless there is additional data pending. In the latter case, the <FIN> is ignored until the data has been processed and acknowledged.
在收到启动器<FIN>（以及验证时间戳和Cookie对选项）后，响应程序将发送其<FIN，ACK（FIN）>，除非有其他待处理的数据。在后一种情况下，<FIN>被忽略，直到数据被处理和确认。
Upon receipt of the Responder <FIN,ACK(FIN)> (and verification of the Timestamps and Cookie-Pair options), the Initiator sends its final <ACK(FIN)> unless there is additional data pending. The Initiator enters TIME-WAIT state.
在收到响应者<FIN，ACK（FIN）>（以及时间戳和Cookie对选项的验证）后，发起方发送其最终<ACK（FIN）>，除非有其他未决数据。启动器进入等待时间状态。
This segment contains both Timestamps and Cookie-Pair options.
此段包含时间戳和Cookie对选项。
Upon receipt of the Initiator <ACK(FIN)> (and verification of the Timestamps and Cookie-Pair options), the Responder removes its TCB.
在收到启动器<ACK（FIN）>（以及时间戳和Cookie对选项的验证）后，响应程序将删除其TCB。
Upon arrival of more data prompting a new Cookie exchange, the Initiator SHOULD NOT send a final <ACK(FIN)> and/or SHOULD NOT wait the remaining TIME-WAIT interval. Any existing TSoffset SHOULD be incremented. TSoffset will be removed (with the TCB itself) at the conclusion of a future TIME-WAIT state.
当更多数据到达时，提示进行新的Cookie交换，发起方不应发送最终的<ACK（FIN）>和/或不应等待剩余的等待时间间隔。任何现有的TSoffset都应递增。TSoffset将在未来的等待状态结束时被删除（使用TCB本身）。
Upon receipt of the Responder <FIN> (and verification of the Timestamps and Cookie-Pair options), the Initiator sends its <FIN,ACK(FIN)> unless there is additional data pending. In the latter case, the <FIN> is ignored until the data has been processed and acknowledged.
在收到响应方<FIN>（以及验证时间戳和Cookie对选项）后，发起方将发送其<FIN，ACK（FIN）>，除非有其他未决数据。在后一种情况下，<FIN>被忽略，直到数据被处理和确认。
Upon receipt of the Initiator <FIN,ACK(FIN)> (and verification of the Timestamps and Cookie-Pair options), the Responder sends its final <ACK(FIN)> and removes its TCB.
在收到发起方<FIN，ACK（FIN）>（以及时间戳和Cookie对选项的验证）后，响应方发送其最终<ACK（FIN）>并移除其TCB。
This segment contains both Timestamps and Cookie-Pair options.
此段包含时间戳和Cookie对选项。
If the Responder's final <ACK(FIN)> is lost, the Responder is likely to send a <RST> (as the Responder retains no TCB state). This distinguished <RST> SHOULD copy both Timestamps and Cookie-Pair options.
如果响应者的最终<ACK（FIN）>丢失，响应者可能会发送<RST>（因为响应者没有保留TCB状态）。此选项应同时复制时间戳和Cookie对选项。
Upon receipt of the Responder's final <ACK(FIN)> (and verification of the Timestamps and Cookie-Pair options), the Initiator enters TIME-WAIT state.
在收到响应者的最终<ACK（FIN）>（以及时间戳和Cookie对选项的验证）后，启动器进入TIME-WAIT状态。
Upon arrival of more data prompting a new Cookie exchange, the Initiator SHOULD NOT send a <FIN,ACK(FIN)> and/or SHOULD NOT wait the remaining TIME-WAIT interval. Any existing TSoffset SHOULD be incremented. TSoffset will be removed (with the TCB itself) at the conclusion of a future TIME-WAIT state.
当更多数据到达时，提示进行新的Cookie交换，发起方不应发送<FIN，ACK（FIN）>和/或不应等待剩余的等待时间间隔。任何现有的TSoffset都应递增。TSoffset将在未来的等待状态结束时被删除（使用TCB本身）。
Support for accelerated open is OPTIONAL.
支持加速开放是可选的。
When an application is capable of idempotent transactions (such as a query that returns a consistent result or service response heading), the application sets the appropriate limit separately for each port or connection. Applications are responsible for ensuring that retransmissions do not cause duplication of data.
当应用程序能够执行幂等事务（例如返回一致结果或服务响应标题的查询）时，应用程序将分别为每个端口或连接设置适当的限制。应用程序负责确保重新传输不会导致数据重复。
This facility allows single data segment transactions without establishing TCB state at the Responder (server). For longer transactions, a short look-ahead of upcoming data allows the Initiator (client) to select alternatives for further processing.
此功能允许单数据段事务，而无需在响应程序（服务器）上建立TCB状态。对于较长的事务，对即将到来的数据进行一次简短的前瞻，允许发起方（客户机）选择备选方案进行进一步处理。
By default, the Initiator <SYN> does not contain data. The application sets the TCP_SYN_DATA_LIMIT to indicate that the <SYN> MAY be sent with data.
默认情况下，启动器<SYN>不包含数据。应用程序设置TCP_SYN_DATA_LIMIT以指示<SYN>可以与数据一起发送。
The Responder Maximum Segment Size (MSS) is unknown, and the default MSS (536 bytes) MUST be used instead ([RFC1122] section 4.2.2.6). This is further reduced by the total length of the TCP options (in this case, commonly 496 bytes). Applications MAY specify a shorter limit.
响应程序最大段大小（MSS）未知，必须使用默认MSS（536字节）（[RFC1122]第4.2.2.6节）。TCP选项的总长度（在本例中，通常为496字节）将进一步减少该值。应用程序可以指定较短的限制。
If the data will not entirely fit within the initial segment, data MUST NOT be sent until after the Responder's <SYN,ACK(SYN)> is received.
如果数据不完全适合初始段，则必须在收到响应者的<SYN，ACK（SYN）>后才能发送数据。
Unlike T/TCP [RFC1644], <FIN> SHOULD NOT be sent with <SYN> data. This facilitates persistent connections.
与T/TCP[RFC1644]不同，<FIN>不应与<SYN>数据一起发送。这有助于实现持久连接。
Likewise, <PSH> SHOULD NOT be set. Although the application might use push to indicate that its data is ready to send, the push is implied for <SYN> data segments.
同样，不应设置<PSH>。尽管应用程序可能使用推送来指示其数据已准备好发送，但推送是针对<SYN>数据段的。
During the initial exchange, the Initiator is solely responsible for retransmission. Although the cookie and sequence have not changed, each retransmission appears to the Responder as another original <SYN>.
在初始交换期间，发起者仅负责重新传输。尽管cookie和序列没有改变，但每次重新传输在响应者看来都是另一个原始的<SYN>。
Implementation Notes:
实施说明：
Initiator <SYN,FIN> with the Cookie option and no segment data is permitted in a test environment. This combination SHOULD be silently discarded.
启动器<SYN，FIN>带有Cookie选项，并且测试环境中不允许有任何段数据。这个组合应该被悄悄地丢弃。
Initiator <SYN,FIN> with both the Cookie option and segment data is similar to T/TCP [RFC1644]. However, whenever the Responder <SYN,ACK(SYN),FIN> has been sent with data (there is no further data expected), TCB state has not been saved at the Responder. There is no need to send <FIN> to close the connection.
同时具有Cookie选项和段数据的启动器<SYN，FIN>类似于T/TCP[RFC1644]。但是，每当响应程序<SYN，ACK（SYN），FIN>与数据一起发送时（预计不会有更多数据），TCB状态就不会保存在响应程序中。无需发送<FIN>来关闭连接。
By default, the Responder <SYN,ACK(SYN)> does not contain data. The application sets the TCP_SYN_ACK_DATA_LIMIT to indicate that the <SYN,ACK(SYN)> MAY be sent with data.
默认情况下，响应程序<SYN，ACK（SYN）>不包含数据。应用程序设置TCP_SYN_ACK_DATA_LIMIT以指示<SYN，ACK（SYN）>可以与数据一起发送。
Segment data is limited to the Maximum Transmission Unit (MTU). Applications MAY specify a shorter limit to prevent spoofed amplification and reflection attacks [RFC5358].
段数据限于最大传输单位（MTU）。应用程序可以指定较短的限制，以防止欺骗放大和反射攻击[RFC5358]。
Upon receipt of the <SYN> with a Cookie option, the Responder MAY process any data present. If the initial data is not accepted, the Acknowledgment Number will be the received Sequence Number plus one (1) for the <SYN>.
在收到带有Cookie选项的<SYN>后，响应者可以处理存在的任何数据。如果初始数据不被接受，则确认号将是收到的序列号加上<SYN>的一（1）。
If the segment data is the entire response (there is no further data expected), <FIN> MAY be set.
如果段数据是整个响应（预期没有更多数据），<FIN>可以设置。
However, <PSH> SHOULD NOT be set. Although the application might use push to indicate that its data is ready to send, the push is implied for <FIN> data segments (see [RFC793] section 3.7, page 41).
但是，不应设置<PSH>。尽管应用程序可能使用推送来表示其数据已准备好发送，但推送是针对<FIN>数据段的（请参见[RFC793]第3.7节，第41页）。
As the Responder retains no TCB state, retransmission timers are not available. Arrival of an Initiator's retransmission appears to be an original <SYN> transmission. There are no differences in processing.
由于应答器未保持TCB状态，因此重传计时器不可用。发起者的重传到达似乎是原始的<SYN>传输。在处理上没有区别。
Implementation Notes:
实施说明：
The Responder Cookie depends on the TCP Sequence and Acknowledgment Numbers after processing <SYN>. Therefore, neither will include data.
响应程序Cookie取决于处理<SYN>后的TCP序列和确认号。因此，两者都不包括数据。
Upon receipt of the <SYN,ACK(SYN)> with a Cookie option, the Initiator MAY process any data present. In this case, the internal RCV.NXT is advanced to provide at-most-once semantics.
在收到带有Cookie选项的<SYN，ACK（SYN）>后，发起方可以处理存在的任何数据。在这种情况下，内部RCV.NXT被提升为最多提供一次语义。
If the segment data is the entire response (there is no further data expected), the Initiator enters TIME-WAIT state.
如果段数据是整个响应（不需要更多数据），则启动器将进入TIME-WAIT状态。
Otherwise, original <SYN> data is retransmitted in <ACK(SYN)>, as its processing is optional. The Acknowledgment Number will be the received Sequence Number plus one (1) for the <SYN>. The Sequence Number will be the Initial Sequence Number (ISN) plus one (1) for the <SYN>.
否则，原始<SYN>数据将在<ACK（SYN）>中重新传输，因为其处理是可选的。对于<SYN>，确认号将是接收序列号加上一（1）。序列号将是初始序列号（ISN）加上<SYN>的一（1）。
Unlike T/TCP [RFC1644], there is no implicit acknowledgment.
与T/TCP[RFC1644]不同，没有隐式确认。
If the Selective Acknowledgment (Sack) option [RFC2018] has been successfully negotiated, a short Sack acknowledging the response data MAY be sent following the Cookie-Pair in the extended header.
如果已成功协商选择性确认（Sack）选项[RFC2018]，则可在扩展报头中的Cookie对之后发送确认响应数据的短Sack。
At this time, any second segment may be sent without awaiting an <ACK>, according to the usual [RFC5681] TCP congestion control process.
此时，根据通常的[RFC5681]TCP拥塞控制过程，可以在不等待<ACK>的情况下发送任何第二段。
Implementation Notes:
实施说明：
Upon arrival of more data prompting a new Cookie exchange, there is no need to increment the previous timestamp; TCB state has not been saved at the Responder. Instead, use the saved RCV.NXT, plus one (1) for the (actual or implied) <FIN>.
当更多数据到达时，提示进行新的Cookie交换，不需要增加以前的时间戳；TCB状态尚未保存在响应程序中。相反，使用保存的RCV.NXT，加上一（1）个用于（实际或暗示）<FIN>。
Initiator <ACK(SYN),FIN> with the Cookie-Pair option and no segment data is never required; TCB state has not been saved at the Responder. This combination MUST be silently discarded.
启动器<ACK（SYN），FIN>，具有Cookie对选项，不需要任何段数据；TCB状态尚未保存在响应程序中。必须悄悄地丢弃此组合。
Upon receipt of the <ACK(SYN)> with a Cookie-Pair option (and verification of the Timestamps and Cookie-Pair options), the Responder SHOULD process any data present.
在收到带有Cookie对选项的<ACK（SYN）>后（以及时间戳和Cookie对选项的验证），响应者应处理存在的任何数据。
Since the TCP Sequence and Acknowledgment Numbers have not advanced, the Responder will process the same incoming data, and transmit the same response.
由于TCP序列和确认号尚未提前，响应程序将处理相同的传入数据，并发送相同的响应。
If the Selective Acknowledgment (Sack) option [RFC2018] has been successfully negotiated, with a short Sack covering earlier response data, only additional unacknowledged response data is sent.
如果已成功协商选择性确认（Sack）选项[RFC2018]，且短Sack覆盖早期响应数据，则仅发送额外的未确认响应数据。
At this time, any second segment may be sent without awaiting an <ACK>, according to the usual [RFC5681] TCP congestion control process.
此时，根据通常的[RFC5681]TCP拥塞控制过程，可以在不等待<ACK>的情况下发送任何第二段。
When a TCB with matching Addresses and Ports is found, but the Cookie-Pair fails to verify, the datagram MUST be silently discarded.
当找到具有匹配地址和端口的TCB，但Cookie对无法验证时，必须以静默方式丢弃数据报。
When no TCB with matching Addresses and Ports is found, a <RST> is sent as usual. The Timestamps option SHOULD be copied [RFC1323]. A Cookie-Pair option MUST also be copied. The Cookie option (or Cookie-less option) MUST NOT be copied.
当没有找到具有匹配地址和端口的TCB时，会像往常一样发送<RST>。应复制时间戳选项[RFC1323]。还必须复制Cookie对选项。不得复制Cookie选项（或无Cookie选项）。
Any <RST> is always treated as advisory. A <RST> without a matching Cookie-Pair option could be caused by antique duplicates. Receipt has no effect on the operation of the protocol. The implementation SHOULD continue until a USER TIMEOUT expires. (See [RFC5482] for additional information.)
任何<RST>始终被视为建议。没有匹配的Cookie对选项的<RST>可能是由仿古副本引起的。接收对协议的操作没有影响。应继续执行，直到用户超时过期。（有关更多信息，请参阅[RFC5482]）
This also inhibits third parties from disrupting communications.
这也会阻止第三方中断通信。
A successful Cookie (or Cookie-less) option exchange signals availability of the TCP header extension. Other options with large data portions MAY also use this feature. The extended option data is processed in the order that the options appear.
成功的Cookie（或无Cookie）选项交换TCP头扩展的可用性信号。具有大数据部分的其他选项也可以使用此功能。扩展选项数据按选项出现的顺序进行处理。
(Kind 5 [RFC2018].) The pairs of 32-bit fields are well suited to the header extension. Because of its variable size, this is RECOMMENDED as the final extended option.
（第5类[RFC2018]）32位字段对非常适合标头扩展。由于其大小可变，建议将其作为最终扩展选项。
During the cookie exchange, the <ACK(SYN)> MAY include this option to acknowledge any optional transaction response data.
在cookie交换期间，<ACK（SYN）>可以包括此选项以确认任何可选的事务响应数据。
(Kind 8 [RFC1323].) Support is REQUIRED. See also section 3.
（第8类[RFC1323]）需要支持。另见第3节。
When a segment needs no header extension, and 32-bit timestamps have been negotiated, this option MUST be sent.
当一个段不需要头扩展，并且已经协商了32位时间戳时，必须发送此选项。
(Kinds 11-13 [RFC1644].) Incompatible with this specification, and MUST be ignored on receipt.
（第11-13类[RFC1644]）与本规范不兼容，在收到时必须忽略。
(Kind 19 [RFC2385].) This option is beyond the scope of this specification. Because specific configuration is required, sending is under the complete control of the operator. Segments lacking this option will be silently discarded.
（第19类[RFC2385]）此选项超出本规范的范围。由于需要特定的配置，发送由操作员完全控制。缺少此选项的段将被自动放弃。
The size of the option itself precludes use with the Cookie option in the <SYN>. Regardless of the system default, the Cookie option MUST NOT be sent, and MUST be ignored on receipt. Instead, the Cookie-less extension option indicates that other features of this specification are available.
选项本身的大小不允许与<SYN>中的Cookie选项一起使用。无论系统默认设置如何，Cookie选项都不能发送，并且在收到时必须忽略。相反，无Cookie扩展选项指示此规范的其他功能可用。
(Kind 29 [RFC5925].) This option is beyond the scope of this specification. Because specific configuration is required, sending is under the complete control of the operator. Segments lacking this option will be silently discarded.
（第29类[RFC5925]）此选项超出本规范的范围。由于需要特定的配置，发送由操作员完全控制。缺少此选项的段将被自动放弃。
The size of the option itself precludes use with the Cookie option in the <SYN>. Regardless of the system default, the Cookie option MUST NOT be sent, and MUST be ignored on receipt. Instead, the Cookie-less extension option indicates that other features of this specification are available.
选项本身的大小不允许与<SYN>中的Cookie选项一起使用。无论系统默认设置如何，Cookie选项都不能发送，并且在收到时必须忽略。相反，无Cookie扩展选项指示此规范的其他功能可用。
T/TCP [RFC1379] [RFC1644] permits lightweight TCP transactions for applications that traditionally have used UDP. However, T/TCP has unacceptable security issues [Hannum1996] [Phrack1998].
T/TCP[RFC1379][RFC1644]允许传统上使用UDP的应用程序进行轻量级TCP事务。然而，T/TCP存在不可接受的安全问题[Hannum1996][Phrack1998]。
The initial specification [KS1995] of Photuris [RFC2522], now called version 1 (December 1994 to March 1995), was based on a short list of design requirements, and simple experimental code by Phil Karn. A "Cookie" Exchange guards against simple flooding attacks sent with bogus IP Sources or UDP Ports.
Photuris[RFC2522]的初始规范[KS1995]，现称为第1版（1994年12月至1995年3月），基于设计要求的简短列表和Phil Karn的简单实验代码。“Cookie”交换可以防止使用伪造的IP源或UDP端口发送的简单洪泛攻击。
During 1995, the Photuris efficient secret rollover and many other extensions were specified. Multiple interoperable implementations were produced.
1995年期间，指定了Photuris高效秘密翻转和许多其他扩展。产生了多个可互操作的实现。
By September 1996, the long anticipated Denial of Service (DoS) attacks in the form of TCP SYN floods were devastating popular (and unpopular) servers and sites. Phil Karn informally mentioned adapting anti-clogging cookies to TCP. Perry Metzger proposed adding Karn's cookies as part of a "TCP++" effort [Metzger1996].
到1996年9月，人们期待已久的以TCP SYN洪水形式出现的拒绝服务（DoS）攻击摧毁了流行（且不受欢迎）的服务器和站点。Phil Karn非正式地提到将抗阻塞cookie应用于TCP。Perry Metzger建议将Karn的cookies添加为“TCP++”工作的一部分[Metzger1996]。
Later in 1996, Daniel J. Bernstein implemented "SYN cookies", small cookies embedded in the TCP SYN Initial Sequence Number (ISN). This technique was exceptionally clever, because it did not require cooperation of the remote party and could be deployed unilaterally. However, SYN cookies can only be used in emergencies; they are incompatible with most TCP options. As there is insufficient space in the Sequence Number, the cookie is not considered cryptologically secure. Therefore, the mechanism remains inactive until the system is under attack, and thus is not well tested in operation. SYN cookies were not accepted for publication until recently [RFC4987].
1996年晚些时候，Daniel J.Bernstein实现了“SYN cookies”，即嵌入在TCP SYN初始序列号（ISN）中的小cookies。这项技术非常聪明，因为它不需要远程方的合作，可以单方面部署。但是，SYN Cookie只能在紧急情况下使用；它们与大多数TCP选项不兼容。由于序列号中没有足够的空间，因此cookie不被认为是加密安全的。因此，在系统受到攻击之前，该机制一直处于非活动状态，因此未在运行中进行良好测试。直到最近[RFC4987]才接受发布SYN Cookie。
In 1998, Perry Metzger proposed adding Karn's cookies as part of a "TCPng" discussion [Metzger1998].
1998年，佩里·梅茨格（Perry Metzger）提议在“TCPng”讨论中加入卡恩的饼干[Metzger1998]。
In 1999, Faber, Touch, and Yue [FTY1999] proposed using an option to negotiate the party that would maintain TIME-WAIT state. This permits a server to entirely eliminate state after closing a connection.
1999年，Faber、Touch和Yue[FTY1999]提议使用一个选项来谈判将保持等待状态的一方。这允许服务器在关闭连接后完全消除状态。
In 2000, the Stream Control Transmission Protocol (SCTP) [RFC2960] was published with an inadequate partial cookie mechanism claiming to be based upon Photuris. It featured a deficient checksum (replaced in 2002 by [RFC3309] without graceful transition), and has undergone subsequent revisions [RFC4960].
2000年，流控制传输协议（SCTP）[RFC2960]发布时，声称基于Photuris的部分cookie机制不足。它有一个缺陷校验和（在2002年被[RFC3309]取代，没有优雅的转换），并经历了后续修订[RFC4960]。
In 2006, the Datagram Congestion Control Protocol (DCCP) [RFC4340] was published with a mechanism analogous to SYN cookies.
2006年，发布了数据报拥塞控制协议（DCCP）[RFC4340]，其机制类似于SYN cookies。
Andre Broido informally described utilizing cookies for Transport Layer Security (TLS) session identifiers, in place of the [RFC5077] ticket. Rapid TLS session resumption would improve both latency and privacy, but is beyond the scope of this specification. Also, he provided numerous helpful comments and additional references, such as [KBC2005].
Andre Broido非正式地描述了使用Cookie作为传输层安全（TLS）会话标识符来代替[RFC5077]票证。快速TLS会话恢复将改善延迟和隐私，但超出本规范的范围。此外，他还提供了许多有用的评论和其他参考资料，如[KBC2005]。
H. K. Jerry Chu and Arvind Jain informally described retaining existing cookies for accelerated open on subsequent connections. That feature was subsumed by this specification.
H.K.Jerry Chu和Arvind Jain非正式地描述了保留现有cookie以加速后续连接的开放。该特性包含在本规范中。
Wesley M. Eddy and Adam Langley previously proposed another pair of options [EL2008] extending the TCP header option space.
Wesley M.Eddy和Adam Langley之前提出了另一对扩展TCP报头选项空间的选项[EL2008]。
Adam Langley previously proposed another option [Langley2008] permitting <SYN,ACK(SYN)> constant payload data. His (August 2008) code was a base for the initial TCPCT implementation.
Adam Langley之前提出了另一个选项[Langley2008]，允许<SYN，ACK（SYN）>恒定有效载荷数据。他的（2008年8月）代码是初始TCPCT实现的基础。
Joe Touch postulated a (hopefully hypothetical) failure mode: options re-ordered by middleware. This caused a change in specifications, and has considerably complicated option interactions and processing. His helpful comments were appreciated.
Joe Touch假设了一种（希望是假设的）故障模式：由中间件重新排序的选项。这导致了规范的变化，并使选项交互和处理相当复杂。他有益的评论受到了赞赏。
Many thanks to Fernando Gont for suggestions, and Rick Jones for performance testing.
非常感谢Fernando Gont的建议，以及Rick Jones的性能测试。
Two TCP Option numbers are reserved for general experimental use under the rules laid out in [RFC4727] and [RFC3692] section 1. Such values reserved for experimental use are never to be made permanent; permanent assignments should be obtained through standard processes. Experimental numbers are intended for experimentation and testing and are not intended for wide or general deployments.
根据[RFC4727]和[RFC3692]第1节中规定的规则，保留两个TCP选项编号供一般实验使用。此类保留供实验使用的数值不得永久化；永久性任务应通过标准流程获得。实验数量用于实验和测试，不用于广泛或一般部署。
For further information, contact the author.
欲了解更多信息，请联系作者。
Any implementation of this specification SHOULD be configurable, separately for each port or connection.
本规范的任何实现都应该是可配置的，分别针对每个端口或连接。
TCPCT_COOKIE_DESIRED Values: 0 (disabled), 8, 10, 12, 14, 16. Default: 16. Send the Cookie option with the <SYN>.
TCPCT_COOKIE_所需值：0（禁用）、8、10、12、14、16。默认值：16。使用<SYN>发送Cookie选项。
TCPCT_EXTEND_TS[32|64|128] Default: off. If defined, may designate 32-bit, 64-bit, or 128-bit timestamps extension.
TCPCT|U EXTEND|TS[32 | 64 | 128]默认值：关闭。如果已定义，则可以指定32位、64位或128位时间戳扩展。
TCPCT_IN_ALWAYS Default: off. Silently discard any incoming <SYN> that is missing the Cookie option.
TCPCT_IN_始终默认：关闭。以静默方式放弃任何缺少Cookie选项的传入<SYN>。
TCPCT_OUT_NEVER Default: off. Refuse to send (override) the Cookie option.
TCPCT_OUT_从不默认：关闭。拒绝发送（覆盖）Cookie选项。
TCP_SYN_DATA_LIMIT Default: 0. Maximum: 496. The maximum amount of data transmitted with the <SYN>. Wait for data before sending.
TCP\u同步\u数据\u限制默认值：0。最高限额：496。使用<SYN>传输的最大数据量。发送前等待数据。
TCP_SYN_ACK_DATA_LIMIT Default: 0. Maximum: 1220. The maximum amount of data transmitted with the <SYN,ACK(SYN)>. Wait for data before sending.
TCP\u同步\u确认\u数据\u限制默认值：0。最高限额：1220。使用<SYN，ACK（SYN）>传输的最大数据量。发送前等待数据。
TCPCT was based on currently available tools, by experienced network protocol designers with an interest in cryptography, rather than by cryptographers with an interest in network protocols. This specification is intended to be readily implementable without requiring an extensive background in cryptology.
TCPCT是基于当前可用的工具，由对密码学感兴趣的经验丰富的网络协议设计师，而不是对网络协议感兴趣的密码学家。本规范旨在易于实现，无需广泛的密码学背景。
Therefore, only minimal background cryptologic discussion and rationale is included in this document. Although some review has been provided by the general cryptologic community, it is anticipated that design decisions and tradeoffs will be thoroughly analysed in subsequent dissertations and debated for many years to come. Cryptologic details are reserved for separate documents that may be more readily and timely updated with new analysis.
因此，本文件仅包含最低限度的密码学背景讨论和基本原理。虽然一般密码学界已经提供了一些评论，但预计设计决策和权衡将在随后的论文中进行彻底分析，并在未来的许多年中进行辩论。密码学详细信息保留给单独的文档，这些文档可能更容易通过新的分析及时更新。
The security depends on the quality of the random numbers generated by each party. Generating cryptographic quality random numbers on a general purpose computer without hardware assistance is a very tricky problem (see [RFC4086] for discussion).
安全性取决于各方生成的随机数的质量。在没有硬件协助的情况下，在通用计算机上生成加密质量随机数是一个非常棘手的问题（有关讨论，请参阅[RFC4086]）。
TCPCT is not intended to prevent or recover from all possible security threats. Rather, it is designed to inhibit inadvertent middlebox interference, while protecting against Denial of Service (DoS) attacks. (See [RFC4732], and [RFC3552] section 4.6.3 et seq.)
TCPCT的目的不是防止或恢复所有可能的安全威胁。相反，它旨在抑制无意中的中间箱干扰，同时防止拒绝服务（DoS）攻击。（参见[RFC4732]和[RFC3552]第4.6.3节等。）
The cookie exchange does not protect against an interloper that can race to substitute another value, nor an interceptor that can modify and/or replace a value. These attacks are considerably more difficult than passive vacuum-cleaner monitoring.
cookie交换不能防止可能竞相替换另一个值的入侵者，也不能防止可能修改和/或替换一个值的拦截器。这些攻击比被动真空吸尘器监控困难得多。
Note that each incoming <SYN,ACK(SYN)> replaces the Responder cookie. The initial exchange is most fragile, as protection against spoofing relies entirely upon the sequence and timestamp. This replacement strategy allows the correct pair to pass through, while any others will be filtered via Responder verification later.
请注意，每个传入的<SYN，ACK（SYN）>都会替换响应器cookie。初始交换是最脆弱的，因为防止欺骗完全依赖于序列和时间戳。此替换策略允许正确的配对通过，而其他配对将在稍后通过响应者验证进行过滤。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=MSS | Length=4 | (value) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=UTO | Length=4 | (timeout) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=SackOK | Length=2 | Kind=TS | Length=10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS Echo Reply |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=Cookie | Length=16 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ Cookie +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=wscale | Length=3 | (value) | Kind=EOL |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=MSS | Length=4 | (value) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=UTO | Length=4 | (timeout) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=SackOK | Length=2 | Kind=TS | Length=10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS Echo Reply |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=Cookie | Length=16 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ Cookie +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=wscale | Length=3 | (value) | Kind=EOL |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
A 14 byte (112-bit) Cookie barely fits with the other recommended options in the maximal 60 byte TCP header (40 bytes of option space).
14字节（112位）的Cookie与最大60字节TCP头（40字节的选项空间）中的其他推荐选项几乎不匹配。
Since the cookies are required to be the same size and meet a 32-bit alignment requirement, the implementor recognizes that this order provides optimal packing.
由于cookie需要相同的大小并满足32位对齐要求，所以实现者认识到此顺序提供了最佳打包。
The UserTimeOut (UTO) option can appear in other locations instead, such as following the Cookie option. Because some middleboxes are sensitive to the order of options, UTO should not appear before MSS nor between the TS and Cookie.
UserTimeOut（UTO）选项可以出现在其他位置，例如Cookie选项之后。由于某些中间盒对选项顺序敏感，因此UTO不应出现在MSS之前，也不应出现在TS和Cookie之间。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=TSX | Length=4 | Extend=16 | 0 | S=1 |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| TS Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS Echo Reply |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=nop | Kind=nop | Kind=Cookie | Length=30 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Initiator-Cookie +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ Responder-Cookie +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=MSS | Length=4 | (value) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=UTO | Length=4 | (timeout) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=nop | Kind=nop | Kind=Sack | Length=10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Starting Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ending Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=wscale | Length=3 | (value) | Kind=EOL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=TSX | Length=4 | Extend=16 | 0 | S=1 |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| TS Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS Echo Reply |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=nop | Kind=nop | Kind=Cookie | Length=30 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Initiator-Cookie +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ Responder-Cookie +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=MSS | Length=4 | (value) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=UTO | Length=4 | (timeout) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=nop | Kind=nop | Kind=Sack | Length=10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Starting Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ending Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=wscale | Length=3 | (value) | Kind=EOL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sack implies SackOK.
Sack意味着SackOK。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=TSX | Length=4 | Extend=15 | 0 | S=2 |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
+ TS Value +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ TS Echo Reply +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=SackOK | Length=2 | Kind=Cookie | Length=30 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Initiator-Cookie +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ Responder-Cookie +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=MSS | Length=4 | (value) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=UTO | Length=4 | (timeout) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=wscale | Length=3 | (value) | Kind=EOL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=TSX | Length=4 | Extend=15 | 0 | S=2 |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
+ TS Value +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ TS Echo Reply +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=SackOK | Length=2 | Kind=Cookie | Length=30 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Initiator-Cookie +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ Responder-Cookie +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=MSS | Length=4 | (value) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=UTO | Length=4 | (timeout) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=wscale | Length=3 | (value) | Kind=EOL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The larger 64-bit (or 128-bit) Timestamps extended option MUST be recognized, although the Responder MAY return a smaller Timestamps extended option.
必须识别较大的64位（或128位）时间戳扩展选项，尽管响应程序可能返回较小的时间戳扩展选项。
Normative References
规范性引用文件
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]Postel，J.，“互联网协议”，标准5，RFC7911981年9月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]Braden，R.，Ed.“互联网主机的要求-通信层”，STD 3，RFC 1122，1989年10月。
[RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323]Jacobson，V.，Braden，R.，和D.Borman，“高性能TCP扩展”，RFC 1323，1992年5月。
[RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", RFC 1948, May 1996.
[RFC1948]Bellovin，S.，“防御序列号攻击”，RFC 1948，1996年5月。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
[RFC2018]Mathis，M.，Mahdavi，J.，Floyd，S.，和A.Romanow，“TCP选择性确认选项”，RFC 2018，1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[RFC2988]Paxson，V.和M.Allman，“计算TCP的重传计时器”，RFC 2988，2000年11月。
[RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002.
[RFC3232]Reynolds，J.，Ed.“分配的数字：RFC 1700被在线数据库取代”，RFC 3232，2002年1月。
[RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More Resilient against Forged Answers", RFC 5452, January 2009.
[RFC5452]Hubert，A.和R.van Mook，“使DNS对伪造答案更具弹性的措施”，RFC 5452，2009年1月。
[RFC5482] Eggert, L. and F. Gont, "TCP User Timeout Option", RFC 5482, March 2009.
[RFC5482]Eggert，L.和F.Gont，“TCP用户超时选项”，RFC 54822009年3月。
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, September 2009.
[RFC5681]Allman，M.，Paxson，V.和E.Blanton，“TCP拥塞控制”，RFC 56812009年9月。
Informative References
资料性引用
[EL2008] Eddy, W. and A. Langley, "Extending the Space Available for TCP Options", Work in Progress, July 2008.
[EL2008]Eddy，W.和A.Langley，“扩展TCP选项的可用空间”，正在进行的工作，2008年7月。
[FTY1999] Faber, T., Touch, J., and W. Yue, "The TIME-WAIT state in TCP and Its Effect on Busy Servers", IEEE INFOCOM 99, pp. 1573-1584.
[FTY1999]Faber，T.，Touch，J.，和W.Yue，“TCP中的时间等待状态及其对繁忙服务器的影响”，IEEE INFOCOM 99，第1573-1584页。
[Gont2009] Gont, F., "Security assessment of the Transmission Control Protocol (TCP)", February 2009. https://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf
[Gont2009]Gont，F.，“传输控制协议（TCP）的安全评估”，2009年2月。https://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf
[GO2010] Gont, F. and A. Oppermann, "On the generation of TCP timestamps", Work in Progress, June 2010.
[GO2010]Gont，F.和A.Oppermann，“关于TCP时间戳的生成”，正在进行的工作，2010年6月。
[Hannum1996]
Hannum, C., "Security Problems Associated With T/TCP",
unpublished work in progress, September 1996.
http://www.mid-way.org/doc/ttcp-sec.txt
[Hannum1996]
Hannum, C., "Security Problems Associated With T/TCP",
unpublished work in progress, September 1996.
http://www.mid-way.org/doc/ttcp-sec.txt
[KBC2005] Kohno, T., Broido, A., and K. C. Claffy, "Remote physical
device fingerprinting", IEEE Symposium on Security and
Privacy, May 2005. http://www.caida.org/
outreach/papers/2005/fingerprinting/
KohnoBroidoClaffy05-devicefingerprinting.pdf
[KBC2005] Kohno, T., Broido, A., and K. C. Claffy, "Remote physical
device fingerprinting", IEEE Symposium on Security and
Privacy, May 2005. http://www.caida.org/
outreach/papers/2005/fingerprinting/
KohnoBroidoClaffy05-devicefingerprinting.pdf
[KS1995] Karn, P. and W. Simpson, "The Photuris Session Key Management Protocol", March 1995.
[KS1995]Karn，P.和W.Simpson，“Photuris会话密钥管理协议”，1995年3月。
Published as: "Photuris: Design Criteria", Proceedings of Sixth Annual Workshop on Selected Areas in Cryptography, LNCS 1758, Springer-Verlag. August 1999.
出版名称：“Photuris：设计标准”，第六届密码学选定领域年度研讨会论文集，LNCS 1758，Springer Verlag。1999年8月。
[Langley2008] Langley, A., "Faster application handshakes with SYN/ACK payloads", Work in Progress, August 2008.
[Langley2008]Langley，A.，“使用SYN/ACK有效载荷进行更快的应用程序握手”，正在进行的工作，2008年8月。
[MAF2004] Medina, A., Allman, M., and S. Floyd, "Measuring Interactions Between Transport Protocols and Middleboxes", Proceedings 4th ACM SIGCOMM/USENIX Conference on Internet Measurement, October 2004. http://www.icsi.berkeley.edu/pubs/networking/tbit-Aug2004.pdf
[MAF2004]Medina，A.，Allman，M.，和S.Floyd，“测量传输协议和中间盒之间的相互作用”，第四届ACM SIGCOMM/USENIX互联网测量会议论文集，2004年10月。http://www.icsi.berkeley.edu/pubs/networking/tbit-Aug2004.pdf
[Metzger1996]
Metzger, P., "Re: SYN floods (was: does history repeat
itself?)", September 9, 1996.
http://www.merit.net/mail.archives/nanog/
1996-09/msg00235.html
[Metzger1996]
Metzger, P., "Re: SYN floods (was: does history repeat
itself?)", September 9, 1996.
http://www.merit.net/mail.archives/nanog/
1996-09/msg00235.html
[Metzger1998]
Metzger, P., "Re: what a new TCP header might look like",
May 12, 1998. ftp://ftp.isi.edu/end2end/end2end-
interest-1998.mail
[Metzger1998]
Metzger, P., "Re: what a new TCP header might look like",
May 12, 1998. ftp://ftp.isi.edu/end2end/end2end-
interest-1998.mail
[Morris1985]
Morris, R., "A Weakness in the 4.2BSD Unix TCP/IP
Software", Technical Report CSTR-117, AT&T Bell
Laboratories, February 1985.
http://pdos.csail.mit.edu/~rtm/papers/117.pdf
[Morris1985]
Morris, R., "A Weakness in the 4.2BSD Unix TCP/IP
Software", Technical Report CSTR-117, AT&T Bell
Laboratories, February 1985.
http://pdos.csail.mit.edu/~rtm/papers/117.pdf
[MSV2009] Metzger, P., Simpson, W., and P. Vixie, "Improving TCP
Security With Robust Cookies", Usenix ;login:, December
2009. http://www.usenix.org/publications/login/
2009-12/openpdfs/metzger.pdf
[MSV2009] Metzger, P., Simpson, W., and P. Vixie, "Improving TCP
Security With Robust Cookies", Usenix ;login:, December
2009. http://www.usenix.org/publications/login/
2009-12/openpdfs/metzger.pdf
[Phrack1998]
route|daemon9, "T/TCP vulnerabilities", Phrack Magazine,
Volume 8, Issue 53, July 8, 1998.
http://www.phrack.org/issues.html?issue=53&id=6
[Phrack1998]
route|daemon9, "T/TCP vulnerabilities", Phrack Magazine,
Volume 8, Issue 53, July 8, 1998.
http://www.phrack.org/issues.html?issue=53&id=6
[RFC1379] Braden, R., "Extending TCP for Transactions -- Concepts", RFC 1379, November 1992.
[RFC1379]Braden，R.，“为事务扩展TCP——概念”，RFC 1379，1992年11月。
[RFC1644] Braden, R., "T/TCP -- TCP Extensions for Transactions Functional Specification", RFC 1644, July 1994.
[RFC1644]Braden，R.，“T/TCP——事务功能规范的TCP扩展”，RFC16441994年7月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385]Heffernan，A.，“通过TCP MD5签名选项保护BGP会话”，RFC 2385，1998年8月。
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management Protocol", RFC 2522, March 1999.
[RFC2522]Karn，P.和W.Simpson，“Photuris：会话密钥管理协议”，RFC 2522，1999年3月。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2827]Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，2000年5月。
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[RFC2960]Stewart，R.，Xie，Q.，Morneault，K.，Sharp，C.，Schwarzbauer，H.，Taylor，T.，Rytina，I.，Kalla，M.，Zhang，L.，和V.Paxson，“流控制传输协议”，RFC 29602000年10月。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[RFC3022]Srisuresh，P.和K.Egevang，“传统IP网络地址转换器（传统NAT）”，RFC 3022，2001年1月。
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.
[RFC3234]Carpenter，B.和S.Brim，“中间盒：分类和问题”，RFC 32342002年2月。
[RFC3309] Stone, J., Stewart, R., and D. Otis, "Stream Control Transmission Protocol (SCTP) Checksum Change", RFC 3309, September 2002.
[RFC3309]Stone，J.，Stewart，R.，和D.Otis，“流控制传输协议（SCTP）校验和更改”，RFC 33092002年9月。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[RFC3552]Rescorla，E.和B.Korver，“关于安全考虑的RFC文本编写指南”，BCP 72，RFC 3552，2003年7月。
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC3692]Narten，T.，“分配被认为有用的实验和测试数字”，BCP 82，RFC 3692，2004年1月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]Baker，F.和P.Savola，“多宿网络的入口过滤”，BCP 84，RFC 37042004年3月。
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]Eastlake 3rd，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，2005年6月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340]Kohler，E.，Handley，M.和S.Floyd，“数据报拥塞控制协议（DCCP）”，RFC 43402006年3月。
[RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.
[RFC4727]Fenner，B.，“IPv4、IPv6、ICMPv4、ICMPv6、UDP和TCP报头中的实验值”，RFC 4727，2006年11月。
[RFC4732] Handley, M., Ed., Rescorla, E., Ed., and Internet Architecture Board, "Internet Denial-of-Service Considerations", RFC 4732, November 2006.
[RFC4732]Handley，M.，Ed.，Rescorla，E.，Ed.，和互联网架构委员会，“互联网拒绝服务注意事项”，RFC 4732，2006年11月。
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", RFC 4953, July 2007.
[RFC4953]Touch，J.“保护TCP免受欺骗攻击”，RFC 4953，2007年7月。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]Stewart，R.，Ed.“流控制传输协议”，RFC 49602007年9月。
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, August 2007.
[RFC4987]Eddy，W.“TCP SYN洪泛攻击和常见缓解措施”，RFC 4987，2007年8月。
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, January 2008.
[RFC5077]Salowey，J.，Zhou，H.，Eronen，P.，和H.Tschofenig，“无服务器端状态的传输层安全（TLS）会话恢复”，RFC 5077，2008年1月。
[RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive Nameservers in Reflector Attacks", BCP 140, RFC 5358, October 2008.
[RFC5358]Damas，J.和F.Neves，“防止在反射器攻击中使用递归名称服务器”，BCP 140，RFC 5358，2008年10月。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
[RFC5925]Touch，J.，Mankin，A.，和R.Bonica，“TCP认证选项”，RFC 59252010年6月。
[RFC6056] Larson, M. and F. Gont, "Recommendations for Transport-Protocol Port Randomization", BCP 156, RFC 6056, January 2011.
[RFC6056]Larson，M.和F.Gont，“传输协议端口随机化建议”，BCP 156，RFC 6056，2011年1月。
[rfc1323bis] Borman, D., Braden, R., and V. Jacobson., "TCP Extensions for High Performance", Work in Progress, March 2009.
[rfc1323bis]Borman，D.，Braden，R.，和V.Jacobson.，“高性能TCP扩展”，正在进行的工作，2009年3月。
Author's Address
作者地址
Questions about this document can be directed to:
有关本文件的问题，请联系：
William Allen Simpson DayDreamer Computer Systems Consulting Services 1384 Fontaine Madison Heights, Michigan 48071
William Allen Simpson DayDreamer计算机系统咨询服务1384 Fontaine Madison Heights，Michigan 48071
EMail: William.Allen.Simpson@Gmail.com
EMail: William.Allen.Simpson@Gmail.com