Internet Engineering Task Force (IETF) F. Gont
Request for Comments: 6191 UK CPNI
BCP: 159 April 2011
Category: Best Current Practice
ISSN: 2070-1721
Internet Engineering Task Force (IETF) F. Gont
Request for Comments: 6191 UK CPNI
BCP: 159 April 2011
Category: Best Current Practice
ISSN: 2070-1721
Reducing the TIME-WAIT State Using TCP Timestamps
使用TCP时间戳减少等待时间状态
Abstract
摘要
This document describes an algorithm for processing incoming SYN segments that allows higher connection-establishment rates between any two TCP endpoints when a TCP Timestamps option is present in the incoming SYN segment. This document only modifies processing of SYN segments received for connections in the TIME-WAIT state; processing in all other states is unchanged.
本文档描述了一种处理传入SYN段的算法，当传入SYN段中存在TCP时间戳选项时，该算法允许在任意两个TCP端点之间建立更高的连接速率。本文档仅修改为处于等待状态的连接接收的SYN段的处理；所有其他状态下的处理都保持不变。
Status of This Memo
关于下段备忘
This memo documents an Internet Best Current Practice.
本备忘录记录了互联网最佳实践。
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). Further information on BCPs is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关BCP的更多信息，请参见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/rfc6191.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6191.
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. 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许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Improved Processing of Incoming Connection Requests . . . . . 3
3. Interaction with Various Timestamp Generation Algorithms . . . 6
4. Interaction with Various ISN Generation Algorithms . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . . 8
Appendix A. Behavior of the Proposed Mechanism in Specific
Scenarios . . . . . . . . . . . . . . . . . . . . . . 10
A.1. Connection Request after System Reboot . . . . . . . . . . 10
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Improved Processing of Incoming Connection Requests . . . . . 3
3. Interaction with Various Timestamp Generation Algorithms . . . 6
4. Interaction with Various ISN Generation Algorithms . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . . 8
Appendix A. Behavior of the Proposed Mechanism in Specific
Scenarios . . . . . . . . . . . . . . . . . . . . . . 10
A.1. Connection Request after System Reboot . . . . . . . . . . 10
The Timestamps option, specified in RFC 1323 [RFC1323], allows a TCP to include a timestamp value in its segments that can be used to perform two functions: Round-Trip Time Measurement (RTTM) and Protection Against Wrapped Sequences (PAWS).
RFC 1323[RFC1323]中规定的时间戳选项允许TCP在其段中包含时间戳值，该时间戳值可用于执行两个功能：往返时间测量（RTTM）和包裹序列保护（PAW）。
For the purpose of PAWS, the timestamps sent on a connection are required to be monotonically increasing. While there is no requirement that timestamps are monotonically increasing across TCP connections, the generation of timestamps such that they are monotonically increasing across connections between the same two endpoints allows the use of timestamps for improving the handling of SYN segments that are received while the corresponding four-tuple is in the TIME-WAIT state. That is, the Timestamps option could be used to perform heuristics to determine whether to allow the creation of a new incarnation of a connection that is in the TIME-WAIT state.
对于PAW，在连接上发送的时间戳必须是单调递增的。虽然不要求时间戳在TCP连接之间单调增加，时间戳的生成使得它们在相同的两个端点之间的连接之间单调增加，从而允许使用时间戳来改进在相应的四元组处于等待状态时接收的SYN段的处理。也就是说，时间戳选项可用于执行试探，以确定是否允许创建处于等待时间状态的连接的新化身。
This use of TCP timestamps is simply an extrapolation of the use of Initial Sequence Numbers (ISNs) for the same purpose, as allowed by RFC 1122 [RFC1122], and it has been incorporated in a number of TCP implementations, such as that included in the Linux kernel [Linux].
TCP时间戳的使用只是出于RFC 1122[RFC1122]所允许的相同目的而使用初始序列号（ISN）的外推，并且它已被纳入许多TCP实现中，例如Linux内核[Linux]中包含的TCP实现中。
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]中所述进行解释。
In a number of scenarios, a socket pair may need to be reused while the corresponding four-tuple is still in the TIME-WAIT state in a remote TCP peer. For example, a client accessing some service on a host may try to create a new incarnation of a previous connection, while the corresponding four-tuple is still in the TIME-WAIT state at the remote TCP peer (the server). This may happen if the ephemeral port numbers are being reused too quickly, either because of a bad policy of selection of ephemeral ports, or simply because of a high connection rate to the corresponding service. In such scenarios, the establishment of new connections that reuse a four-tuple that is in the TIME-WAIT state would fail. This problem is discussed in detail in [INFOCOM-99].
在许多场景中，当远程TCP对等中对应的四元组仍处于等待状态时，可能需要重用套接字对。例如，在远程TCP对等方（服务器）上，当相应的四元组仍处于等待状态时，访问主机上某些服务的客户端可能会尝试创建以前连接的新版本。如果由于选择临时端口的错误策略，或者仅仅因为与相应服务的高连接率，临时端口号被过快地重用，则可能会发生这种情况。在这种情况下，建立新连接以重用处于TIME-WAIT状态的四元组将失败。这个问题在[INFOCOM-99]中有详细讨论。
In order to avoid this problem, Section 4.2.2.13 of RFC 1122 [RFC1122] states that when a connection request is received with a four-tuple that is in the TIME-WAIT state, the connection request may be accepted if the sequence number of the incoming SYN segment is greater than the last sequence number seen on the previous incarnation of the connection (for that direction of the data transfer). The goal of this requirement is to prevent the overlap of the sequence number spaces of the old and new incarnations of the connection so that segments from the old incarnation are not accepted as valid by the new incarnation.
为了避免此问题，RFC 1122[RFC1122]第4.2.2.13节规定，当接收到连接请求时，四元组处于等待状态，如果传入SYN段的序列号大于上一次连接上看到的最后一个序列号（对于该数据传输方向），则可以接受连接请求。该要求的目标是防止连接的新旧化身的序列号空间重叠，从而新化身不接受来自旧化身的段。
The same policy may be extrapolated to TCP timestamps. That is, when a connection request is received with a four-tuple that is in the TIME-WAIT state, the connection request could be accepted if the timestamp of the incoming SYN segment is greater than the last timestamp seen on the previous incarnation of the connection (for that direction of the data transfer).
相同的策略可以外推到TCP时间戳。也就是说，当使用处于TIME-WAIT状态的四元组接收到连接请求时，如果传入SYN段的时间戳大于在连接的前一个版本上看到的最后一个时间戳（对于该数据传输方向），则可以接受连接请求。
The following paragraphs summarize the processing of SYN segments received for connections in the TIME-WAIT state. The processing of SYN segments received for connections in all other states is unchanged. Both the ISN (Initial Sequence Number) and the Timestamps
以下段落总结了为处于TIME-WAIT状态的连接接收的SYN段的处理。在所有其他状态下，为连接接收的SYN段的处理保持不变。ISN（初始序列号）和时间戳
option (if present) of the incoming SYN segment are included in the heuristics performed for allowing a high connection-establishment rate.
传入SYN段的选项（如果存在）包括在为允许高连接建立率而执行的启发式中。
Processing of SYN segments received for connections in the TIME-WAIT state SHOULD occur as follows:
为处于等待状态的连接接收的SYN段的处理应如下所示：
o If the previous incarnation of the connection used Timestamps, then:
o 如果连接的前一个版本使用时间戳，则：
* If TCP Timestamps would be enabled for the new incarnation of the connection, and the timestamp contained in the incoming SYN segment is greater than the last timestamp seen on the previous incarnation of the connection (for that direction of the data transfer), honor the connection request (creating a connection in the SYN-RECEIVED state).
* 如果TCP时间戳将为连接的新版本启用，并且传入SYN段中包含的时间戳大于在连接的前一版本上看到的最后一个时间戳（对于该数据传输方向），请遵守连接请求（在SYN-RECEIVED状态下创建连接）。
* If TCP Timestamps would be enabled for the new incarnation of the connection, the timestamp contained in the incoming SYN segment is equal to the last timestamp seen on the previous incarnation of the connection (for that direction of the data transfer), and the Sequence Number of the incoming SYN segment is greater than the last sequence number seen on the previous incarnation of the connection (for that direction of the data transfer), honor the connection request (creating a connection in the SYN-RECEIVED state).
* 如果TCP时间戳将为新版本的连接启用，则传入SYN段中包含的时间戳等于上一版本的连接上看到的最后一个时间戳（对于该数据传输方向），并且传入SYN段的序列号大于连接前一个版本上看到的最后一个序列号（对于该数据传输方向），请遵守连接请求（在SYN-RECEIVED状态下创建连接）。
* If TCP Timestamps would not be enabled for the new incarnation of the connection, but the Sequence Number of the incoming SYN segment is greater than the last sequence number seen on the previous incarnation of the connection (for the same direction of the data transfer), honor the connection request (creating a connection in the SYN-RECEIVED state).
* 如果TCP时间戳不会为新版本的连接启用，但传入SYN段的序列号大于上一版本的连接上看到的最后一个序列号（对于相同的数据传输方向），请遵守连接请求（在SYN-RECEIVED状态下创建连接）。
* Otherwise, silently drop the incoming SYN segment, thus leaving the previous incarnation of the connection in the TIME-WAIT state.
* 否则，将静默地删除传入的SYN段，从而使连接的前一个化身处于TIME-WAIT状态。
o If the previous incarnation of the connection did not use Timestamps, then:
o 如果连接的前一个版本未使用时间戳，则：
* If TCP Timestamps would be enabled for the new incarnation of the connection, honor the incoming connection request (creating a connection in the SYN-RECEIVED state).
* 如果TCP时间戳将为连接的新化身启用，则接受传入的连接请求（以SYN-RECEIVED状态创建连接）。
* If TCP Timestamps would not be enabled for the new incarnation of the connection, but the Sequence Number of the incoming SYN segment is greater than the last sequence number seen on the previous incarnation of the connection (for the same direction of the data transfer), honor the incoming connection request (creating a connection in the SYN-RECEIVED state).
* 如果TCP时间戳不会为新版本的连接启用，但传入SYN段的序列号大于上一版本的连接上看到的最后一个序列号（对于相同的数据传输方向），请接受传入的连接请求（在SYN-RECEIVED状态下创建连接）。
* Otherwise, silently drop the incoming SYN segment, thus leaving the previous incarnation of the connection in the TIME-WAIT state.
* 否则，将静默地删除传入的SYN段，从而使连接的前一个化身处于TIME-WAIT状态。
Note:
注:
In the above explanation, the phrase "TCP Timestamps would be enabled for the new incarnation for the connection" means that the incoming SYN segment contains a TCP Timestamps option (i.e., the client has enabled TCP Timestamps), and that the SYN/ACK segment that would be sent in response to it would also contain a Timestamps option (i.e., the server has enabled TCP Timestamps). In such a scenario, TCP Timestamps would be enabled for the new incarnation of the connection.
在上面的解释中，短语“TCP时间戳将为连接的新化身启用”意味着传入的SYN段包含TCP时间戳选项（即，客户端已启用TCP时间戳），并且将作为响应发送的SYN/ACK段也将包含时间戳选项（即，服务器已启用TCP时间戳）。在这种情况下，TCP时间戳将为连接的新化身启用。
The "last sequence number seen on the previous incarnation of the connection (for the same direction of the data transfer)" refers to the last sequence number used by the previous incarnation of the connection (for the same direction of the data transfer), and not to the last value seen in the Sequence Number field of the corresponding segments. That is, it refers to the sequence number corresponding to the FIN flag of the previous incarnation of the connection, for that direction of the data transfer.
“在连接的前一个版本上看到的最后一个序列号（对于数据传输的相同方向）”指的是连接的前一个版本使用的最后一个序列号（对于数据传输的相同方向），而不是对应段的序列号字段中看到的最后一个值。也就是说，对于该数据传输方向，它是指与连接的前一个版本的FIN标志相对应的序列号。
Many implementations do not include the TCP Timestamps option when performing the above heuristics, thus imposing stricter constraints on the generation of Initial Sequence Numbers, the average data transfer rate of the connections, and the amount of data transferred with them. RFC 793 [RFC0793] states that the ISN generator should be incremented roughly once every four microseconds (i.e., roughly 250,000 times per second). As a result, any connection that transfers more than 250,000 bytes of data at more than 250 kilobytes/ second could lead to scenarios in which the last sequence number seen on a connection that moves into the TIME-WAIT state is still greater than the sequence number of an incoming SYN segment that aims at creating a new incarnation of the same connection. In those scenarios, the ISN heuristics would fail, and therefore the connection request would usually time out. By including the TCP Timestamps option in the heuristics described above, all these constraints are greatly relaxed.
许多实现在执行上述启发式时不包括TCP Timestamps选项，因此对初始序列号的生成、连接的平均数据传输速率以及与之一起传输的数据量施加了更严格的限制。RFC 793[RFC0793]指出，ISN生成器应大约每四微秒递增一次（即大约每秒250000次）。因此任何以超过250千字节/秒的速度传输超过250000字节数据的连接都可能导致出现这样的情况，即在进入TIME-WAIT状态的连接上看到的最后一个序列号仍然大于旨在创建同一连接的新化身的传入SYN段的序列号。在这些场景中，ISN启发式将失败，因此连接请求通常会超时。通过将TCP时间戳选项包括在上述启发式中，所有这些约束都大大放松了。
It is clear that the use of TCP timestamps for the heuristics described above benefit from timestamps that are monotonically increasing across connections between the same two TCP endpoints.
显然，在上述启发式中使用TCP时间戳受益于在相同的两个TCP端点之间的连接中单调增加的时间戳。
Note: The upcoming revision of RFC 1323, [1323bis], recommends the selection of timestamps such that they are monotonically increasing across connections. An example of such a timestamp generation scheme can be found in [TS-Generation].
注：RFC 1323[1323bis]即将发布的修订版建议选择时间戳，以便它们在连接之间单调增加。这种时间戳生成方案的示例可以在[TS generation]中找到。
The algorithm proposed in Section 2 clearly benefits from timestamps that are monotonically increasing across connections to the same endpoint. In particular, generation of timestamps such that they are monotonically increasing is important for TCP instances that perform the active open, as those are the timestamps that will be used for the proposed algorithm.
第2节中提出的算法明显受益于在连接到同一端点时单调增加的时间戳。特别是，时间戳的生成使得它们单调增加对于执行主动打开的TCP实例来说非常重要，因为这些时间戳将用于所提出的算法。
While monotonically increasing timestamps ensure that the proposed algorithm will be able to reduce the TIME-WAIT state of a previous incarnation of a connection, implementation of the algorithm (by itself) does not imply a requirement on the timestamp generation algorithm of other TCP implementations.
虽然单调增加的时间戳确保所提出的算法将能够减少连接的前一个化身的等待时间状态，但该算法的实现（本身）并不意味着对其他TCP实现的时间戳生成算法的要求。
In the worst-case scenario, an incoming SYN corresponding to a new incarnation of a connection in the TIME-WAIT contains a timestamp that is smaller than the last timestamp seen on the previous incarnation of the connection, the heuristics fail, and the result is no worse than the current state of affairs. That is, the SYN segment is ignored (as specified in [RFC1337]), and thus the connection request times out, or is accepted after future retransmissions of the SYN.
在最坏的情况下，与TIME-WAIT中的连接的新化身相对应的传入SYN包含的时间戳小于在连接的前一化身上看到的最后一个时间戳，启发式失败，结果不比当前状态差。也就是说，SYN段被忽略（如[RFC1337]中所述），因此连接请求超时，或者在将来重新传输SYN后被接受。
Some stacks may implement timestamp generation algorithms that do not lead to monotonically increasing timestamps across connections with the same remote endpoint. An example of such algorithms is the one described in [RFC4987] and [Opperman], which allows the implementation of extended TCP SYN cookies.
一些堆栈可以实现时间戳生成算法，这些算法不会导致在具有相同远程端点的连接之间单调增加时间戳。[RFC4987]和[Opperman]中描述的算法就是此类算法的一个示例，它允许实现扩展的TCP SYN Cookie。
Note: It should be noted that the "extended TCP SYN cookies" could coexist with an algorithm for generating timestamps such that they are monotonically increasing. Monotonically increasing timestamps could be generated for TCP instances that perform the active open, while timestamps for TCP instances that perform the passive open could be generated according to [Opperman].
注意：应该注意的是，“扩展TCP SYN cookies”可以与生成时间戳的算法共存，以便它们是单调递增的。对于执行主动打开的TCP实例，可以生成单调递增的时间戳，而对于执行被动打开的TCP实例，可以根据[Opperman]生成时间戳。
Some stacks (notably OpenBSD) implement timestamp randomization algorithms which do not result in monotonically increasing ISNs across connections. As noted in [Silbersack], such randomization schemes may prevent the mechanism proposed in this document from recycling connections that are in the TIME-WAIT state. However, as noted earlier in this section in the worst-case scenario, the heuristics fail, and the result is no worse than the current state of affairs.
一些堆栈（尤其是OpenBSD）实现了时间戳随机化算法，这些算法不会导致连接间的ISN单调增加。如[Silbersack]中所述，此类随机化方案可能会阻止本文档中提出的机制回收处于等待时间状态的连接。然而，正如本节前面在最坏情况场景中所述，启发式失败，结果并不比当前情况更糟。
[RFC0793] suggests that the ISNs of TCP connections be generated from a global timer, such that they are monotonically increasing across connections. However, this ISN-generation scheme leads to predictable ISNs, which have well-known security implications [CPNI-TCP]. [RFC1948] proposes an alternative ISN-generation scheme that results in monotonically increasing ISNs across connections that are not easily predictable by an off-path attacker.
[RFC0793]建议TCP连接的iSN由全局计时器生成，以便它们在连接之间单调递增。然而，这种ISN生成方案会产生可预测的ISN，这具有众所周知的安全含义[CPNI-TCP]。[RFC1948]提出了一种替代的ISN生成方案，该方案会导致连接间的ISN单调增加，而非路径攻击者很难预测这种情况。
Some stacks (notably OpenBSD) implement ISN randomization algorithms which do not result in monotonically increasing ISNs across connections. As noted in [Silbersack], such ISN randomization schemes break BSD's improved handling of SYN segments received for connections that are in the TIME-WAIT state.
一些堆栈（尤其是OpenBSD）实现ISN随机化算法，这些算法不会导致连接间ISN单调增加。如[Silbersack]中所述，此类ISN随机化方案打破了BSD对处于等待状态的连接接收的SYN段的改进处理。
An implementation of the mechanism proposed in this document would enable recycling of the TIME-WAIT state even in the presence of ISNs that are not monotonically increasing across connections, except when the timestamp contained in the incoming SYN is equal to the last timestamp seen on the connection in the TIME-WAIT state (for that direction of the data transfer).
本文件中提出的机制的实现将使得即使在存在ISN的情况下，也能够循环使用等待时间状态，ISN在连接之间不是单调增加的，除非传入SYN中包含的时间戳等于在等待时间状态下在连接上看到的最后一个时间戳（用于数据传输的该方向）。
[TCP-Security] contains a detailed discussion of the security implications of TCP Timestamps and of different timestamp generation algorithms.
[TCP Security]详细讨论了TCP时间戳和不同时间戳生成算法的安全含义。
This document is based on part of the contents of the technical report "Security Assessment of the Transmission Control Protocol (TCP)" [CPNI-TCP] written by Fernando Gont on behalf of the United Kingdom's Centre for the Protection of National Infrastructure (UK CPNI).
本文件基于Fernando Gont代表英国国家基础设施保护中心（英国CPNI）编写的技术报告“传输控制协议（TCP）安全评估”[CPNI-TCP]的部分内容。
The author of this document would like to thank (in alphabetical order) Mark Allman, Francis Dupont, Wesley Eddy, Lars Eggert, John Heffner, Alfred Hoenes, Christian Huitema, Eric Rescorla, Joe Touch, and Alexander Zimmermann for providing valuable feedback on an earlier version of this document.
本文件的作者要感谢（按字母顺序排列）马克·奥尔曼、弗朗西斯·杜邦、卫斯理·艾迪、拉尔斯·艾格特、约翰·赫夫纳、阿尔弗雷德·霍恩斯、克里斯蒂安·惠特马、埃里克·雷斯科拉、乔·图奇和亚历山大·齐默尔曼为本文件的早期版本提供了宝贵的反馈。
Additionally, the author would like to thank David Borman for a fruitful discussion on TCP Timestamps at IETF 73.
此外，作者还要感谢David Borman在IETF 73上对TCP时间戳进行了富有成效的讨论。
Finally, the author would like to thank the United Kingdom's Centre for the Protection of National Infrastructure (UK CPNI) for their continued support.
最后，作者要感谢联合王国国家基础设施保护中心（UK CPNI）的持续支持。
Fernando Gont's attendance to IETF meetings was supported by ISOC's "Fellowship to the IETF" program.
费尔南多·冈特出席IETF会议得到了ISOC“IETF奖学金”计划的支持。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]Braden，R.，“互联网主机的要求-通信层”，标准3，RFC 1122，1989年10月。
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323]Jacobson，V.，Braden，B.，和D.Borman，“高性能TCP扩展”，RFC 1323，1992年5月。
[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月。
[1323bis] Borman, D., Braden, R., and V. Jacobson, "TCP Extensions for High Performance", Work in Progress, March 2009.
[1323bis]Borman，D.，Braden，R.，和V.Jacobson，“高性能TCP扩展”，正在进行的工作，2009年3月。
[CPNI-TCP] CPNI, "Security Assessment of the Transmission Control Protocol (TCP)", 2009, <http://www.cpni.gov.uk/Docs/ tn-03-09-security-assessment-TCP.pdf>.
[CPNI-TCP]CPNI，“传输控制协议（TCP）的安全评估”，2009年<http://www.cpni.gov.uk/Docs/ tn-03-09-security-assessment-TCP.pdf>。
[INFOCOM-99] Faber, T., Touch, J., and W. Yue, "The TIME-WAIT state in TCP and Its Effect on Busy Servers", Proc. IEEE Infocom, 1999, pp. 1573-1583.
[INFOCOM-99]Faber，T.，Touch，J.，和W.Yue，“TCP中的时间等待状态及其对繁忙服务器的影响”，Proc。IEEE Infocom，1999年，第1573-1583页。
[Linux] Linux Kernel Organization, "The Linux Kernel Archives", <http://www.kernel.org>.
[Linux]Linux内核组织，“Linux内核档案”<http://www.kernel.org>.
[Opperman] Oppermann, A., "FYI: Extended TCP syncookies in FreeBSD-current", post to the tcpm mailing list, September 2006, <http://www.ietf.org/mail-archive/ web/tcpm/current/msg02251.html>.
[Opperman]Oppermann，A.，“仅供参考：FreeBSD当前中的扩展TCP同步”，发布到tcpm邮件列表，2006年9月<http://www.ietf.org/mail-archive/ web/tcpm/current/msg02251.html>。
[RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP", RFC 1337, May 1992.
[RFC1337]Braden，B.，“TCP中的等待时间暗杀危险”，RFC 1337，1992年5月。
[RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", RFC 1948, May 1996.
[RFC1948]Bellovin，S.，“防御序列号攻击”，RFC 1948，1996年5月。
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, August 2007.
[RFC4987]Eddy，W.“TCP SYN洪泛攻击和常见缓解措施”，RFC 4987，2007年8月。
[Silbersack] Silbersack, M., "Improving TCP/IP security through randomization without sacrificing interoperability", EuroBSDCon 2005.
[Silbersack]Silbersack，M.“在不牺牲互操作性的情况下通过随机化提高TCP/IP安全性”，EuroBSDCon 2005。
[TCP-Security] Gont, F., "Security Assessment of the Transmission Control Protocol (TCP)", Work in Progress, January 2011.
[TCP安全]Gont，F.，“传输控制协议（TCP）的安全评估”，正在进行的工作，2011年1月。
[TS-Generation] Gont, F. and A. Oppermann, "On the generation of TCP timestamps", Work in Progress, June 2010.
[TS生成]Gont，F.和A.Oppermann，“关于TCP时间戳的生成”，正在进行的工作，2010年6月。
This section clarifies how this algorithm would operate in case a computer reboots, keeps the same IP address, loses memory of the previous timestamps, and then tries to reestablish a previous connection.
本节阐明了当计算机重新启动、保持相同的IP地址、丢失以前的时间戳内存，然后尝试重新建立以前的连接时，该算法将如何运行。
Firstly, as specified in [RFC0793], hosts must not establish new connections for a period of 2*MSL (Maximum Segment Lifetime) after they boot (this is the "quiet time" concept). As a result, in terms of specifications, this scenario should never occur.
首先，如[RFC0793]中所述，主机在启动后2*MSL（最大段生存期）内不得建立新连接（这是“静默时间”概念）。因此，就规范而言，这种情况永远不会发生。
If a host does not comply with the "quiet time concept", a connection request might be sent to a remote host while there is a previous incarnation of the same connection in the TIME-WAIT state at the remote host. In such a scenario, as a result of having lost memory of previous timestamps, the resulting timestamps might not be monotonically increasing, and hence the proposed algorithm might be unable to recycle the previous incarnation of the connection that is in the TIME-WAIT state. This case corresponds to the current state of affairs without the algorithm proposed in this document.
如果主机不符合“静默时间概念”，则在远程主机上有相同连接的前一个版本处于等待时间状态时，可能会向远程主机发送连接请求。在这样的场景中，由于丢失了先前时间戳的内存，结果时间戳可能不会单调增加，因此所提出的算法可能无法回收处于等待状态的连接的先前化身。这种情况对应于没有本文中提出的算法的当前情况。
Author's Address
作者地址
Fernando Gont UK Centre for the Protection of National Infrastructure
费尔南多·贡特英国国家基础设施保护中心
EMail: fernando@gont.com.ar
URI: http://www.cpni.gov.uk
EMail: fernando@gont.com.ar
URI: http://www.cpni.gov.uk