Internet Engineering Task Force (IETF) D. Borman
Request for Comments: 7323 Quantum Corporation
Obsoletes: 1323 B. Braden
Category: Standards Track University of Southern California
ISSN: 2070-1721 V. Jacobson
Google, Inc.
R. Scheffenegger, Ed.
NetApp, Inc.
September 2014
Internet Engineering Task Force (IETF) D. Borman
Request for Comments: 7323 Quantum Corporation
Obsoletes: 1323 B. Braden
Category: Standards Track University of Southern California
ISSN: 2070-1721 V. Jacobson
Google, Inc.
R. Scheffenegger, Ed.
NetApp, Inc.
September 2014
TCP Extensions for High Performance
高性能的TCP扩展
Abstract
摘要
This document specifies a set of TCP extensions to improve performance over paths with a large bandwidth * delay product and to provide reliable operation over very high-speed paths. It defines the TCP Window Scale (WS) option and the TCP Timestamps (TS) option and their semantics. The Window Scale option is used to support larger receive windows, while the Timestamps option can be used for at least two distinct mechanisms, Protection Against Wrapped Sequences (PAWS) and Round-Trip Time Measurement (RTTM), that are also described herein.
本文档指定了一组TCP扩展，以提高具有大带宽*延迟积的路径上的性能，并在超高速路径上提供可靠的操作。它定义了TCP窗口缩放（WS）选项和TCP时间戳（TS）选项及其语义。窗口缩放选项用于支持更大的接收窗口，而时间戳选项可用于至少两种不同的机制，即对包裹序列（PAW）的保护和往返时间测量（RTTM），这两种机制也在本文中描述。
This document obsoletes RFC 1323 and describes changes from it.
本文件废除了RFC 1323，并描述了其变化。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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 Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7323.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7323.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. TCP Performance . . . . . . . . . . . . . . . . . . . . . 4
1.2. TCP Reliability . . . . . . . . . . . . . . . . . . . . . 5
1.3. Using TCP options . . . . . . . . . . . . . . . . . . . . 6
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
2. TCP Window Scale Option . . . . . . . . . . . . . . . . . . . 8
2.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Window Scale Option . . . . . . . . . . . . . . . . . . . 8
2.3. Using the Window Scale Option . . . . . . . . . . . . . . 9
2.4. Addressing Window Retraction . . . . . . . . . . . . . . 10
3. TCP Timestamps Option . . . . . . . . . . . . . . . . . . . . 11
3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 11
3.2. Timestamps Option . . . . . . . . . . . . . . . . . . . . 12
4. The RTTM Mechanism . . . . . . . . . . . . . . . . . . . . . 14
4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 14
4.2. Updating the RTO Value . . . . . . . . . . . . . . . . . 15
4.3. Which Timestamp to Echo . . . . . . . . . . . . . . . . . 16
5. PAWS - Protection Against Wrapped Sequences . . . . . . . . . 19
5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 19
5.2. The PAWS Mechanism . . . . . . . . . . . . . . . . . . . 19
5.3. Basic PAWS Algorithm . . . . . . . . . . . . . . . . . . 20
5.4. Timestamp Clock . . . . . . . . . . . . . . . . . . . . . 22
5.5. Outdated Timestamps . . . . . . . . . . . . . . . . . . . 24
5.6. Header Prediction . . . . . . . . . . . . . . . . . . . . 25
5.7. IP Fragmentation . . . . . . . . . . . . . . . . . . . . 26
5.8. Duplicates from Earlier Incarnations of Connection . . . 26
6. Conclusions and Acknowledgments . . . . . . . . . . . . . . . 27
7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
7.1. Privacy Considerations . . . . . . . . . . . . . . . . . 29
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
9.1. Normative References . . . . . . . . . . . . . . . . . . 30
9.2. Informative References . . . . . . . . . . . . . . . . . 30
Appendix A. Implementation Suggestions . . . . . . . . . . . . . 34
Appendix B. Duplicates from Earlier Connection Incarnations . . 35
B.1. System Crash with Loss of State . . . . . . . . . . . . . 35
B.2. Closing and Reopening a Connection . . . . . . . . . . . 35
Appendix C. Summary of Notation . . . . . . . . . . . . . . . . 37
Appendix D. Event Processing Summary . . . . . . . . . . . . . . 38
Appendix E. Timestamps Edge Cases . . . . . . . . . . . . . . . 44
Appendix F. Window Retraction Example . . . . . . . . . . . . . 44
Appendix G. RTO Calculation Modification . . . . . . . . . . . . 45
Appendix H. Changes from RFC 1323 . . . . . . . . . . . . . . . 46
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. TCP Performance . . . . . . . . . . . . . . . . . . . . . 4
1.2. TCP Reliability . . . . . . . . . . . . . . . . . . . . . 5
1.3. Using TCP options . . . . . . . . . . . . . . . . . . . . 6
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
2. TCP Window Scale Option . . . . . . . . . . . . . . . . . . . 8
2.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Window Scale Option . . . . . . . . . . . . . . . . . . . 8
2.3. Using the Window Scale Option . . . . . . . . . . . . . . 9
2.4. Addressing Window Retraction . . . . . . . . . . . . . . 10
3. TCP Timestamps Option . . . . . . . . . . . . . . . . . . . . 11
3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 11
3.2. Timestamps Option . . . . . . . . . . . . . . . . . . . . 12
4. The RTTM Mechanism . . . . . . . . . . . . . . . . . . . . . 14
4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 14
4.2. Updating the RTO Value . . . . . . . . . . . . . . . . . 15
4.3. Which Timestamp to Echo . . . . . . . . . . . . . . . . . 16
5. PAWS - Protection Against Wrapped Sequences . . . . . . . . . 19
5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 19
5.2. The PAWS Mechanism . . . . . . . . . . . . . . . . . . . 19
5.3. Basic PAWS Algorithm . . . . . . . . . . . . . . . . . . 20
5.4. Timestamp Clock . . . . . . . . . . . . . . . . . . . . . 22
5.5. Outdated Timestamps . . . . . . . . . . . . . . . . . . . 24
5.6. Header Prediction . . . . . . . . . . . . . . . . . . . . 25
5.7. IP Fragmentation . . . . . . . . . . . . . . . . . . . . 26
5.8. Duplicates from Earlier Incarnations of Connection . . . 26
6. Conclusions and Acknowledgments . . . . . . . . . . . . . . . 27
7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
7.1. Privacy Considerations . . . . . . . . . . . . . . . . . 29
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
9.1. Normative References . . . . . . . . . . . . . . . . . . 30
9.2. Informative References . . . . . . . . . . . . . . . . . 30
Appendix A. Implementation Suggestions . . . . . . . . . . . . . 34
Appendix B. Duplicates from Earlier Connection Incarnations . . 35
B.1. System Crash with Loss of State . . . . . . . . . . . . . 35
B.2. Closing and Reopening a Connection . . . . . . . . . . . 35
Appendix C. Summary of Notation . . . . . . . . . . . . . . . . 37
Appendix D. Event Processing Summary . . . . . . . . . . . . . . 38
Appendix E. Timestamps Edge Cases . . . . . . . . . . . . . . . 44
Appendix F. Window Retraction Example . . . . . . . . . . . . . 44
Appendix G. RTO Calculation Modification . . . . . . . . . . . . 45
Appendix H. Changes from RFC 1323 . . . . . . . . . . . . . . . 46
The TCP protocol [RFC0793] was designed to operate reliably over almost any transmission medium regardless of transmission rate, delay, corruption, duplication, or reordering of segments. Over the years, advances in networking technology have resulted in ever-higher transmission speeds, and the fastest paths are well beyond the domain for which TCP was originally engineered.
TCP协议[RFC0793]设计用于在几乎任何传输介质上可靠运行，而不考虑传输速率、延迟、损坏、重复或段的重新排序。多年来，网络技术的进步带来了更高的传输速度，最快的路径远远超出了TCP最初设计的领域。
This document defines a set of modest extensions to TCP to extend the domain of its application to match the increasing network capability. It is an update to and obsoletes [RFC1323], which in turn is based upon and obsoletes [RFC1072] and [RFC1185].
本文档定义了一组对TCP的适度扩展，以扩展其应用程序的域，以匹配不断增长的网络能力。它是对[RFC1323]的更新和淘汰，而[RFC1323]又是基于[RFC1072]和[RFC1185]的更新和淘汰。
Changes between [RFC1323] and this document are detailed in Appendix H. These changes are partly due to errata in [RFC1323], and partly due to the improved understanding of how the involved components interact.
附录H详述了[RFC1323]与本文件之间的变更。这些变更部分是由于[RFC1323]中的勘误表，部分是由于对相关组件如何相互作用的理解有所提高。
For brevity, the full discussions of the merits and history behind the TCP options defined within this document have been omitted. [RFC1323] should be consulted for reference. It is recommended that a modern TCP stack implements and make use of the extensions described in this document.
为简洁起见，本文件中定义的TCP选项背后的优点和历史的完整讨论已被省略。应参考[RFC1323]。建议现代TCP堆栈实现并使用本文档中描述的扩展。
TCP performance problems arise when the bandwidth * delay product is large. A network having such paths is referred to as a "long, fat network" (LFN).
当带宽*延迟乘积较大时，会出现TCP性能问题。具有这种路径的网络称为“长胖网络”（LFN）。
There are two fundamental performance problems with basic TCP over LFN paths:
基本TCP over LFN路径存在两个基本性能问题：
(1) Window Size Limit
(1) 窗口大小限制
The TCP header uses a 16-bit field to report the receive window size to the sender. Therefore, the largest window that can be used is 2^16 = 64 KiB. For LFN paths where the bandwidth * delay product exceeds 64 KiB, the receive window limits the maximum throughput of the TCP connection over the path, i.e., the amount of unacknowledged data that TCP can send in order to keep the pipeline full.
TCP标头使用16位字段向发送方报告接收窗口大小。因此，可以使用的最大窗口是2^16=64 KiB。对于带宽*延迟乘积超过64 KiB的LFN路径，接收窗口限制该路径上TCP连接的最大吞吐量，即TCP可以发送的未确认数据量，以保持管道满。
To circumvent this problem, Section 2 of this memo defines a TCP option, "Window Scale", to allow windows larger than 2^16. This option defines an implicit scale factor, which is used to multiply the window size value found in a TCP header to obtain the true window size.
为了避免这个问题，本备忘录的第2节定义了一个TCP选项“窗口比例”，允许窗口大于2^16。此选项定义一个隐式比例因子，用于乘以TCP标头中的窗口大小值，以获得真实的窗口大小。
It must be noted that the use of large receive windows increases the chance of too quickly wrapping sequence numbers, as described below in Section 1.2, (1).
必须注意，使用较大的接收窗口会增加过快包装序列号的可能性，如下文第1.2节（1）所述。
(2) Recovery from Losses
(2) 弥补损失
Packet losses in an LFN can have a catastrophic effect on throughput.
LFN中的数据包丢失会对吞吐量产生灾难性影响。
To generalize the Fast Retransmit / Fast Recovery mechanism to handle multiple packets dropped per window, Selective Acknowledgments are required. Unlike the normal cumulative acknowledgments of TCP, Selective Acknowledgments give the sender a complete picture of which segments are queued at the receiver and which have not yet arrived.
为了将快速重传/快速恢复机制推广到处理每个窗口丢弃的多个数据包，需要选择性确认。与TCP的正常累积确认不同，选择性确认为发送方提供了在接收方排队的段和尚未到达的段的完整信息。
Selective Acknowledgments and their use are specified in separate documents, "TCP Selective Acknowledgment Options" [RFC2018], "An Extension to the Selective Acknowledgement (SACK) Option for TCP" [RFC2883], and "A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP" [RFC6675], and are not further discussed in this document.
选择性确认及其使用在单独的文件“TCP选择性确认选项”[RFC2018]、“TCP选择性确认（SACK）选项的扩展”[RFC2883]和“基于TCP选择性确认（SACK）的保守丢失恢复算法”[RFC6675]中有规定，在本文件中不作进一步讨论。
An especially serious kind of error may result from an accidental reuse of TCP sequence numbers in data segments. TCP reliability depends upon the existence of a bound on the lifetime of a segment: the "Maximum Segment Lifetime" or MSL.
数据段中TCP序列号的意外重用可能会导致一种特别严重的错误。TCP可靠性取决于段的生存期是否存在一个界限：“最大段生存期”或MSL。
Duplication of sequence numbers might happen in either of two ways:
序列号的重复可能以两种方式之一发生：
(1) Sequence number wrap-around on the current connection
(1) 当前连接上的序号环绕
A TCP sequence number contains 32 bits. At a high enough transfer rate of large volumes of data (at least 4 GiB in the same session), the 32-bit sequence space may be "wrapped" (cycled) within the time that a segment is delayed in queues.
TCP序列号包含32位。在大容量数据（同一会话中至少4 GiB）的足够高的传输速率下，32位序列空间可以在队列中的段延迟时间内被“包装”（循环）。
(2) Earlier incarnation of the connection
(2) 连接的早期化身
Suppose that a connection terminates, either by a proper close sequence or due to a host crash, and the same connection (i.e., using the same pair of port numbers) is immediately reopened. A delayed segment from the terminated connection could fall within the current window for the new incarnation and be accepted as valid.
假设一个连接通过正确的关闭顺序或由于主机崩溃而终止，并且同一个连接（即，使用同一对端口号）立即重新打开。来自终止连接的延迟段可能在新化身的当前窗口内，并被视为有效。
Duplicates from earlier incarnations, case (2), are avoided by enforcing the current fixed MSL of the TCP specification, as explained in Section 5.8 and Appendix B. In addition, the randomizing of ephemeral ports can also help to probabilistically reduce the chances of duplicates from earlier connections. However, case (1), avoiding the reuse of sequence numbers within the same connection, requires an upper bound on MSL that depends upon the transfer rate, and at high enough rates, a dedicated mechanism is required.
如第5.8节和附录B所述，通过强制执行TCP规范的当前固定MSL，可以避免早期版本（案例（2）中的重复。此外，临时端口的随机化也有助于从概率上减少早期连接中重复的机会。然而，情况（1）避免了在同一连接中重复使用序列号，需要依赖于传输速率的MSL上界，并且在足够高的速率下，需要专用机制。
A possible fix for the problem of cycling the sequence space would be to increase the size of the TCP sequence number field. For example, the sequence number field (and also the acknowledgment field) could be expanded to 64 bits. This could be done either by changing the TCP header or by means of an additional option.
循环序列空间的问题的一个可能解决方法是增加TCP序列号字段的大小。例如，序列号字段（以及确认字段）可以扩展为64位。这可以通过更改TCP头或通过附加选项来实现。
Section 5 presents a different mechanism, which we call PAWS, to extend TCP reliability to transfer rates well beyond the foreseeable upper limit of network bandwidths. PAWS uses the TCP Timestamps option defined in Section 3.2 to protect against old duplicates from the same connection.
第5节介绍了一种不同的机制，我们称之为PAWS，它将TCP可靠性扩展到传输速率远远超过可预见的网络带宽上限。PAWS使用第3.2节中定义的TCP时间戳选项来防止来自同一连接的旧副本。
The extensions defined in this document all use TCP options.
本文档中定义的扩展都使用TCP选项。
When [RFC1323] was published, there was concern that some buggy TCP implementation might crash on the first appearance of an option on a non-<SYN> segment. However, bugs like that can lead to denial-of-service (DoS) attacks against a TCP. Research has shown that most TCP implementations will properly handle unknown options on non-<SYN> segments ([Medina04], [Medina05]). But it is still prudent to be conservative in what you send, and avoiding buggy TCP implementation is not the only reason for negotiating TCP options on <SYN> segments.
[RFC1323]发布时，有人担心某些有缺陷的TCP实现可能会在非<SYN>段上首次出现选项时崩溃。然而，类似这样的错误可能会导致针对TCP的拒绝服务（DoS）攻击。研究表明，大多数TCP实现将正确处理非<SYN>段（[Medina04]、[Medina05]）上的未知选项。但在发送内容上还是要谨慎，避免错误的TCP实现并不是在<SYN>段上协商TCP选项的唯一原因。
The Window Scale option negotiates fundamental parameters of the TCP session. Therefore, it is only sent during the initial handshake. Furthermore, the Window Scale option will be sent in a <SYN,ACK> segment only if the corresponding option was received in the initial <SYN> segment.
窗口缩放选项协商TCP会话的基本参数。因此，它仅在初始握手期间发送。此外，只有在初始<SYN>段中收到相应选项时，才会在<SYN，ACK>段中发送窗口缩放选项。
The Timestamps option may appear in any data or <ACK> segment, adding 10 bytes (up to 12 bytes including padding) to the 20-byte TCP header. It is required that this TCP option will be sent on all non-<SYN> segments after an exchange of options on the <SYN> segments has indicated that both sides understand this extension.
时间戳选项可能出现在任何数据或<ACK>段中，向20字节的TCP报头添加10个字节（最多12个字节，包括填充）。在<SYN>段上的选项交换表明双方都理解此扩展后，需要在所有非<SYN>段上发送此TCP选项。
Research has shown that the use of the Timestamps option to take additional RTT samples within each RTT has little effect on the ultimate retransmission timeout value [Allman99]. However, there are other uses of the Timestamps option, such as the Eifel mechanism ([RFC3522], [RFC4015]) and PAWS (see Section 5), which improve overall TCP security and performance. The extra header bandwidth used by this option should be evaluated for the gains in performance and security in an actual deployment.
研究表明，使用时间戳选项在每个RTT内获取额外的RTT样本对最终重传超时值几乎没有影响[Allman99]。但是，时间戳选项还有其他用途，例如Eifel机制（[RFC3522]、[RFC4015]）和PAWS（参见第5节），它们可以提高总体TCP安全性和性能。应评估此选项使用的额外报头带宽在实际部署中的性能和安全性增益。
Appendix A contains a recommended layout of the options in TCP headers to achieve reasonable data field alignment.
附录A包含TCP头中选项的推荐布局，以实现合理的数据字段对齐。
Finally, we observe that most of the mechanisms defined in this document are important for LFNs and/or very high-speed networks. For low-speed networks, it might be a performance optimization to NOT use these mechanisms. A TCP vendor concerned about optimal performance over low-speed paths might consider turning these extensions off for low-speed paths, or allow a user or installation manager to disable them.
最后，我们观察到，本文中定义的大多数机制对于LFN和/或超高速网络非常重要。对于低速网络，不使用这些机制可能是一种性能优化。关注低速路径上的最优性能的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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
In this document, these words will appear with that interpretation only when in UPPER CASE. Lower case uses of these words are not to be interpreted as carrying [RFC2119] significance.
在本文件中，这些词语只有在大写时才会与该解释一起出现。这些词语的小写用法不得解释为具有[RFC2119]意义。
The window scale extension expands the definition of the TCP window to 30 bits and then uses an implicit scale factor to carry this 30-bit value in the 16-bit window field of the TCP header (SEG.WND in [RFC0793]). The exponent of the scale factor is carried in a TCP option, Window Scale. This option is sent only in a <SYN> segment (a segment with the SYN bit on), hence the window scale is fixed in each direction when a connection is opened.
窗口比例扩展将TCP窗口的定义扩展为30位，然后使用隐式比例因子在TCP标头的16位窗口字段中携带该30位值（参见[RFC0793]中的SEG.WND）。比例因子的指数在TCP选项“窗口比例”中携带。此选项仅在<SYN>段（SYN位打开的段）中发送，因此当连接打开时，窗口比例在每个方向上都是固定的。
The maximum receive window, and therefore the scale factor, is determined by the maximum receive buffer space. In a typical modern implementation, this maximum buffer space is set by default but can be overridden by a user program before a TCP connection is opened. This determines the scale factor, and therefore no new user interface is needed for window scaling.
最大接收窗口和比例因子由最大接收缓冲区空间决定。在典型的现代实现中，默认情况下会设置此最大缓冲区空间，但可以在打开TCP连接之前由用户程序覆盖。这决定了比例因子，因此窗口缩放不需要新的用户界面。
The three-byte Window Scale option MAY be sent in a <SYN> segment by a TCP. It has two purposes: (1) indicate that the TCP is prepared to both send and receive window scaling, and (2) communicate the exponent of a scale factor to be applied to its receive window. Thus, a TCP that is prepared to scale windows SHOULD send the option, even if its own scale factor is 1 and the exponent 0. The scale factor is limited to a power of two and encoded logarithmically, so it may be implemented by binary shift operations. The maximum scale exponent is limited to 14 for a maximum permissible receive window size of 1 GiB (2^(14+16)).
三字节窗口缩放选项可通过TCP以<SYN>段发送。它有两个目的：（1）指示TCP准备好发送和接收窗口缩放；（2）传递要应用于其接收窗口的缩放因子指数。因此，准备缩放窗口的TCP应发送该选项，即使其自身的缩放因子为1且指数为0。比例因子被限制为2的幂，并以对数编码，因此它可以通过二进制移位操作实现。对于1 GiB（2^（14+16））的最大允许接收窗口大小，最大比例指数限制为14。
TCP Window Scale option (WSopt):
TCP窗口缩放选项（WSopt）：
Kind: 3
种类：3
Length: 3 bytes
长度：3字节
+---------+---------+---------+
| Kind=3 |Length=3 |shift.cnt|
+---------+---------+---------+
1 1 1
+---------+---------+---------+
| Kind=3 |Length=3 |shift.cnt|
+---------+---------+---------+
1 1 1
This option is an offer, not a promise; both sides MUST send Window Scale options in their <SYN> segments to enable window scaling in either direction. If window scaling is enabled, then the TCP that sent this option will right-shift its true receive-window values by 'shift.cnt' bits for transmission in SEG.WND. The value 'shift.cnt'
这种选择是一种要约，而不是承诺；两侧必须在其<SYN>段中发送窗口缩放选项，以启用任意方向的窗口缩放。如果启用了窗口缩放，则发送此选项的TCP将通过“shift.cnt”位将其真实接收窗口值右移，以便在SEG.WND中传输。值“shift.cnt”
MAY be zero (offering to scale, while applying a scale factor of 1 to the receive window).
可能为零（提供缩放功能，同时将缩放因子1应用于接收窗口）。
This option MAY be sent in an initial <SYN> segment (i.e., a segment with the SYN bit on and the ACK bit off). If a Window Scale option was received in the initial <SYN> segment, then this option MAY be sent in the <SYN,ACK> segment. A Window Scale option in a segment without a SYN bit MUST be ignored.
该选项可在初始<SYN>段（即，SYN位打开且ACK位关闭的段）中发送。如果在初始<SYN>段中收到窗口缩放选项，则该选项可在<SYN，ACK>段中发送。必须忽略段中没有SYN位的窗口比例选项。
The window field in a segment where the SYN bit is set (i.e., a <SYN> or <SYN,ACK>) MUST NOT be scaled.
设置SYN位（即<SYN>或<SYN，ACK>）的段中的窗口字段不得缩放。
A model implementation of window scaling is as follows, using the notation of [RFC0793]:
使用[RFC0793]符号，窗口缩放的模型实现如下所示：
o The connection state is augmented by two window shift counters, Snd.Wind.Shift and Rcv.Wind.Shift, to be applied to the incoming and outgoing window fields, respectively.
o 连接状态由两个窗口移位计数器Snd.Wind.shift和Rcv.Wind.shift进行扩充，分别应用于传入和传出窗口字段。
o If a TCP receives a <SYN> segment containing a Window Scale option, it SHOULD send its own Window Scale option in the <SYN,ACK> segment.
o 如果TCP接收到包含窗口缩放选项的<SYN>段，则应在<SYN，ACK>段中发送自己的窗口缩放选项。
o The Window Scale option MUST be sent with shift.cnt = R, where R is the value that the TCP would like to use for its receive window.
o 窗口缩放选项必须与shift.cnt=R一起发送，其中R是TCP希望用于其接收窗口的值。
o Upon receiving a <SYN> segment with a Window Scale option containing shift.cnt = S, a TCP MUST set Snd.Wind.Shift to S and MUST set Rcv.Wind.Shift to R; otherwise, it MUST set both Snd.Wind.Shift and Rcv.Wind.Shift to zero.
o 在接收到窗口缩放选项包含shift.cnt=S的<SYN>段时，TCP必须将Snd.Wind.shift设置为S，并且必须将Rcv.Wind.shift设置为R；否则，它必须将Snd.Wind.Shift和Rcv.Wind.Shift都设置为零。
o The window field (SEG.WND) in the header of every incoming segment, with the exception of <SYN> segments, MUST be left-shifted by Snd.Wind.Shift bits before updating SND.WND:
o 在更新Snd.WND之前，除<SYN>段外，每个传入段的标头中的窗口字段（SEG.WND）必须左移Snd.Wind.Shift位：
SND.WND = SEG.WND << Snd.Wind.Shift
SND.WND = SEG.WND << Snd.Wind.Shift
(assuming the other conditions of [RFC0793] are met, and using the "C" notation "<<" for left-shift).
（假设满足[RFC0793]的其他条件，并使用“C”符号“<<”表示左移）。
o The window field (SEG.WND) of every outgoing segment, with the exception of <SYN> segments, MUST be right-shifted by Rcv.Wind.Shift bits:
o 除<SYN>段外，每个输出段的窗口字段（SEG.WND）必须通过Rcv.Wind.Shift位右移：
SEG.WND = RCV.WND >> Rcv.Wind.Shift
SEG.WND = RCV.WND >> Rcv.Wind.Shift
TCP determines if a data segment is "old" or "new" by testing whether its sequence number is within 2^31 bytes of the left edge of the window, and if it is not, discarding the data as "old". To insure that new data is never mistakenly considered old and vice versa, the left edge of the sender's window has to be at most 2^31 away from the right edge of the receiver's window. The same is true of the sender's right edge and receiver's left edge. Since the right and left edges of either the sender's or receiver's window differ by the window size, and since the sender and receiver windows can be out of phase by at most the window size, the above constraints imply that two times the maximum window size must be less than 2^31, or
TCP通过测试数据段的序列号是否在窗口左边缘的2^31字节内来确定数据段是“旧”还是“新”，如果不在，则将数据段丢弃为“旧”。为确保新数据不会被错误地视为旧数据，反之亦然，发送方窗口的左边缘与接收方窗口的右边缘之间的距离不得超过2^31。发送方的右边缘和接收方的左边缘也是如此。由于发送方或接收方窗口的左右边缘因窗口大小不同而不同，且发送方和接收方窗口最多可因窗口大小而不同步，因此上述约束意味着最大窗口大小的两倍必须小于2^31，或
max window < 2^30
最大窗口<2^30
Since the max window is 2^S (where S is the scaling shift count) times at most 2^16 - 1 (the maximum unscaled window), the maximum window is guaranteed to be < 2^30 if S <= 14. Thus, the shift count MUST be limited to 14 (which allows windows of 2^30 = 1 GiB). If a Window Scale option is received with a shift.cnt value larger than 14, the TCP SHOULD log the error but MUST use 14 instead of the specified value. This is safe as a sender can always choose to only partially use any signaled receive window. If the receiver is scaling by a factor larger than 14 and the sender is only scaling by 14, then the receive window used by the sender will appear smaller than it is in reality.
由于最大窗口为2^S（其中S为缩放移位计数），最多为2^16-1（最大未缩放窗口），因此如果S<=14，则最大窗口保证小于2^30。因此，移位计数必须限制为14（这允许窗口为2^30=1 GiB）。如果接收到的窗口缩放选项的shift.cnt值大于14，TCP应记录错误，但必须使用14而不是指定的值。这是安全的，因为发送方始终可以选择仅部分使用任何信号接收窗口。如果接收器按大于14的因子缩放，而发送方仅按14缩放，则发送方使用的接收窗口将看起来比实际更小。
The scale factor applies only to the window field as transmitted in the TCP header; each TCP using extended windows will maintain the window values locally as 32-bit numbers. For example, the "congestion window" computed by slow start and congestion avoidance (see [RFC5681]) is not affected by the scale factor, so window scaling will not introduce quantization into the congestion window.
比例因子仅适用于TCP报头中传输的窗口字段；每个使用扩展窗口的TCP将在本地将窗口值保持为32位数字。例如，通过慢速启动和拥塞避免（参见[RFC5681]）计算的“拥塞窗口”不受比例因子的影响，因此窗口缩放不会将量化引入拥塞窗口。
When a non-zero scale factor is in use, there are instances when a retracted window can be offered -- see Appendix F for a detailed example. The end of the window will be on a boundary based on the granularity of the scale factor being used. If the sequence number is then updated by a number of bytes smaller than that granularity, the TCP will have to either advertise a new window that is beyond what it previously advertised (and perhaps beyond the buffer) or will have to advertise a smaller window, which will cause the TCP window to shrink. Implementations MUST ensure that they handle a shrinking window, as specified in Section 4.2.2.16 of [RFC1122].
当使用非零比例因子时，有时可以提供缩回窗口——有关详细示例，请参见附录F。窗口的末端将位于基于所用比例因子粒度的边界上。如果序列号随后被更新为小于该粒度的字节数，TCP将不得不通告一个超出其先前通告的新窗口（可能超出缓冲区），或者必须通告一个较小的窗口，这将导致TCP窗口收缩。按照[RFC1122]第4.2.2.16节的规定，实施必须确保能够处理收缩窗口。
For the receiver, this implies that:
对于接收方而言，这意味着：
1) The receiver MUST honor, as in window, any segment that would have been in window for any <ACK> sent by the receiver.
1) 接收方必须像在窗口中一样，对接收方发送的任何<ACK>，遵守窗口中的任何段。
2) When window scaling is in effect, the receiver SHOULD track the actual maximum window sequence number (which is likely to be greater than the window announced by the most recent <ACK>, if more than one segment has arrived since the application consumed any data in the receive buffer).
2) 当窗口缩放生效时，接收器应跟踪实际的最大窗口序列号（如果自应用程序使用接收缓冲区中的任何数据以来已到达多个段，则该序列号可能大于最近的<ACK>所宣布的窗口）。
On the sender side:
在发送方：
3) The initial transmission MUST be within the window announced by the most recent <ACK>.
3) 初始传输必须在最近的<ACK>所宣布的窗口内。
4) On first retransmission, or if the sequence number is out of window by less than 2^Rcv.Wind.Shift, then do normal retransmission(s) without regard to the receiver window as long as the original segment was in window when it was sent.
4) 在第一次重传时，或者如果序列号超出窗口小于2^Rcv.Wind.Shift，则只要发送时原始段在窗口中，则不考虑接收器窗口，执行正常重传。
5) Subsequent retransmissions MAY only be sent if they are within the window announced by the most recent <ACK>.
5) 只有在最近的<ACK>所宣布的窗口内，才能发送后续重传。
The Timestamps option is introduced to address some of the issues mentioned in Sections 1.1 and 1.2. The Timestamps option is specified in a symmetrical manner, so that Timestamp Value (TSval) timestamps are carried in both data and <ACK> segments and are echoed in Timestamp Echo Reply (TSecr) fields carried in returning <ACK> or data segments. Originally used primarily for timestamping individual segments, the properties of the Timestamps option allow for taking time measurements (Section 4) as well as additional uses (Section 5).
引入时间戳选项是为了解决第1.1节和第1.2节中提到的一些问题。时间戳选项以对称方式指定，以便时间戳值（TSval）时间戳在数据段和<ACK>段中都携带，并在返回<ACK>或数据段中携带的时间戳回送回复（TSecr）字段中回送。时间戳选项最初主要用于为单个段添加时间戳，其属性允许进行时间测量（第4节）以及其他用途（第5节）。
It is necessary to remember that there is a distinction between the Timestamps option conveying timestamp information and the use of that information. In particular, the RTTM mechanism must be viewed independently from updating the Retransmission Timeout (RTO) (see Section 4.2). In this case, the sample granularity also needs to be taken into account. Other mechanisms, such as PAWS or Eifel, are not built upon the timestamp information itself but are based on the intrinsic property of monotonically non-decreasing values.
必须记住，传递时间戳信息的时间戳选项与该信息的使用之间存在区别。特别是，必须独立于更新重传超时（RTO）来查看RTTM机制（见第4.2节）。在这种情况下，还需要考虑样本粒度。其他机制，如PAWS或Eifel，不是基于时间戳信息本身，而是基于单调非递减值的固有特性。
The Timestamps option is important when large receive windows are used to allow the use of the PAWS mechanism (see Section 5).
当使用较大的接收窗口来允许使用PAWS机制时，时间戳选项非常重要（参见第5节）。
Furthermore, the option may be useful for all TCPs, since it simplifies the sender and allows the use of additional optimizations such as Eifel ([RFC3522], [RFC4015]) and others ([RFC6817], [Kuzmanovic03], [Kuehlewind10]).
此外，该选项可能对所有TCP都有用，因为它简化了发送方并允许使用额外的优化，例如Eifel（[RFC3522]、[RFC4015]）和其他（[RFC6817]、[Kuzmanovic03]、[Kuehlewind10]）。
TCP is a symmetric protocol, allowing data to be sent at any time in either direction, and therefore timestamp echoing may occur in either direction. For simplicity and symmetry, we specify that timestamps always be sent and echoed in both directions. For efficiency, we combine the timestamp and timestamp reply fields into a single TCP Timestamps option.
TCP是一种对称协议，允许数据在任意时间以任意方向发送，因此时间戳回送可能在任意方向发生。为了简单和对称，我们指定时间戳总是在两个方向上发送和回响。为了提高效率，我们将时间戳和时间戳回复字段合并到一个TCP时间戳选项中。
TCP Timestamps option (TSopt):
TCP时间戳选项（TSopt）：
Kind: 8
种类：8
Length: 10 bytes
长度：10字节
+-------+-------+---------------------+---------------------+
|Kind=8 | 10 | TS Value (TSval) |TS Echo Reply (TSecr)|
+-------+-------+---------------------+---------------------+
1 1 4 4
+-------+-------+---------------------+---------------------+
|Kind=8 | 10 | TS Value (TSval) |TS Echo Reply (TSecr)|
+-------+-------+---------------------+---------------------+
1 1 4 4
The Timestamps option carries two four-byte timestamp fields. The TSval field contains the current value of the timestamp clock of the TCP sending the option.
时间戳选项包含两个四字节的时间戳字段。TSval字段包含发送选项的TCP的时间戳时钟的当前值。
The TSecr field is valid if the ACK bit is set in the TCP header. If the ACK bit is not set in the outgoing TCP header, the sender of that segment SHOULD set the TSecr field to zero. When the ACK bit is set in an outgoing segment, the sender MUST echo a recently received TSval sent by the remote TCP in the TSval field of a Timestamps option. The exact rules on which TSval MUST be echoed are given in Section 4.3. When the ACK bit is not set, the receiver MUST ignore the value of the TSecr field.
如果在TCP报头中设置了ACK位，则TSecr字段有效。如果传出TCP报头中未设置ACK位，则该段的发送方应将TSecr字段设置为零。在传出段中设置ACK位时，发送方必须在时间戳选项的TSval字段中回显远程TCP发送的最近接收到的TSval。第4.3节给出了必须响应TSval的确切规则。当未设置ACK位时，接收器必须忽略TSecr字段的值。
A TCP MAY send the TSopt in an initial <SYN> segment (i.e., segment containing a SYN bit and no ACK bit), and MAY send a TSopt in <SYN,ACK> only if it received a TSopt in the initial <SYN> segment for the connection.
TCP可在初始<SYN>段（即，包含SYN位且无ACK位的段）中发送TSopt，并且仅当其在连接的初始<SYN>段中接收到TSopt时，才可在<SYN，ACK>中发送TSopt。
Once TSopt has been successfully negotiated, that is both <SYN> and
<SYN,ACK> contain TSopt, the TSopt MUST be sent in every non-<RST>
segment for the duration of the connection, and SHOULD be sent in an
<RST> segment (see Section 5.2 for details). The TCP SHOULD remember
this state by setting a flag, referred to as Snd.TS.OK, to one. If a
Once TSopt has been successfully negotiated, that is both <SYN> and
<SYN,ACK> contain TSopt, the TSopt MUST be sent in every non-<RST>
segment for the duration of the connection, and SHOULD be sent in an
<RST> segment (see Section 5.2 for details). The TCP SHOULD remember
this state by setting a flag, referred to as Snd.TS.OK, to one. If a
non-<RST> segment is received without a TSopt, a TCP SHOULD silently drop the segment. A TCP MUST NOT abort a TCP connection because any segment lacks an expected TSopt.
如果在没有TSopt的情况下接收到非-<RST>段，TCP应自动删除该段。TCP不能中止TCP连接，因为任何段都缺少预期的TSopt。
Implementations are strongly encouraged to follow the above rules for handling a missing Timestamps option and the order of precedence mentioned in Section 5.3 when deciding on the acceptance of a segment.
强烈鼓励实施人员在决定是否接受某个段时，遵循上述规则处理丢失的时间戳选项和第5.3节中提到的优先顺序。
If a receiver chooses to accept a segment without an expected Timestamps option, it must be clear that undetectable data corruption may occur.
如果接收器选择接受没有预期时间戳选项的段，则必须清楚可能发生无法检测到的数据损坏。
Such a TCP receiver may experience undetectable wrapped-sequence effects, such as data (payload) corruption or session stalls. In order to maintain the integrity of the payload data, in particular on high-speed networks, it is paramount to follow the described processing rules.
这样的TCP接收器可能会经历不可检测的包装序列效应，例如数据（有效负载）损坏或会话暂停。为了保持有效载荷数据的完整性，特别是在高速网络上，遵循所述处理规则至关重要。
However, it has been mentioned that under some circumstances, the above guidelines are too strict, and some paths sporadically suppress the Timestamps option, while maintaining payload integrity. A path behaving in this manner should be deemed unacceptable, but it has been noted that some implementations relax the acceptance rules as a workaround and allow TCP to run across such paths [RE-1323BIS].
然而，有人提到，在某些情况下，上述准则过于严格，一些路径偶尔会抑制时间戳选项，同时保持有效负载的完整性。以这种方式运行的路径应被视为不可接受的，但已经注意到，一些实现将接受规则作为一种解决办法，并允许TCP在此类路径上运行[RE-1323BIS]。
If a TSopt is received on a connection where TSopt was not negotiated in the initial three-way handshake, the TSopt MUST be ignored and the packet processed normally.
如果在初始三方握手中未协商TSopt的连接上接收到TSopt，则必须忽略TSopt并正常处理数据包。
In the case of crossing <SYN> segments where one <SYN> contains a TSopt and the other doesn't, both sides MAY send a TSopt in the <SYN,ACK> segment.
在交叉<SYN>段的情况下，其中一个<SYN>包含TSopt，而另一个不包含TSopt，双方可以在<SYN，ACK>段中发送TSopt。
TSopt is required for the two mechanisms described in Sections 4 and 5. There are also other mechanisms that rely on the presence of the TSopt, e.g., [RFC3522]. If a TCP stopped sending TSopt at any time during an established session, it interferes with these mechanisms. This update to [RFC1323] describes explicitly the previous assumption (see Section 5.2) that each TCP segment must have a TSopt, once negotiated.
第4节和第5节中描述的两种机制需要TSopt。还有其他依赖于TSopt存在的机制，例如[RFC3522]。如果TCP在已建立会话期间的任何时间停止发送TSopt，则会干扰这些机制。[RFC1323]的更新明确描述了之前的假设（见第5.2节），即每个TCP段在协商后必须有一个TSopt。
One use of the Timestamps option is to measure the round-trip time (RTT) of virtually every packet acknowledged. The RTTM mechanism requires a Timestamps option in every measured segment, with a TSval that is obtained from a (virtual) "timestamp clock". Values of this clock MUST be at least approximately proportional to real time, in order to measure actual RTT.
时间戳选项的一个用途是测量几乎每个已确认数据包的往返时间（RTT）。RTTM机制要求在每个测量段中都有一个时间戳选项，TSval从（虚拟）“时间戳时钟”中获得。为了测量实际RTT，该时钟的值必须至少与实时近似成比例。
TCP measures the RTT, primarily for the purpose of arriving at a reasonable value for the RTO timer interval. Accurate and current RTT estimates are necessary to adapt to changing traffic conditions, while a conservative estimate of the RTO interval is necessary to minimize spurious RTOs.
TCP测量RTT，主要是为了获得RTO定时器间隔的合理值。为了适应不断变化的交通状况，需要准确且当前的RTT估计，而保守的RTO间隔估计对于最小化虚假RTO是必要的。
These TSval values are echoed in TSecr values in the reverse direction. The difference between a received TSecr value and the current timestamp clock value provides an RTT measurement.
这些TSval值在TSecr值中反向回显。接收到的TSecr值和当前时间戳时钟值之间的差值提供RTT测量。
When timestamps are used, every segment that is received will contain a TSecr value. However, these values cannot all be used to update the measured RTT. The following example illustrates why. It shows a one-way data flow with segments arriving in sequence without loss. Here A, B, C... represent data blocks occupying successive blocks of sequence numbers, and ACK(A),... represent the corresponding cumulative acknowledgments. The two timestamp fields of the Timestamps option are shown symbolically as <TSval=x,TSecr=y>. Each TSecr field contains the value most recently received in a TSval field.
使用时间戳时，接收到的每个段都将包含一个TSecr值。但是，这些值不能全部用于更新测量的RTT。下面的例子说明了原因。它显示了一个单向数据流，数据段按顺序到达，没有丢失。这里是A，B，C。。。表示占用连续序列号块的数据块，以及ACK（A），。。。表示相应的累积确认。时间戳选项的两个时间戳字段以符号形式显示为<TSval=x，TSecr=y>。每个TSecr字段包含最近在TSval字段中接收到的值。
TCP A TCP B
TCP A TCP B
<A,TSval=1,TSecr=120> ----->
<A,TSval=1,TSecr=120> ----->
<---- <ACK(A),TSval=127,TSecr=1>
<---- <ACK(A),TSval=127,TSecr=1>
<B,TSval=5,TSecr=127> ----->
<B,TSval=5,TSecr=127> ----->
<---- <ACK(B),TSval=131,TSecr=5>
<---- <ACK(B),TSval=131,TSecr=5>
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
<C,TSval=65,TSecr=131> ---->
<C,TSval=65,TSecr=131> ---->
<---- <ACK(C),TSval=191,TSecr=65>
<---- <ACK(C),TSval=191,TSecr=65>
(etc.)
（等等）
The dotted line marks a pause (60 time units long) in which A had nothing to send. Note that this pause inflates the RTT, which B could infer from receiving TSecr=131 in data segment C. Thus, in one-way data flows, RTTM in the reverse direction measures a value that is inflated by gaps in sending data. However, the following rule prevents a resulting inflation of the measured RTT:
虚线表示暂停（60个时间单位长），其中a没有任何要发送的内容。请注意，此暂停会使RTT膨胀，B可以从数据段C中接收到的TSecr=131推断出RTT。因此，在单向数据流中，反向的RTTM测量因发送数据的间隙而膨胀的值。但是，以下规则可防止测量RTT的膨胀：
RTTM Rule: A TSecr value received in a segment MAY be used to update the averaged RTT measurement only if the segment advances the left edge of the send window, i.e., SND.UNA is increased.
RTTM规则：只有当某个段前进到发送窗口的左边缘，即SND.UNA增加时，在该段中接收到的TSecr值才可用于更新平均RTT测量值。
Since TCP B is not sending data, the data segment C does not acknowledge any new data when it arrives at B. Thus, the inflated RTTM measurement is not used to update B's RTTM measurement.
由于TCP B不发送数据，数据段C在到达B时不确认任何新数据。因此，膨胀的RTTM测量值不用于更新B的RTTM测量值。
When [RFC1323] was originally written, it was perceived that taking RTT measurements for each segment, and also during retransmissions, would contribute to reduce spurious RTOs, while maintaining the timeliness of necessary RTOs. At the time, RTO was also the only mechanism to make use of the measured RTT. It has been shown that taking more RTT samples has only a very limited effect to optimize RTOs [Allman99].
最初编写[RFC1323]时，人们认为对每个段以及在重传期间进行RTT测量将有助于减少虚假RTO，同时保持必要RTO的及时性。当时，RTO也是利用测量RTT的唯一机制。已经证明，获取更多RTT样本对优化RTO的效果非常有限[Allman99]。
Implementers should note that with timestamps, multiple RTTMs can be taken per RTT. The [RFC6298] RTT estimator has weighting factors, alpha and beta, based on an implicit assumption that at most one RTTM will be sampled per RTT. When multiple RTTMs per RTT are available
实现者应该注意，对于时间戳，每个RTT可以使用多个RTTM。[RFC6298]RTT估计器具有加权因子α和β，基于每个RTT最多采样一个RTTM的隐式假设。当每个RTT有多个RTTMs可用时
to update the RTT estimator, an implementation SHOULD try to adhere to the spirit of the history specified in [RFC6298]. An implementation suggestion is detailed in Appendix G.
要更新RTT估计器，实现应尽量遵循[RFC6298]中规定的历史精神。实施建议详见附录G。
[Ludwig00] and [Floyd05] have highlighted the problem that an unmodified RTO calculation, which is updated with per-packet RTT samples, will truncate the path history too soon. This can lead to an increase in spurious retransmissions, when the path properties vary in the order of a few RTTs, but a high number of RTT samples are taken on a much shorter timescale.
[Ludwig00]和[Floyd05]强调了一个问题，即未经修改的RTO计算（使用每包RTT样本更新）将过早截断路径历史。当路径属性以几个RTT的顺序变化时，这可能会导致虚假重传的增加，但在更短的时间尺度上采集大量RTT样本。
If more than one Timestamps option is received before a reply segment is sent, the TCP must choose only one of the TSvals to echo, ignoring the others. To minimize the state kept in the receiver (i.e., the number of unprocessed TSvals), the receiver should be required to retain at most one timestamp in the connection control block.
如果在发送应答段之前接收到多个时间戳选项，TCP必须只选择一个TSVAL进行回显，而忽略其他TSVAL。为了最小化接收器中保持的状态（即，未处理TSVAL的数量），应要求接收器在连接控制块中最多保留一个时间戳。
There are three situations to consider:
有三种情况需要考虑：
(A) Delayed ACKs.
（A） 延迟确认。
Many TCPs acknowledge only every second segment out of a group of segments arriving within a short time interval; this policy is known generally as "delayed ACKs". The data-sender TCP must measure the effective RTT, including the additional time due to delayed ACKs, or else it will retransmit unnecessarily. Thus, when delayed ACKs are in use, the receiver SHOULD reply with the TSval field from the earliest unacknowledged segment.
许多TCP只确认在短时间间隔内到达的一组段中的每一秒段；此策略通常称为“延迟确认”。数据发送方TCP必须测量有效RTT，包括由于延迟ACK而增加的时间，否则它将不必要地重新传输。因此，当使用延迟确认时，接收器应使用来自最早未确认段的TSval字段进行回复。
(B) A hole in the sequence space (segment(s) has been lost).
（B） 序列空间中的孔（段丢失）。
The sender will continue sending until the window is filled, and the receiver may be generating <ACK>s as these out-of-order segments arrive (e.g., to aid "Fast Retransmit").
发送方将继续发送，直到窗口被填满，当这些无序段到达时，接收方可能正在生成<ACK>s（例如，帮助“快速重传”）。
The lost segment is probably a sign of congestion, and in that situation the sender should be conservative about retransmission. Furthermore, it is better to overestimate than underestimate the RTT. An <ACK> for an out-of-order segment SHOULD, therefore, contain the timestamp from the most recent segment that advanced RCV.NXT.
丢失的数据段可能是拥塞的迹象，在这种情况下，发送方应该对重传保持谨慎。此外，高估RTT比低估RTT更好。因此，无序段的<ACK>应该包含来自最新的提升RCV.NXT的段的时间戳。
The same situation occurs if segments are reordered by the network.
如果网络对段重新排序，也会出现相同的情况。
(C) A filled hole in the sequence space.
（C） 序列空间中的填充孔。
The segment that fills the hole and advances the window represents the most recent measurement of the network characteristics. An RTT computed from an earlier segment would probably include the sender's retransmit timeout, badly biasing the sender's average RTT estimate. Thus, the timestamp from the latest segment (which filled the hole) MUST be echoed.
填充孔并推进窗口的段表示网络特性的最新测量。从先前的段计算的RTT可能包括发送方的重新传输超时，严重偏离发送方的平均RTT估计。因此，必须回显最新段（填充孔）的时间戳。
An algorithm that covers all three cases is described in the following rules for Timestamps option processing on a synchronized connection:
以下同步连接上时间戳选项处理规则中描述了涵盖所有三种情况的算法：
(1) The connection state is augmented with two 32-bit slots:
(1) 连接状态增加了两个32位插槽：
TS.Recent holds a timestamp to be echoed in TSecr whenever a segment is sent, and Last.ACK.sent holds the ACK field from the last segment sent. Last.ACK.sent will equal RCV.NXT except when <ACK>s have been delayed.
TS.NEXT保存一个时间戳，每当发送一个段时，该时间戳将在TSecr中回显，Last.ACK.sent保存最后发送的段的ACK字段。Last.ACK.sent将等于RCV.NXT，除非<ACK>s已延迟。
(2) If:
(2) 如果：
SEG.TSval >= TS.Recent and SEG.SEQ <= Last.ACK.sent
SEG.TSval >= TS.Recent and SEG.SEQ <= Last.ACK.sent
then SEG.TSval is copied to TS.Recent; otherwise, it is ignored.
然后将SEG.TSval复制到TS.Recent；否则，它将被忽略。
(3) When a TSopt is sent, its TSecr field is set to the current TS.Recent value.
(3) 发送TSopt时，其TSecr字段设置为当前TS.NEXT值。
The following examples illustrate these rules. Here A, B, C... represent data segments occupying successive blocks of sequence numbers, and ACK(A),... represent the corresponding acknowledgment segments. Note that ACK(A) has the same sequence number as B. We show only one direction of timestamp echoing, for clarity.
下面的例子说明了这些规则。这里是A，B，C。。。表示占用连续序列号块的数据段，以及ACK（A），。。。表示相应的确认段。请注意，ACK（A）与B具有相同的序列号。为了清晰起见，我们只显示了时间戳回声的一个方向。
o Segments arrive in sequence, and some of the <ACK>s are delayed.
o 分段按顺序到达，一些<ACK>s延迟。
By case (A), the timestamp from the oldest unacknowledged segment is echoed.
在案例（A）中，来自最早的未确认段的时间戳被回显。
TS.Recent
<A, TSval=1> ------------------->
1
<B, TSval=2> ------------------->
1
<C, TSval=3> ------------------->
1
<---- <ACK(C), TSecr=1>
(etc.)
TS.Recent
<A, TSval=1> ------------------->
1
<B, TSval=2> ------------------->
1
<C, TSval=3> ------------------->
1
<---- <ACK(C), TSecr=1>
(etc.)
o Segments arrive out of order, and every segment is acknowledged.
o 分段无序到达，每个分段都被确认。
By case (B), the timestamp from the last segment that advanced the left window edge is echoed until the missing segment arrives; it is echoed according to case (C). The same sequence would occur if segments B and D were lost and retransmitted.
在情况（B）中，来自推进左窗口边缘的最后一段的时间戳被回响，直到丢失的段到达；根据情况（C）进行回声。如果段B和D丢失并重新传输，则会出现相同的序列。
TS.Recent
<A, TSval=1> ------------------->
1
<---- <ACK(A), TSecr=1>
1
<C, TSval=3> ------------------->
1
<---- <ACK(A), TSecr=1>
1
<B, TSval=2> ------------------->
2
<---- <ACK(C), TSecr=2>
2
<E, TSval=5> ------------------->
2
<---- <ACK(C), TSecr=2>
2
<D, TSval=4> ------------------->
4
<---- <ACK(E), TSecr=4>
(etc.)
TS.Recent
<A, TSval=1> ------------------->
1
<---- <ACK(A), TSecr=1>
1
<C, TSval=3> ------------------->
1
<---- <ACK(A), TSecr=1>
1
<B, TSval=2> ------------------->
2
<---- <ACK(C), TSecr=2>
2
<E, TSval=5> ------------------->
2
<---- <ACK(C), TSecr=2>
2
<D, TSval=4> ------------------->
4
<---- <ACK(E), TSecr=4>
(etc.)
Another use for the Timestamps option is the PAWS mechanism. Section 5.2 describes a simple mechanism to reject old duplicate segments that might corrupt an open TCP connection. PAWS operates within a single TCP connection, using state that is saved in the connection control block. Section 5.8 and Appendix H discuss the implications of the PAWS mechanism for avoiding old duplicates from previous incarnations of the same connection.
时间戳选项的另一个用途是PAWS机制。第5.2节描述了一种简单的机制，用于拒绝可能损坏开放TCP连接的旧重复段。PAWS使用保存在连接控制块中的状态在单个TCP连接中运行。第5.8节和附录H讨论了PAWS机制的含义，以避免相同连接的前代版本中的旧副本。
PAWS uses the TCP Timestamps option described earlier and assumes that every received TCP segment (including data and <ACK> segments) contains a timestamp SEG.TSval whose values are monotonically non-decreasing in time. The basic idea is that a segment can be discarded as an old duplicate if it is received with a timestamp SEG.TSval less than some timestamps recently received on this connection.
PAWS使用前面描述的TCP时间戳选项，并假设每个接收到的TCP段（包括数据和<ACK>段）都包含一个时间戳SEG.TSval，其值在时间上单调不变。其基本思想是，如果接收到的段的时间戳SEG.TSval小于最近在此连接上接收到的一些时间戳，则可以将其作为旧副本丢弃。
In the PAWS mechanism, the "timestamps" are 32-bit unsigned integers in a modular 32-bit space. Thus, "less than" is defined the same way it is for TCP sequence numbers, and the same implementation techniques apply. If s and t are timestamp values,
在PAWS机制中，“时间戳”是模化32位空间中的32位无符号整数。因此，“小于”的定义与TCP序列号的定义相同，并且应用相同的实现技术。如果s和t是时间戳值，
s < t if 0 < (t - s) < 2^31,
如果0<（t-s）<2^31，
computed in unsigned 32-bit arithmetic.
以无符号32位算术计算。
The choice of incoming timestamps to be saved for this comparison MUST guarantee a value that is monotonically non-decreasing. For example, an implementation might save the timestamp from the segment that last advanced the left edge of the receive window, i.e., the most recent in-sequence segment. For simplicity, the value TS.Recent introduced in Section 4.3 is used instead, as using a common value for both PAWS and RTTM simplifies the implementation. As Section 4.3 explained, TS.Recent differs from the timestamp from the last in-sequence segment only in the case of delayed <ACK>s, and therefore by less than one window. Either choice will, therefore, protect against sequence number wrap-around.
为进行比较而保存的传入时间戳的选择必须保证值是单调非递减的。例如，一个实现可能保存来自最后一个到达接收窗口左边缘的段的时间戳，即最近的序列段。为简单起见，使用第4.3节中引入的值TS，因为使用PAWS和RTTM的公共值简化了实现。如第4.3节所述，TS.Recent与序列中最后一个段的时间戳不同，仅在延迟<ACK>s的情况下，因此相差不到一个窗口。因此，任何一种选择都可以防止序列号缠绕。
PAWS submits all incoming segments to the same test, and therefore
protects against duplicate <ACK> segments as well as data segments.
(An alternative non-symmetric algorithm would protect against old
duplicate <ACK>s: the sender of data would reject incoming <ACK>
segments whose TSecr values were less than the TSecr saved from the
PAWS submits all incoming segments to the same test, and therefore
protects against duplicate <ACK> segments as well as data segments.
(An alternative non-symmetric algorithm would protect against old
duplicate <ACK>s: the sender of data would reject incoming <ACK>
segments whose TSecr values were less than the TSecr saved from the
last segment whose ACK field advanced the left edge of the send window. This algorithm was deemed to lack economy of mechanism and symmetry.)
其ACK字段位于发送窗口左边缘的最后一段。该算法被认为缺乏机制和对称性的经济性。）
TSval timestamps sent on <SYN> and <SYN,ACK> segments are used to initialize PAWS. PAWS protects against old duplicate non-<SYN> segments and duplicate <SYN> segments received while there is a synchronized connection. Duplicate <SYN> and <SYN,ACK> segments received when there is no connection will be discarded by the normal 3-way handshake and sequence number checks of TCP.
在<SYN>和<SYN，ACK>段上发送的TSval时间戳用于初始化PAW。PAWS可防止旧的重复非<SYN>段和在同步连接时接收的重复<SYN>段。在没有连接的情况下接收到的重复的<SYN>和<SYN，ACK>段将被TCP的正常三向握手和序列号检查丢弃。
[RFC1323] recommended that <RST> segments NOT carry timestamps and that they be acceptable regardless of their timestamp. At that time, the thinking was that old duplicate <RST> segments should be exceedingly unlikely, and their cleanup function should take precedence over timestamps. More recently, discussions about various blind attacks on TCP connections have raised the suggestion that if the Timestamps option is present, SEG.TSecr could be used to provide stricter acceptance tests for <RST> segments.
[RFC1323]建议<RST>段不带有时间戳，并且无论其时间戳如何，都可以接受。当时的想法是，旧的重复<RST>段不太可能出现，它们的清理功能应该优先于时间戳。最近，关于TCP连接的各种盲攻击的讨论提出了这样的建议，即如果存在时间戳选项，SEG.TSecr可用于为<RST>段提供更严格的验收测试。
While still under discussion, to enable research into this area it is now RECOMMENDED that when generating an <RST>, if the segment causing the <RST> to be generated contains a Timestamps option, the <RST> should also contain a Timestamps option. In the <RST> segment, SEG.TSecr SHOULD be set to SEG.TSval from the incoming segment and SEG.TSval SHOULD be set to zero. If an <RST> is being generated because of a user abort, and Snd.TS.OK is set, then a Timestamps option SHOULD be included in the <RST>. When an <RST> segment is received, it MUST NOT be subjected to the PAWS check by verifying an acceptable value in SEG.TSval, and information from the Timestamps option MUST NOT be used to update connection state information. SEG.TSecr MAY be used to provide stricter <RST> acceptance checks.
尽管仍在讨论中，为了能够对该领域进行研究，现在建议在生成<RST>时，如果导致生成<RST>的段包含时间戳选项，<RST>也应包含时间戳选项。在<RST>段中，应从输入段将SEG.TSecr设置为SEG.TSval，并将SEG.TSval设置为零。如果由于用户中止而生成<RST>，并且设置了Snd.TS.OK，则<RST>中应包含时间戳选项。当收到<RST>段时，不得通过验证SEG.TSval中的可接受值对其进行PAWS检查，并且不得使用来自时间戳选项的信息来更新连接状态信息。SEG.TSecr可用于提供更严格的验收检查。
If the PAWS algorithm is used, the following processing MUST be performed on all incoming segments for a synchronized connection. Also, PAWS processing MUST take precedence over the regular TCP acceptability check (Section 3.3 in [RFC0793]), which is performed after verification of the received Timestamps option:
如果使用PAWS算法，则必须对同步连接的所有传入段执行以下处理。此外，PAWS处理必须优先于常规TCP可接受性检查（RFC0793中的第3.3节），该检查在验证收到的时间戳选项后执行：
R1) If there is a Timestamps option in the arriving segment, SEG.TSval < TS.Recent, TS.Recent is valid (see later discussion), and if the RST bit is not set, then treat the arriving segment as not acceptable:
R1）如果到达段中有时间戳选项，SEG.TSval<TS.Recent，TS.Recent有效（见后面的讨论），并且如果未设置RST位，则将到达段视为不可接受：
Send an acknowledgment in reply as specified in Section 3.9 of [RFC0793], page 69, and drop the segment.
按照[RFC0793]第69页第3.9节的规定发送回复确认，并删除该段。
Note: it is necessary to send an <ACK> segment in order to retain TCP's mechanisms for detecting and recovering from half-open connections. For an example, see Figure 10 of [RFC0793].
注意：有必要发送<ACK>段，以便保留TCP用于检测和恢复半开放连接的机制。有关示例，请参见[RFC0793]的图10。
R2) If the segment is outside the window, reject it (normal TCP processing).
R2）如果段在窗口外，则拒绝它（正常TCP处理）。
R3) If an arriving segment satisfies SEG.TSval >= TS.Recent and SEG.SEQ <= Last.ACK.sent (see Section 4.3), then record its timestamp in TS.Recent.
R3）如果到达段满足SEG.TSval>=TS.Recent和SEG.SEQ<=Last.ACK.sent（参见第4.3节），则在TS.Recent中记录其时间戳。
R4) If an arriving segment is in sequence (i.e., at the left window edge), then accept it normally.
R4）如果一个到达段按顺序（即，在左窗口边缘），则正常接受它。
R5) Otherwise, treat the segment as a normal in-window, out-of-sequence TCP segment (e.g., queue it for later delivery to the user).
R5）否则，将该段视为正常的in-window、out-sequence TCP段（例如，将其排队等待稍后交付给用户）。
Steps R2, R4, and R5 are the normal TCP processing steps specified by [RFC0793].
步骤R2、R4和R5是[RFC0793]指定的正常TCP处理步骤。
It is important to note that the timestamp MUST be checked only when a segment first arrives at the receiver, regardless of whether it is in sequence or it must be queued for later delivery.
重要的是要注意，时间戳必须仅在段第一次到达接收器时检查，而不管它是按顺序还是必须排队等待以后的传递。
Consider the following example.
考虑下面的例子。
Suppose the segment sequence: A.1, B.1, C.1, ..., Z.1 has been sent, where the letter indicates the sequence number and the digit represents the timestamp. Suppose also that segment B.1 has been lost. The timestamp in TS.Recent is 1 (from A.1), so C.1, ..., Z.1 are considered acceptable and are queued. When B is retransmitted as segment B.2 (using the latest timestamp), it fills the hole and causes all the segments through Z to be acknowledged and passed to the user. The timestamps of the queued segments are *not* inspected again at this time, since they have already been accepted. When B.2 is accepted, TS.Recent is set to 2.
假设已发送段序列：A.1、B.1、C.1、…、Z.1，其中字母表示序列号，数字表示时间戳。还假设段B.1已丢失。TS.Recent中的时间戳是1（从A.1开始），因此C.1、…、Z.1被认为是可接受的，并排队。当B被重新传输为段B.2（使用最新的时间戳）时，它将填充孔，并使通过Z的所有段被确认并传递给用户。此时，队列段的时间戳*不会*再次检查，因为它们已被接受。当B.2被接受时，TS.Recent设置为2。
This rule allows reasonable performance under loss. A full window of data is in transit at all times, and after a loss a full window less one segment will show up out of sequence to be queued at the receiver (e.g., up to ~2^30 bytes of data); the Timestamps option must not result in discarding this data.
该规则允许在损失情况下合理履行。一个完整的数据窗口始终在传输中，丢失后，一个完整的窗口减去一个数据段将出现顺序错误，以便在接收器排队（例如，最多2^30字节的数据）；时间戳选项不得导致丢弃此数据。
In certain unlikely circumstances, the algorithm of rules R1-R5 could lead to discarding some segments unnecessarily, as shown in the following example:
在某些不太可能的情况下，规则R1-R5的算法可能导致不必要地丢弃某些段，如下例所示：
Suppose again that segments: A.1, B.1, C.1, ..., Z.1 have been sent in sequence and that segment B.1 has been lost. Furthermore, suppose delivery of some of C.1, ... Z.1 is delayed until *after* the retransmission B.2 arrives at the receiver. These delayed segments will be discarded unnecessarily when they do arrive, since their timestamps are now out of date.
再次假设：A.1、B.1、C.1、…、Z.1段已按顺序发送，而B.1段已丢失。此外，假设C.1中的一些。。。Z.1延迟到*重传B.2到达接收器之后。这些延迟段在到达时将被不必要地丢弃，因为它们的时间戳现在已过期。
This case is very unlikely to occur. If the retransmission was triggered by a timeout, some of the segments C.1, ... Z.1 must have been delayed longer than the RTO time. This is presumably an unlikely event, or there would be many spurious timeouts and retransmissions. If B's retransmission was triggered by the "Fast Retransmit" algorithm, i.e., by duplicate <ACK>s, then the queued segments that caused these <ACK>s must have been received already.
这种情况不太可能发生。如果重新传输是由超时触发的，则某些段C.1。。。Z.1的延迟时间必须超过RTO时间。这可能是一个不太可能发生的事件，或者会有许多虚假的超时和重新传输。如果B的重传是由“快速重传”算法触发的，即通过重复<ACK>s触发的，则导致这些<ACK>s的排队段必须已经收到。
Even if a segment were delayed past the RTO, the Fast Retransmit mechanism [Jacobson90c] will cause the delayed segments to be retransmitted at the same time as B.2, avoiding an extra RTT and, therefore, causing a very small performance penalty.
即使某个段延迟超过RTO，快速重传机制[Jacobson90c]也会导致延迟段与B.2同时重传，从而避免额外的RTT，从而导致非常小的性能损失。
We know of no case with a significant probability of occurrence in which timestamps will cause performance degradation by unnecessarily discarding segments.
据我们所知，没有出现过时间戳会因不必要地丢弃段而导致性能下降的情况。
It is important to understand that the PAWS algorithm does not require clock synchronization between the sender and receiver. The sender's timestamp clock is used as a source of monotonic non-decreasing values to stamp the segments. The receiver treats the timestamp value as simply a monotonically non-decreasing serial number, without any connection to time. From the receiver's viewpoint, the timestamp is acting as a logical extension of the high-order bits of the sequence number.
重要的是要理解PAWS算法不需要发送方和接收方之间的时钟同步。发送方的时间戳时钟被用作单调非递减值的来源，以标记段。接收器将时间戳值视为简单的单调非递减序列号，与时间没有任何连接。从接收机的角度来看，时间戳充当序列号的高阶位的逻辑扩展。
The receiver algorithm does place some requirements on the frequency of the timestamp clock.
接收器算法确实对时间戳时钟的频率提出了一些要求。
(a) The timestamp clock must not be "too slow".
(a) 时间戳时钟不得“太慢”。
It MUST tick at least once for each 2^31 bytes sent. In fact, in order to be useful to the sender for round-trip timing, the clock SHOULD tick at least once per window's worth of data, and even with the window extension defined in Section 2.2, 2^31 bytes must be at least two windows.
对于发送的每个2^31字节，它必须至少勾选一次。事实上，为了对发送方的往返计时有用，时钟应在每个窗口的数据量中至少滴答一次，即使使用第2.2节中定义的窗口扩展，2^31字节也必须至少有两个窗口。
To make this more quantitative, any clock faster than 1 tick/sec
will reject old duplicate segments for link speeds of ~8 Gbps.
A 1 ms timestamp clock will work at link speeds up to 8 Tbps
(8*10^12) bps!
To make this more quantitative, any clock faster than 1 tick/sec
will reject old duplicate segments for link speeds of ~8 Gbps.
A 1 ms timestamp clock will work at link speeds up to 8 Tbps
(8*10^12) bps!
(b) The timestamp clock must not be "too fast".
(b) 时间戳时钟不能“太快”。
The recycling time of the timestamp clock MUST be greater than MSL seconds. Since the clock (timestamp) is 32 bits and the worst-case MSL is 255 seconds, the maximum acceptable clock frequency is one tick every 59 ns.
时间戳时钟的循环时间必须大于MSL秒。由于时钟（时间戳）为32位，最坏情况下的MSL为255秒，因此可接受的最大时钟频率为每59纳秒一次。
However, it is desirable to establish a much longer recycle period, in order to handle outdated timestamps on idle connections (see Section 5.5), and to relax the MSL requirement for preventing sequence number wrap-around. With a 1 ms timestamp clock, the 32-bit timestamp will wrap its sign bit in 24.8 days. Thus, it will reject old duplicates on the same connection if MSL is 24.8 days or less. This appears to be a very safe figure; an MSL of 24.8 days or longer can probably be assumed in the Internet without requiring precise MSL enforcement.
然而，为了处理空闲连接上过时的时间戳（见第5.5节），并放宽MSL要求以防止序列号缠绕，需要建立更长的循环周期。使用1ms时间戳时钟，32位时间戳将在24.8天内完成符号位的封装。因此，如果MSL为24.8天或更少，它将拒绝相同连接上的旧副本。这似乎是一个非常安全的数字；在互联网上，可以假设MSL为24.8天或更长，而无需执行精确的MSL。
Based upon these considerations, we choose a timestamp clock frequency in the range 1 ms to 1 sec per tick. This range also matches the requirements of the RTTM mechanism, which does not need much more resolution than the granularity of the retransmit timer, e.g., tens or hundreds of milliseconds.
基于这些考虑，我们选择的时间戳时钟频率范围为1毫秒到1秒/滴答。该范围还符合RTTM机制的要求，RTTM机制不需要比重传计时器的粒度更多的分辨率，例如，几十或几百毫秒。
The PAWS mechanism also puts a strong monotonicity requirement on the sender's timestamp clock. The method of implementation of the timestamp clock to meet this requirement depends upon the system hardware and software.
PAWS机制还对发送方的时间戳时钟提出了很强的单调性要求。满足此要求的时间戳时钟的实现方法取决于系统硬件和软件。
o Some hosts have a hardware clock that is guaranteed to be monotonic between hardware resets.
o 某些主机的硬件时钟保证在硬件重置之间是单调的。
o A clock interrupt may be used to simply increment a binary integer by 1 periodically.
o 时钟中断可用于周期性地将二进制整数增加1。
o The timestamp clock may be derived from a system clock that is subject to being abruptly changed by adding a variable offset value. This offset is initialized to zero. When a new timestamp clock value is needed, the offset can be adjusted as necessary to make the new value equal to or larger than the previous value (which was saved for this purpose).
o 时间戳时钟可以从通过添加可变偏移值而受到突然改变的系统时钟导出。该偏移量初始化为零。当需要新的时间戳时钟值时，可以根据需要调整偏移量，使新值等于或大于先前的值（为此目的而保存）。
o A random offset may be added to the timestamp clock on a per-connection basis. See [RFC6528], Section 3, on randomizing the initial sequence number (ISN). The same function with a different secret key can be used to generate the per-connection timestamp offset.
o 可以基于每个连接向时间戳时钟添加随机偏移。参见[RFC6528]第3节，关于初始序列号（ISN）的随机化。具有不同密钥的相同函数可用于生成每个连接的时间戳偏移量。
If a connection remains idle long enough for the timestamp clock of the other TCP to wrap its sign bit, then the value saved in TS.Recent will become too old; as a result, the PAWS mechanism will cause all subsequent segments to be rejected, freezing the connection (until the timestamp clock wraps its sign bit again).
如果一个连接保持空闲足够长的时间，以便另一个TCP的时间戳时钟包装其符号位，则保存在TS.NEXT中的值将变得太旧；因此，PAWS机制将导致拒绝所有后续段，冻结连接（直到时间戳时钟再次包裹其符号位）。
With the chosen range of timestamp clock frequencies (1 sec to 1 ms), the time to wrap the sign bit will be between 24.8 days and 24800 days. A TCP connection that is idle for more than 24 days and then comes to life is exceedingly unusual. However, it is undesirable in principle to place any limitation on TCP connection lifetimes.
在选定的时间戳时钟频率范围内（1秒到1ms），包装符号位的时间将在24.8天到24800天之间。TCP连接闲置超过24天，然后恢复正常，这是极不寻常的。然而，原则上不希望对TCP连接寿命进行任何限制。
We therefore require that an implementation of PAWS include a mechanism to "invalidate" the TS.Recent value when a connection is idle for more than 24 days. (An alternative solution to the problem of outdated timestamps would be to send keep-alive segments at a very low rate, but still more often than the wrap-around time for timestamps, e.g., once a day. This would impose negligible overhead. However, the TCP specification has never included keep-alives, so the solution based upon invalidation was chosen.)
因此，我们要求PAWS的实现包括一种机制，当连接空闲超过24天时，使TS.Recent值“无效”。（过时时间戳问题的另一个解决方案是以非常低的速率发送保持活动的段，但仍然比时间戳的环绕时间更频繁，例如，每天一次。这将产生可忽略不计的开销。然而，TCP规范从未包括保持活动，因此基于失效的解决方案是（奥森）
Note that a TCP does not know the frequency, and therefore the wrap-around time, of the other TCP, so it must assume the worst. The validity of TS.Recent needs to be checked only if the basic PAWS timestamp check fails, i.e., only if SEG.TSval < TS.Recent. If TS.Recent is found to be invalid, then the segment is accepted, regardless of the failure of the timestamp check, and rule R3 updates TS.Recent with the TSval from the new segment.
请注意，一个TCP不知道另一个TCP的频率，因此也不知道环绕时间，因此它必须假设最坏的情况。仅当基本PAWS时间戳检查失败时，即仅当SEG.TSval<TS.Recent时，才需要检查TS.Recent的有效性。如果发现TS.NEXT无效，则不管时间戳检查是否失败，都会接受该段，并且规则R3使用新段中的TSval更新TS.NEXT。
To detect how long the connection has been idle, the TCP MAY update a clock or timestamp value associated with the connection whenever TS.Recent is updated, for example. The details will be implementation dependent.
为了检测连接空闲多长时间，例如，每当更新TS.Recent时，TCP可以更新与连接相关联的时钟或时间戳值。具体细节将取决于实施情况。
"Header prediction" [Jacobson90a] is a high-performance transport protocol implementation technique that is most important for high-speed links. This technique optimizes the code for the most common case, receiving a segment correctly and in order. Using header prediction, the receiver asks the question, "Is this segment the next in sequence?" This question can be answered in fewer machine instructions than the question, "Is this segment within the window?"
“报头预测”[Jacobson90a]是一种高性能传输协议实现技术，对高速链路最为重要。这种技术优化了最常见情况下的代码，正确有序地接收段。使用报头预测，接收者会问这样一个问题：“这个段是序列中的下一个吗？”这个问题可以用比“这个段在窗口内吗？”更少的机器指令来回答
Adding header prediction to our timestamp procedure leads to the following recommended sequence for processing an arriving TCP segment:
将报头预测添加到我们的时间戳过程会导致以下建议的处理到达TCP段的顺序：
H1) Check timestamp (same as step R1 above).
H1）检查时间戳（与上面的步骤R1相同）。
H2) Do header prediction: if the segment is next in sequence and if there are no special conditions requiring additional processing, accept the segment, record its timestamp, and skip H3.
H2）进行报头预测：如果该段是序列中的下一个，并且没有需要额外处理的特殊条件，则接受该段，记录其时间戳，并跳过H3。
H3) Process the segment normally, as specified in RFC 793. This includes dropping segments that are outside the window and possibly sending acknowledgments, and queuing in-window, out-of-sequence segments.
H3）按照RFC 793的规定，正常处理管段。这包括丢弃窗口外的段并可能发送确认，以及在窗口中排队，顺序不一致的段。
Another possibility would be to interchange steps H1 and H2, i.e., to perform the header prediction step H2 *first*, and perform H1 and H3 only when header prediction fails. This could be a performance improvement, since the timestamp check in step H1 is very unlikely to fail, and it requires unsigned modulo arithmetic. To perform this check on every single segment is contrary to the philosophy of header prediction. We believe that this change might produce a measurable reduction in CPU time for TCP protocol processing on high-speed networks.
另一种可能性是交换步骤H1和H2，即，执行报头预测步骤H2*first*，并且仅在报头预测失败时执行H1和H3。这可能是一种性能改进，因为步骤H1中的时间戳检查不太可能失败，并且需要无符号模运算。对每个段执行此检查与报头预测的原理相反。我们相信，这种变化可能会显著减少高速网络上TCP协议处理的CPU时间。
However, putting H2 first would create a hazard: a segment from 2^32 bytes in the past might arrive at exactly the wrong time and be accepted mistakenly by the header-prediction step. The following reasoning has been introduced in [RFC1185] to show that the probability of this failure is negligible.
但是，将H2放在第一位会产生一种危险：过去2^32字节的段可能正好在错误的时间到达，并被报头预测步骤错误地接受。[RFC1185]中介绍了以下推理，以表明该故障的概率可以忽略不计。
If all segments are equally likely to show up as old duplicates,
then the probability of an old duplicate exactly matching the left
window edge is the maximum segment size (MSS) divided by the size
of the sequence space. This ratio must be less than 2^-16, since
MSS must be < 2^16; for example, it will be (2^12)/(2^32) = 2^-20
for [a 100 Mbit/s] link. However, the older a segment is, the
less likely it is to be retained in the Internet, and under any
If all segments are equally likely to show up as old duplicates,
then the probability of an old duplicate exactly matching the left
window edge is the maximum segment size (MSS) divided by the size
of the sequence space. This ratio must be less than 2^-16, since
MSS must be < 2^16; for example, it will be (2^12)/(2^32) = 2^-20
for [a 100 Mbit/s] link. However, the older a segment is, the
less likely it is to be retained in the Internet, and under any
reasonable model of segment lifetime the probability of an old duplicate exactly at the left window edge must be much smaller than 2^-16.
段寿命的合理模型精确位于左窗口边缘的旧复制的概率必须远小于2^-16。
The 16 bit TCP checksum also allows a basic unreliability of one part in 2^16. A protocol mechanism whose reliability exceeds the reliability of the TCP checksum should be considered "good enough", i.e., it won't contribute significantly to the overall error rate. We therefore believe we can ignore the problem of an old duplicate being accepted by doing header prediction before checking the timestamp. [Note: the notation for exponentiation has been changed from how it appeared in RFC 1185.]
16位TCP校验和还允许2^16中一个部分的基本不可靠性。可靠性超过TCP校验和可靠性的协议机制应被视为“足够好”，即它不会对总体错误率产生显著影响。因此，我们相信，通过在检查时间戳之前进行报头预测，可以忽略旧副本被接受的问题。[注：指数表示法已从RFC 1185中的显示方式更改。]
However, this probabilistic argument is not universally accepted, and the consensus at present is that the performance gain does not justify the hazard in the general case. It is therefore recommended that H2 follow H1.
然而，这一概率论证并未被普遍接受，目前的共识是，在一般情况下，性能增益并不能证明危险是合理的。因此，建议H2跟随H1。
At high data rates, the protection against old segments provided by PAWS can be circumvented by errors in IP fragment reassembly (see [RFC4963]). The only way to protect against incorrect IP fragment reassembly is to not allow the segments to be fragmented. This is done by setting the Don't Fragment (DF) bit in the IP header.
在高数据速率下，IP片段重组中的错误可以避免PAWS提供的对旧段的保护（参见[RFC4963]）。防止错误IP片段重组的唯一方法是不允许片段被分段。这是通过在IP报头中设置不分段（DF）位来完成的。
Setting the DF bit implies the use of Path MTU Discovery as described in [RFC1191], [RFC1981], and [RFC4821]; thus, any TCP implementation that implements PAWS MUST also implement Path MTU Discovery.
设置DF位意味着使用[RFC1191]、[RFC1981]和[RFC4821]中所述的路径MTU发现；因此，任何实现PAWS的TCP实现也必须实现路径MTU发现。
The PAWS mechanism protects against errors due to sequence number wrap-around on high-speed connections. Segments from an earlier incarnation of the same connection are also a potential cause of old duplicate errors. In both cases, the TCP mechanisms to prevent such errors depend upon the enforcement of an MSL by the Internet (IP) layer (see the Appendix of RFC 1185 for a detailed discussion). Unlike the case of sequence space wrap-around, the MSL required to prevent old duplicate errors from earlier incarnations does not depend upon the transfer rate. If the IP layer enforces the recommended 2-minute MSL of TCP, and if the TCP rules are followed, TCP connections will be safe from earlier incarnations, no matter how high the network speed. Thus, the PAWS mechanism is not required for this case.
PAWS机构可防止因高速连接上的序号缠绕而导致的错误。来自同一连接的早期版本的段也是旧的重复错误的潜在原因。在这两种情况下，防止此类错误的TCP机制取决于互联网（IP）层对MSL的强制执行（有关详细讨论，请参阅RFC 1185的附录）。与序列空间环绕的情况不同，防止早期版本的旧重复错误所需的MSL不取决于传输速率。如果IP层强制执行TCP的建议2分钟MSL，并且遵守TCP规则，则无论网络速度有多高，TCP连接都不会受到早期版本的影响。因此，这种情况下不需要棘爪机构。
We may still ask whether the PAWS mechanism can provide additional security against old duplicates from earlier connections, allowing us to relax the enforcement of MSL by the IP layer. Appendix B explores this question, showing that further assumptions and/or mechanisms are required, beyond those of PAWS. This is not part of the current extension.
我们可能仍然会问，PAWS机制是否能够针对早期连接中的旧副本提供额外的安全性，从而允许我们放松IP层对MSL的强制执行。附录B探讨了这个问题，表明除了PAWS的假设和/或机制之外，还需要进一步的假设和/或机制。这不是当前扩展的一部分。
This memo presented a set of extensions to TCP to provide efficient operation over large bandwidth * delay product paths and reliable operation over very high-speed paths. These extensions are designed to provide compatible interworking with TCP stacks that do not implement the extensions.
此备忘录提供了一组TCP扩展，以在大带宽*延迟乘积路径上提供高效操作，并在超高速路径上提供可靠操作。这些扩展旨在提供与未实现扩展的TCP堆栈的兼容互通。
These mechanisms are implemented using TCP options for scaled windows and timestamps. The timestamps are used for two distinct mechanisms: RTTM and PAWS.
这些机制是使用TCP选项实现的，用于缩放窗口和时间戳。时间戳用于两种不同的机制：RTTM和PAWS。
The Window Scale option was originally suggested by Mike St. Johns of USAF/DCA. The present form of the option was suggested by Mike Karels of UC Berkeley in response to a more cumbersome scheme defined by Van Jacobson. Lixia Zhang helped formulate the PAWS mechanism description in [RFC1185].
窗口比例选项最初是由美国空军/DCA的Mike St.Johns提出的。加州大学伯克利分校的迈克·卡勒斯（Mike Karels）针对范·雅各布森（Van Jacobson）定义的更为繁琐的方案提出了目前的期权形式。张立霞在[RFC1185]中帮助制定了爪机构描述。
Finally, much of this work originated as the result of discussions within the End-to-End Task Force on the theoretical limitations of transport protocols in general and TCP in particular. Task force members and others on the end2end-interest list have made valuable contributions by pointing out flaws in the algorithms and the documentation. Continued discussion and development since the publication of [RFC1323] originally occurred in the IETF TCP Large Windows Working Group, later on in the End-to-End Task Force, and most recently in the IETF TCP Maintenance Working Group. The authors are grateful for all these contributions.
最后，这项工作的大部分起源于端到端工作组就传输协议的理论局限性，特别是TCP进行讨论的结果。特别工作组成员和End2兴趣列表上的其他人通过指出算法和文档中的缺陷做出了宝贵贡献。自[RFC1323]出版以来，持续的讨论和发展最初发生在IETF TCP大型Windows工作组中，后来发生在端到端工作组中，最近发生在IETF TCP维护工作组中。作者感谢所有这些贡献。
The TCP sequence space is a fixed size, and as the window becomes larger, it becomes easier for an attacker to generate forged packets that can fall within the TCP window and be accepted as valid segments. While use of timestamps and PAWS can help to mitigate this, when using PAWS, if an attacker is able to forge a packet that is acceptable to the TCP connection, a timestamp that is in the future would cause valid segments to be dropped due to PAWS checks. Hence, implementers should take care to not open the TCP window drastically beyond the requirements of the connection.
TCP序列空间的大小是固定的，随着窗口变大，攻击者更容易生成伪造的数据包，这些数据包可以落在TCP窗口内并被接受为有效段。虽然使用时间戳和PAWS有助于缓解这种情况，但在使用PAWS时，如果攻击者能够伪造TCP连接可接受的数据包，则将来的时间戳将导致由于PAWS检查而丢弃有效段。因此，实现者应该注意不要在连接要求之外打开TCP窗口。
See [RFC5961] for mitigation strategies to blind in-window attacks.
请参阅[RFC5961]了解窗口内盲攻击的缓解策略。
A naive implementation that derives the timestamp clock value directly from a system uptime clock may unintentionally leak this information to an attacker. This does not directly compromise any of the mechanisms described in this document. However, this may be valuable information to a potential attacker. It is therefore RECOMMENDED to generate a random, per-connection offset to be used with the clock source when generating the Timestamps option value (see Section 5.4). By carefully choosing this random offset, further improvements as described in [RFC6191] are possible.
直接从系统正常运行时间时钟派生时间戳时钟值的简单实现可能会无意中将此信息泄漏给攻击者。这不会直接影响本文件中描述的任何机制。但是，对于潜在的攻击者来说，这可能是有价值的信息。因此，建议在生成时间戳选项值时，生成随机的每个连接偏移量，以便与时钟源一起使用（参见第5.4节）。通过仔细选择该随机偏移量，可以实现[RFC6191]中所述的进一步改进。
Expanding the TCP window beyond 64 KiB for IPv6 allows Jumbograms [RFC2675] to be used when the local network supports packets larger than 64 KiB. When larger TCP segments are used, the TCP checksum becomes weaker.
将IPv6的TCP窗口扩展到64 KiB之外，允许在本地网络支持大于64 KiB的数据包时使用巨型程序[RFC2675]。当使用较大的TCP段时，TCP校验和会变弱。
Mechanisms to protect the TCP header from modification should also protect the TCP options.
保护TCP头不被修改的机制也应该保护TCP选项。
Middleboxes and TCP options:
中间盒和TCP选项：
Some middleboxes have been known to remove the TCP options described in this document from TCP segments [Honda11]. Middleboxes that remove TCP options described in this document from the <SYN> segment interfere with the selection of parameters appropriate for the session. Removing any of these options in a <SYN,ACK> segment will leave the end hosts in a state that destroys the proper operation of the protocol.
已知一些中间盒会从TCP段中删除本文档中描述的TCP选项[Honda11]。从<SYN>段中删除本文档中描述的TCP选项的中间盒会干扰会话适当参数的选择。删除<SYN，ACK>段中的任何选项都会使终端主机处于破坏协议正常运行的状态。
* If a Window Scale option is removed from a <SYN,ACK> segment, the end hosts will not negotiate the window scaling factor correctly. Middleboxes must not remove or modify the Window Scale option from <SYN,ACK> segments.
* 如果从<SYN，ACK>段中删除窗口缩放选项，则终端主机将无法正确协商窗口缩放因子。中间盒不得从<SYN，ACK>段中删除或修改窗口比例选项。
* If a stateful firewall uses the window field to detect whether a received segment is inside the current window, and does not support the Window Scale option, it will not be able to correctly determine whether or not a packet is in the window. These middle boxes must also support the Window Scale option and apply the scale factor when processing segments. If the window scale factor cannot be determined, it must not do window-based processing.
* 如果有状态防火墙使用窗口字段检测接收的段是否在当前窗口内，并且不支持窗口缩放选项，则它将无法正确确定数据包是否在窗口内。这些中间框还必须支持“窗口比例”选项，并在处理线段时应用比例因子。如果无法确定窗口比例因子，则不能进行基于窗口的处理。
* If the Timestamps option is removed from the <SYN> or <SYN,ACK> segments, high speed connections that need PAWS would not have that protection. Successful negotiation of the Timestamps option enforces a stricter verification of incoming segments at the receiver. If the Timestamps option was removed from a subsequent data segment after a successful negotiation (e.g., as part of resegmentation), the segment is discarded by the receiver without further processing. Middleboxes should not remove the Timestamps option.
* 如果从<SYN>或<SYN，ACK>段中删除时间戳选项，则需要PAW的高速连接将不具有该保护。时间戳选项的成功协商强制在接收器处对传入段进行更严格的验证。如果在成功协商后（例如，作为重新分段的一部分）从后续数据段中删除了时间戳选项，则接收器将丢弃该段而无需进一步处理。中间盒不应删除时间戳选项。
* It must be noted that [RFC1323] doesn't address the case of the Timestamps option being dropped or selectively omitted after being negotiated, and that the update in this document may cause some broken middlebox behavior to be detected (potentially unresponsive TCP sessions).
* 必须注意的是，[RFC1323]没有解决时间戳选项在协商后被删除或选择性省略的情况，并且本文档中的更新可能会导致检测到一些中断的中间盒行为（可能是无响应的TCP会话）。
Implementations that depend on PAWS could provide a mechanism for the application to determine whether or not PAWS is in use on the connection and choose to terminate the connection if that protection doesn't exist. This is not just to protect the connection against middleboxes that might remove the Timestamps option, but also against remote hosts that do not have Timestamp support.
依赖PAWS的实现可以为应用程序提供一种机制，以确定PAWS是否在连接上使用，并在不存在保护的情况下选择终止连接。这不仅是为了保护连接不受可能删除时间戳选项的中间盒的影响，也是为了保护不支持时间戳的远程主机。
The TCP options described in this document do not expose individual user's data. However, a naive implementation simply using the system clock as a source for the Timestamps option will reveal characteristics of the TCP, potentially allowing more targeted attacks. It is therefore RECOMMENDED to generate a random, per-connection offset to be used with the clock source when generating the Timestamps option value (see Section 5.4).
本文档中描述的TCP选项不公开单个用户的数据。然而，简单地使用系统时钟作为时间戳选项的源的简单实现将揭示TCP的特性，可能允许更具针对性的攻击。因此，建议在生成时间戳选项值时，生成随机的每个连接偏移量，以便与时钟源一起使用（参见第5.4节）。
Furthermore, the combination, relative ordering, and padding of the TCP options described in Sections 2.2 and 3.2 will reveal additional clues to allow the fingerprinting of the system.
此外，第2.2节和第3.2节中描述的TCP选项的组合、相对顺序和填充将揭示允许系统指纹识别的额外线索。
The described TCP options are well known from the superceded [RFC1323]. IANA has updated the "TCP Option Kind Numbers" table under "TCP Parameters" to list this document (RFC 7323) as the reference for "Window Scale" and "Timestamps".
所描述的TCP选项在替代的[RFC1323]中是众所周知的。IANA已更新了“TCP参数”下的“TCP选项种类编号”表，将本文件（RFC 7323）列为“窗口比例”和“时间戳”的参考。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]Mogul，J.和S.Deering，“MTU发现路径”，RFC1191，1990年11月。
[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月。
[Allman99] Allman, M. and V. Paxson, "On Estimating End-to-End Network Path Properties", Proceedings of the ACM SIGCOMM Technical Symposium, Cambridge, MA, September 1999, <http://aciri.org/mallman/papers/estimation-la.pdf>.
[Allman99]Allman，M.和V.Paxson，“关于估算端到端网络路径属性”，ACM SIGCOMM技术研讨会论文集，马萨诸塞州剑桥，1999年9月<http://aciri.org/mallman/papers/estimation-la.pdf>.
[Floyd05] Floyd, S., "Subject: Re: [tcpm] RFC 1323: Timestamps option", message to the TCPM mailing list, 26 January 2007, <http://www.ietf.org/mail-archive/web/tcpm/current/ msg02508.html>.
[Floyd05]Floyd，S.，“主题：回复：[tcpm]RFC 1323:时间戳选项”，给tcpm邮件列表的信息，2007年1月26日<http://www.ietf.org/mail-archive/web/tcpm/current/ msg02508.html>。
[Garlick77] Garlick, L., Rom, R., and J. Postel, "Issues in Reliable Host-to-Host Protocols", Proceedings of the Second Berkeley Workshop on Distributed Data Management and Computer Networks, March 1977, <http://www.rfc-editor.org/ien/ien12.txt>.
[Garlick77]Garlick，L.，Rom，R.，和J.Postel，“可靠主机对主机协议的问题”，第二届伯克利分布式数据管理和计算机网络研讨会论文集，1977年3月<http://www.rfc-editor.org/ien/ien12.txt>.
[Honda11] Honda, M., Nishida, Y., Raiciu, C., Greenhalgh, A., Handley, M., and H. Tokuda, "Is it Still Possible to Extend TCP?", Proceedings of the ACM Internet Measurement Conference (IMC) '11, November 2011.
[Honda11]本田，M.，西田，Y.，雷丘，C.，格林哈勒，A.，汉德利，M.，和H.德田，“是否仍有可能扩展TCP？”，ACM互联网测量会议记录，2011年11月11日。
[Jacobson88a] Jacobson, V., "Congestion Avoidance and Control", SIGCOMM '88, Stanford, CA, August 1988, <http://ee.lbl.gov/papers/congavoid.pdf>.
[Jacobson88a]Jacobson，V.，“拥塞避免和控制”，SIGCOMM'88，加利福尼亚州斯坦福市，1988年8月<http://ee.lbl.gov/papers/congavoid.pdf>.
[Jacobson90a] Jacobson, V., "4BSD Header Prediction", ACM Computer Communication Review, April 1990.
[Jacobson90a]Jacobson，V.，“4BSD报头预测”，ACM计算机通信评论，1990年4月。
[Jacobson90c] Jacobson, V., "Subject: modified TCP congestion avoidance algorithm", message to the End2End-Interest mailing list, 30 April 1990, <ftp://ftp.isi.edu/end2end/ end2end-interest-1990.mail>.
[Jacobson90c]Jacobson，V.，“主题：改进的TCP拥塞避免算法”，发送给End2End Interest邮件列表的信息，1990年4月30日<ftp://ftp.isi.edu/end2end/ end2end-interest-1990.mail>。
[Karn87] Karn, P. and C. Partridge, "Estimating Round-Trip Times in Reliable Transport Protocols", Proceedings of SIGCOMM '87, August 1987.
[Karn87]Karn，P.和C.Partridge，“估算可靠传输协议中的往返时间”，SIGCOMM'87会议录，1987年8月。
[Kuehlewind10] Kuehlewind, M. and B. Briscoe, "Chirping for Congestion Control - Implementation Feasibility", November 2010, <http://bobbriscoe.net/projects/netsvc_i-f/ chirp_pfldnet10.pdf>.
[Kuehlewind10]Kuehlewind，M.和B.Briscoe，“啁啾用于拥塞控制-实施可行性”，2010年11月<http://bobbriscoe.net/projects/netsvc_i-f/ chirp_pfldnet10.pdf>。
[Kuzmanovic03] Kuzmanovic, A. and E. Knightly, "TCP-LP: Low-Priority Service via End-Point Congestion Control", 2003, <www.cs.northwestern.edu/~akuzma/doc/TCP-LP-ToN.pdf>.
[Kuzmanovic03]Kuzmanovic，A.和E.Knightly，“TCP-LP：通过端点拥塞控制的低优先级服务”，2003年，<www.cs.northwestern.edu/~akuzma/doc/TCP-LP-ToN.pdf>。
[Ludwig00] Ludwig, R. and K. Sklower, "The Eifel Retransmission Timer", ACM SIGCOMM Computer Communication Review Volume 30 Issue 3, July 2000, <http://ccr.sigcomm.org/archive/2000/july00/ LudwigFinal.pdf>.
[Ludwig00]Ludwig，R.和K.Sklower，“Eifel重传计时器”，ACM SIGCOMM计算机通信评论第30卷第3期，2000年7月<http://ccr.sigcomm.org/archive/2000/july00/ LudwigFinal.pdf>。
[Martin03] Martin, D., "Subject: [Tsvwg] RFC 1323.bis", message to the TSVWG mailing list, 30 September 2003, <http://www.ietf.org/mail-archive/web/tsvwg/current/ msg04435.html>.
[Martin03]Martin，D.，“主题：[Tsvwg]RFC 1323.bis”，致Tsvwg邮件列表的信息，2003年9月30日<http://www.ietf.org/mail-archive/web/tsvwg/current/ msg04435.html>。
[Medina04] Medina, A., Allman, M., and S. Floyd, "Measuring Interactions Between Transport Protocols and Middleboxes", Proceedings of the ACM SIGCOMM/USENIX Internet Measurement Conference, October 2004, <http://www.icir.net/tbit/tbit-Aug2004.pdf>.
[Medina04]Medina，A.，Allman，M.，和S.Floyd，“测量传输协议和中间盒之间的相互作用”，ACM SIGCOMM/USENIX互联网测量会议记录，2004年10月<http://www.icir.net/tbit/tbit-Aug2004.pdf>.
[Medina05] Medina, A., Allman, M., and S. Floyd, "Measuring the Evolution of Transport Protocols in the Internet", ACM Computer Communication Review Volume 35, No. 2, April 2005, <http://icir.net/floyd/papers/TCPevolution-Mar2005.pdf>.
[Medina05]Medina，A.，Allman，M.，和S.Floyd，“测量互联网传输协议的演变”，ACM计算机通信评论第35卷，第2期，2005年4月<http://icir.net/floyd/papers/TCPevolution-Mar2005.pdf>.
[RE-1323BIS] Oppermann, A., "Subject: Re: [tcpm] I-D Action: draft-ietf.tcpm-1323bis-13.txt", message to the TCPM mailing list, 01 June 2013, <http://www.ietf.org/ mail-archive/web/tcpm/current/msg08001.html>.
[RE-1323BIS]Oppermann，A.，“主题：RE:[tcpm]I-D行动：ietf.tcpm-1323BIS-13.txt草案”，发送至tcpm邮件列表的信息，2013年6月1日<http://www.ietf.org/ 邮件存档/web/tcpm/current/msg08001.html>。
[RFC1072] Jacobson, V. and R. Braden, "TCP extensions for long-delay paths", RFC 1072, October 1988.
[RFC1072]Jacobson，V.和R.Braden，“长延迟路径的TCP扩展”，RFC 1072，1988年10月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]Braden，R.，“互联网主机的要求-通信层”，标准3，RFC 1122，1989年10月。
[RFC1185] Jacobson, V., Braden, B., and L. Zhang, "TCP Extension for High-Speed Paths", RFC 1185, October 1990.
[RFC1185]Jacobson，V.，Braden，B.，和L.Zhang，“高速路径的TCP扩展”，RFC 11851990年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月。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981]McCann，J.，Deering，S.，和J.Mogul，“IP版本6的路径MTU发现”，RFC 1981，1996年8月。
[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月。
[RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", RFC 2675, August 1999.
[RFC2675]Borman，D.，Deering，S.，和R.Hinden，“IPv6巨型程序”，RFC 26751999年8月。
[RFC2883] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", RFC 2883, July 2000.
[RFC2883]Floyd，S.，Mahdavi，J.，Mathis，M.，和M.Podolsky，“TCP选择性确认（SACK）选项的扩展”，RFC 28832000年7月。
[RFC3522] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm for TCP", RFC 3522, April 2003.
[RFC3522]Ludwig，R.和M.Meyer，“TCP的Eifel检测算法”，RFC 3522，2003年4月。
[RFC4015] Ludwig, R. and A. Gurtov, "The Eifel Response Algorithm for TCP", RFC 4015, February 2005.
[RFC4015]Ludwig，R.和A.Gurtov，“TCP的Eifel响应算法”，RFC 4015，2005年2月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4821]Mathis，M.和J.Heffner，“打包层路径MTU发现”，RFC 48212007年3月。
[RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly Errors at High Data Rates", RFC 4963, July 2007.
[RFC4963]Heffner，J.，Mathis，M.，和B.Chandler，“高数据速率下的IPv4重组错误”，RFC 4963，2007年7月。
[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月。
[RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's Robustness to Blind In-Window Attacks", RFC 5961, August 2010.
[RFC5961]Ramaiah，A.，Stewart，R.，和M.Dalal，“提高TCP对窗口盲攻击的鲁棒性”，RFC 59612010年8月。
[RFC6191] Gont, F., "Reducing the TIME-WAIT State Using TCP Timestamps", BCP 159, RFC 6191, April 2011.
[RFC6191]Gont，F.，“使用TCP时间戳减少等待时间状态”，BCP 159，RFC 61912011年4月。
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, June 2011.
[RFC6298]Paxson，V.，Allman，M.，Chu，J.，和M.Sargent，“计算TCP的重传计时器”，RFC 62982011年6月。
[RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence Number Attacks", RFC 6528, February 2012.
[RFC6528]Gont，F.和S.Bellovin，“防御序列号攻击”，RFC 6528，2012年2月。
[RFC6675] Blanton, E., Allman, M., Wang, L., Jarvinen, I., Kojo, M., and Y. Nishida, "A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP", RFC 6675, August 2012.
[RFC6675]Blanton，E.，Allman，M.，Wang，L.，Jarvinen，I.，Kojo，M.，和Y.Nishida，“基于TCP选择性确认（SACK）的保守丢失恢复算法”，RFC 6675，2012年8月。
[RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)", RFC 6691, July 2012.
[RFC6691]Borman，D.，“TCP选项和最大段大小（MSS）”，RFC 66912012年7月。
[RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, December 2012.
[RFC6817]Shalunov，S.，Hazel，G.，Iyengar，J.，和M.Kuehlewind，“低额外延迟背景传输（LEDBAT）”，RFC 68172012年12月。
TCP Option Layout
TCP选项布局
The following layout is recommended for sending options on non-<SYN> segments to achieve maximum feasible alignment of 32-bit and 64-bit machines.
建议使用以下布局在非<SYN>段上发送选项，以实现32位和64位机器的最大可行对齐。
+--------+--------+--------+--------+
| NOP | NOP | TSopt | 10 |
+--------+--------+--------+--------+
| TSval timestamp |
+--------+--------+--------+--------+
| TSecr timestamp |
+--------+--------+--------+--------+
+--------+--------+--------+--------+
| NOP | NOP | TSopt | 10 |
+--------+--------+--------+--------+
| TSval timestamp |
+--------+--------+--------+--------+
| TSecr timestamp |
+--------+--------+--------+--------+
Interaction with the TCP Urgent Pointer
与TCP紧急指针的交互
The TCP Urgent Pointer, like the TCP window, is a 16-bit value. Some of the original discussion for the TCP Window Scale option included proposals to increase the Urgent Pointer to 32 bits. As it turns out, this is unnecessary. There are two observations that should be made:
与TCP窗口一样，TCP紧急指针是一个16位的值。TCP窗口缩放选项的一些原始讨论包括将紧急指针增加到32位的建议。事实证明，这是不必要的。应进行两项观察：
(1) With IP version 4, the largest amount of TCP data that can be sent in a single packet is 65495 bytes (64 KiB - 1 - size of fixed IP and TCP headers).
(1) 对于IP版本4，单个数据包中可以发送的最大TCP数据量为65495字节（64 KiB-1-固定IP和TCP头的大小）。
(2) Updates to the Urgent Pointer while the user is in "urgent mode" are invisible to the user.
(2) 当用户处于“紧急模式”时，对紧急指针的更新对用户不可见。
This means that if the Urgent Pointer points beyond the end of the TCP data in the current segment, then the user will remain in urgent mode until the next TCP segment arrives. That segment will update the Urgent Pointer to a new offset, and the user will never have left urgent mode.
这意味着，如果紧急指针指向当前段中TCP数据的结尾之外，则用户将保持紧急模式，直到下一个TCP段到达。该段将把紧急指针更新到一个新的偏移量，用户将永远不会离开紧急模式。
Thus, to properly implement the Urgent Pointer, the sending TCP only has to check for overflow of the 16-bit Urgent Pointer field before filling it in. If it does overflow, than a value of 65535 should be inserted into the Urgent Pointer.
因此，要正确实现紧急指针，发送TCP只需在填充16位紧急指针字段之前检查其溢出情况。如果确实溢出，则应在紧急指针中插入65535的值。
The same technique applies to IP version 6, except in the case of IPv6 Jumbograms. When IPv6 Jumbograms are supported, [RFC2675] requires additional steps for dealing with the Urgent Pointer; these steps are described in Section 5.2 of [RFC2675].
同样的技术也适用于IP版本6，但IPv6巨型程序除外。当支持IPv6巨型程序时，[RFC2675]需要额外的步骤来处理紧急指针；[RFC2675]第5.2节描述了这些步骤。
There are two cases to be considered: (1) a system crashing (and losing connection state) and restarting, and (2) the same connection being closed and reopened without a loss of host state. These will be described in the following two sections.
有两种情况需要考虑：（1）系统崩溃（并失去连接状态）并重新启动，（2）相同的连接在没有主机状态丢失的情况下关闭并重新打开。这些将在以下两个部分中描述。
TCP's quiet time of one MSL upon system startup handles the loss of connection state in a system crash/restart. For an explanation, see, for example, "Knowing When to Keep Quiet" in the TCP protocol specification [RFC0793]. The MSL that is required here does not depend upon the transfer speed. The current TCP MSL of 2 minutes seemed acceptable as an operational compromise, when many host systems used to take this long to boot after a crash. Current host systems can boot considerably faster.
TCP在系统启动时的一个MSL的静默时间处理系统崩溃/重新启动时的连接状态丢失。有关解释，请参阅TCP协议规范[RFC0793]中的“知道何时保持安静”。此处所需的MSL不取决于传输速度。当前2分钟的TCP MSL作为一种操作上的折衷方案似乎是可以接受的，因为许多主机系统在崩溃后需要这么长时间才能启动。当前的主机系统可以更快地启动。
The Timestamps option may be used to ease the MSL requirements (or to provide additional security against data corruption). If timestamps are being used and if the timestamp clock can be guaranteed to be monotonic over a system crash/restart, i.e., if the first value of the sender's timestamp clock after a crash/restart can be guaranteed to be greater than the last value before the restart, then a quiet time is unnecessary.
时间戳选项可用于缓解MSL要求（或提供额外的数据损坏安全性）。如果正在使用时间戳，并且如果可以保证时间戳时钟在系统崩溃/重启期间是单调的，即，如果可以保证在崩溃/重启之后发送方的时间戳时钟的第一个值大于重启之前的最后一个值，则无需静默时间。
To dispense totally with the quiet time would require that the host clock be synchronized to a time source that is stable over the crash/ restart period, with an accuracy of one timestamp clock tick or better. We can back off from this strict requirement to take advantage of approximate clock synchronization. Suppose that the clock is always resynchronized to within N timestamp clock ticks and that booting (extended with a quiet time, if necessary) takes more than N ticks. This will guarantee monotonicity of the timestamps, which can then be used to reject old duplicates even without an enforced MSL.
要完全取消静默时间，需要将主机时钟同步到在崩溃/重启期间稳定的时间源，精度为一个时间戳时钟滴答或更好。我们可以放弃这一严格要求，利用近似时钟同步。假设时钟总是在N个时间戳时钟周期内重新同步，并且引导（如有必要，延长安静时间）需要N个周期以上。这将保证时间戳的单调性，即使没有强制MSL，也可以使用时间戳拒绝旧的重复。
When a TCP connection is closed, a delay of 2*MSL in TIME-WAIT state ties up the socket pair for 4 minutes (see Section 3.5 of [RFC0793]). Applications built upon TCP that close one connection and open a new one (e.g., an FTP data transfer connection using Stream mode) must choose a new socket pair each time. The TIME-WAIT delay serves two different purposes:
当TCP连接关闭时，处于等待状态的2*MSL延迟会将套接字对绑定4分钟（参见[RFC0793]第3.5节）。基于TCP构建的关闭一个连接并打开一个新连接的应用程序（例如，使用流模式的FTP数据传输连接）每次都必须选择一个新的套接字对。等待时间延迟有两个不同的用途：
(a) Implement the full-duplex reliable close handshake of TCP.
(a) 实现TCP的全双工可靠近距离握手。
The proper time to delay the final close step is not really related to the MSL; it depends instead upon the RTO for the FIN segments and, therefore, upon the RTT of the path. (It could be argued that the side that is sending a FIN knows what degree of reliability it needs, and therefore it should be able to determine the length of the TIME-WAIT delay for the FIN's recipient. This could be accomplished with an appropriate TCP option in FIN segments.)
延迟最终关闭步骤的适当时间实际上与MSL无关；它取决于鳍段的RTO，因此取决于路径的RTT。（可以说，发送FIN的一方知道它需要什么程度的可靠性，因此它应该能够确定FIN接收方的等待时间延迟长度。这可以通过FIN段中的适当TCP选项来实现。）
Although there is no formal upper bound on RTT, common network engineering practice makes an RTT greater than 1 minute very unlikely. Thus, the 4-minute delay in TIME-WAIT state works satisfactorily to provide a reliable full-duplex TCP close. Note again that this is independent of MSL enforcement and network speed.
虽然RTT没有正式的上限，但常见的网络工程实践使得RTT不太可能超过1分钟。因此，延时状态下的4分钟延迟可以令人满意地提供可靠的全双工TCP关闭。再次注意，这与MSL强制执行和网络速度无关。
The TIME-WAIT state could cause an indirect performance problem if an application needed to repeatedly close one connection and open another at a very high frequency, since the number of available TCP ports on a host is less than 2^16. However, high network speeds are not the major contributor to this problem; the RTT is the limiting factor in how quickly connections can be opened and closed. Therefore, this problem will be no worse at high transfer speeds.
如果应用程序需要以非常高的频率反复关闭一个连接并打开另一个连接，则TIME-WAIT状态可能会导致间接性能问题，因为主机上可用的TCP端口数少于2^16。然而，高网络速度并不是造成这个问题的主要原因；RTT是连接打开和关闭速度的限制因素。因此，在高传输速度下，该问题不会更严重。
(b) Allow old duplicate segments to expire.
(b) 允许旧的重复段过期。
To replace this function of TIME-WAIT state, a mechanism would have to operate across connections. PAWS is defined strictly within a single connection; the last timestamp (TS.Recent) is kept in the connection control block and discarded when a connection is closed.
要替换这种时间等待状态的功能，必须有一种机制跨连接运行。PAWS严格定义在单个连接中；最后一个时间戳（TS.Recent）保存在连接控制块中，并在连接关闭时丢弃。
An additional mechanism could be added to the TCP, a per-host cache of the last timestamp received from any connection. This value could then be used in the PAWS mechanism to reject old duplicate segments from earlier incarnations of the connection, if the timestamp clock can be guaranteed to have ticked at least once since the old connection was open. This would require that the TIME-WAIT delay plus the RTT together must be at least one tick of the sender's timestamp clock. Such an extension is not part of the proposal of this RFC.
可以向TCP添加一个附加机制，即从任何连接接收的最后一个时间戳的每主机缓存。如果可以保证时间戳时钟自旧连接打开以来至少勾选了一次，则该值可以在PAWS机制中用于拒绝来自连接早期版本的旧重复段。这将要求等待时间延迟加上RTT必须至少是发送方时间戳时钟的一个刻度。此类延期不属于本RFC提案的一部分。
Note that this is a variant on the mechanism proposed by Garlick, Rom, and Postel [Garlick77], which required each host to maintain connection records containing the highest sequence
请注意，这是Garlick、Rom和Postel[Garlick77]提出的机制的一个变体，该机制要求每个主机维护包含最高序列的连接记录
numbers on every connection. Using timestamps instead, it is only necessary to keep one quantity per remote host, regardless of the number of simultaneous connections to that host.
每个连接上的数字。相反，使用时间戳，只需为每个远程主机保留一个数量，而不考虑与该主机同时连接的数量。
The following notation has been used in this document.
本文件中使用了以下符号。
Options
选择权
WSopt: TCP Window Scale option TSopt: TCP Timestamps option
WSopt:TCP窗口缩放选项TSopt:TCP时间戳选项
Option Fields
选项字段
shift.cnt: Window scale byte in WSopt TSval: 32-bit Timestamp Value field in TSopt TSecr: 32-bit Timestamp Reply field in TSopt
shift.cnt:WSopt TSval中的窗口缩放字节：TSopt TSecr中的32位时间戳值字段：TSopt中的32位时间戳回复字段
Option Fields in Current Segment
当前段中的选项字段
SEG.TSval: TSval field from TSopt in current segment SEG.TSecr: TSecr field from TSopt in current segment SEG.WSopt: 8-bit value in WSopt
SEG.TSval:TSval字段来自当前段的TSopt SEG.TSecr:TSopt字段来自当前段的TSopt SEG.WSopt:WSopt中的8位值
Clock Values
时钟值
my.TSclock: System-wide source of 32-bit timestamp values my.TSclock.rate: Period of my.TSclock (1 ms to 1 sec) Snd.TSoffset: An offset for randomizing Snd.TSclock Snd.TSclock: my.TSclock + Snd.TSoffset
my.TSclock:32位时间戳值的系统范围源my.TSclock.rate:my.TSclock的周期（1毫秒到1秒）Snd.TSoffset：随机化Snd.TSclock Snd.TSclock的偏移量：my.TSclock+Snd.TSoffset
Per-Connection State Variables
每连接状态变量
TS.Recent: Latest received Timestamp Last.ACK.sent: Last ACK field sent Snd.TS.OK: 1-bit flag Snd.WS.OK: 1-bit flag Rcv.Wind.Shift: Receive window scale exponent Snd.Wind.Shift: Send window scale exponent Start.Time: Snd.TSclock value when the segment being timed was sent (used by code from before RFC 1323).
TS.Recent:最近接收的时间戳Last.ACK.sent:发送的最后一个ACK字段Snd.TS.OK:1位标志Snd.WS.OK:1位标志Rcv.Wind.Shift:接收窗口比例指数Snd.Wind.Shift:发送窗口比例指数开始。Time:发送正计时的段时的Snd.TSclock值（由RFC 1323之前的代码使用）。
Procedure
程序
Update_SRTT(m) Procedure to update the smoothed RTT and RTT variance estimates, using the rules of [Jacobson88a], given m, a new RTT measurement
Update_SRTT（m）程序，使用[Jacobson88a]的规则更新平滑RTT和RTT方差估计，给定m，一个新的RTT度量
Send Sequence Variables
发送序列变量
SND.UNA: Send unacknowledged SND.NXT: Send next SND.WND: Send window ISS: Initial send sequence number
SND.UNA:发送未确认的SND.NXT:发送下一个SND.WND:发送窗口ISS:初始发送序列号
Receive Sequence Variables
接收序列变量
RCV.NXT: Receive next RCV.WND: Receive window IRS: Initial receive sequence number
RCV.NXT:接收下一个RCV.WND:接收窗口IRS:初始接收序列号
This appendix attempts to specify the algorithms unambiguously by presenting modifications to the Event Processing rules in Section 3.9 of RFC 793. The change bars ("|") indicate lines that are different from RFC 793.
本附录试图通过对RFC 793第3.9节中事件处理规则的修改，明确规定算法。更改栏（“|”）表示与RFC 793不同的行。
OPEN Call
公开电话
...
...
An initial send sequence number (ISS) is selected. Send a <SYN>
| segment of the form:
|
| <SEQ=ISS><CTL=SYN><TSval=Snd.TSclock><WSopt=Rcv.Wind.Shift>
An initial send sequence number (ISS) is selected. Send a <SYN>
| segment of the form:
|
| <SEQ=ISS><CTL=SYN><TSval=Snd.TSclock><WSopt=Rcv.Wind.Shift>
...
...
SEND Call
打电话
CLOSED STATE (i.e., TCB does not exist)
关闭状态（即TCB不存在）
...
...
LISTEN STATE
倾听状态
If active and the foreign socket is specified, then change the connection from passive to active, select an ISS. Send a SYN | segment containing the options: <TSval=Snd.TSclock> and | <WSopt=Rcv.Wind.Shift>. Set SND.UNA to ISS, SND.NXT to ISS+1. Enter SYN-SENT state. ...
如果指定了主动和外部插座，则将连接从被动更改为主动，选择ISS。发送包含以下选项的同步段：<TSval=Snd.TSclock>和|<WSopt=Rcv.Wind.Shift>。将SND.UNA设置为ISS，将SND.NXT设置为ISS+1。输入SYN-SENT状态。。。
SYN-SENT STATE SYN-RECEIVED STATE
同步发送状态同步接收状态
...
...
ESTABLISHED STATE CLOSE-WAIT STATE
建立状态关闭等待状态
Segmentize the buffer and send it with a piggybacked acknowledgment (acknowledgment value = RCV.NXT). ...
对缓冲区进行分段，并使用一个piggybacked确认（确认值=RCV.NXT）发送它。。。
If the urgent flag is set ...
如果设置了紧急标志。。。
| If the Snd.TS.OK flag is set, then include the TCP Timestamps
| option <TSval=Snd.TSclock,TSecr=TS.Recent> in each data
| segment.
|
| Scale the receive window for transmission in the segment
| header:
|
| SEG.WND = (RCV.WND >> Rcv.Wind.Shift).
| If the Snd.TS.OK flag is set, then include the TCP Timestamps
| option <TSval=Snd.TSclock,TSecr=TS.Recent> in each data
| segment.
|
| Scale the receive window for transmission in the segment
| header:
|
| SEG.WND = (RCV.WND >> Rcv.Wind.Shift).
SEGMENT ARRIVES
段到达
...
...
If the state is LISTEN then
如果状态是监听，那么
first check for an RST
首先检查RST
...
...
second check for an ACK
第二次确认
...
...
third check for a SYN
第三次检查SYN
If the SYN bit is set, check the security. If the ...
如果设置了SYN位，请检查安全性。如果。。。
...
...
If the SEG.PRC is less than the TCB.PRC then continue.
如果SEG.PRC小于TCB.PRC，则继续。
| Check for a Window Scale option (WSopt); if one is found,
| save SEG.WSopt in Snd.Wind.Shift and set Snd.WS.OK flag on.
| Otherwise, set both Snd.Wind.Shift and Rcv.Wind.Shift to
| zero and clear Snd.WS.OK flag.
|
| Check for a TSopt option; if one is found, save SEG.TSval in
| the variable TS.Recent and turn on the Snd.TS.OK bit.
| Check for a Window Scale option (WSopt); if one is found,
| save SEG.WSopt in Snd.Wind.Shift and set Snd.WS.OK flag on.
| Otherwise, set both Snd.Wind.Shift and Rcv.Wind.Shift to
| zero and clear Snd.WS.OK flag.
|
| Check for a TSopt option; if one is found, save SEG.TSval in
| the variable TS.Recent and turn on the Snd.TS.OK bit.
Set RCV.NXT to SEG.SEQ+1, IRS is set to SEG.SEQ and any other control or text should be queued for processing later. ISS should be selected and a SYN segment sent of the form:
将RCV.NXT设置为SEG.SEQ+1，IRS设置为SEG.SEQ，任何其他控件或文本应排队等待稍后处理。应选择ISS，并按以下格式发送SYN段：
<SEQ=ISS><ACK=RCV.NXT><CTL=SYN,ACK>
<SEQ=ISS><ACK=RCV.NXT><CTL=SYN,ACK>
| If the Snd.WS.OK bit is on, include a WSopt
| <WSopt=Rcv.Wind.Shift> in this segment. If the Snd.TS.OK
| bit is on, include a TSopt <TSval=Snd.TSclock,
| TSecr=TS.Recent> in this segment. Last.ACK.sent is set to
| RCV.NXT.
| If the Snd.WS.OK bit is on, include a WSopt
| <WSopt=Rcv.Wind.Shift> in this segment. If the Snd.TS.OK
| bit is on, include a TSopt <TSval=Snd.TSclock,
| TSecr=TS.Recent> in this segment. Last.ACK.sent is set to
| RCV.NXT.
SND.NXT is set to ISS+1 and SND.UNA to ISS. The connection state should be changed to SYN-RECEIVED. Note that any other incoming control or data (combined with SYN) will be processed in the SYN-RECEIVED state, but processing of SYN and ACK should not be repeated. If the listen was not fully specified (i.e., the foreign socket was not fully specified), then the unspecified fields should be filled in now.
SND.NXT设置为ISS+1，SND.UNA设置为ISS。连接状态应更改为SYN-RECEIVE。请注意，任何其他传入控制或数据（与SYN结合）将在SYN-RECEIVED状态下进行处理，但SYN和ACK的处理不应重复。如果未完全指定侦听（即未完全指定外部套接字），则应立即填写未指定的字段。
fourth other text or control
第四，其他文本或控件
...
...
If the state is SYN-SENT then
如果状态为SYN-SENT，则
first check the ACK bit
首先检查确认位
...
...
...
...
fourth check the SYN bit
第四，检查SYN位
...
...
If the SYN bit is on and the security/compartment and precedence are acceptable then, RCV.NXT is set to SEG.SEQ+1, IRS is set to SEG.SEQ. SND.UNA should be advanced to equal SEG.ACK (if there is an ACK), and any segments on the retransmission queue which are thereby acknowledged should be removed.
如果SYN位为on且安全/隔间和优先级可接受，则RCV.NXT设置为SEG.SEQ+1，IRS设置为SEG.SEQ。SND.UNA应提前到等于SEG.ACK（如果存在ACK），并且应移除重传队列上由此确认的任何段。
| Check for a Window Scale option (WSopt); if it is found,
| save SEG.WSopt in Snd.Wind.Shift; otherwise, set both
| Snd.Wind.Shift and Rcv.Wind.Shift to zero.
|
| Check for a Window Scale option (WSopt); if it is found,
| save SEG.WSopt in Snd.Wind.Shift; otherwise, set both
| Snd.Wind.Shift and Rcv.Wind.Shift to zero.
|
| Check for a TSopt option; if one is found, save SEG.TSval in
| variable TS.Recent and turn on the Snd.TS.OK bit in the
| connection control block. If the ACK bit is set, use
| Snd.TSclock - SEG.TSecr as the initial RTT estimate.
| Check for a TSopt option; if one is found, save SEG.TSval in
| variable TS.Recent and turn on the Snd.TS.OK bit in the
| connection control block. If the ACK bit is set, use
| Snd.TSclock - SEG.TSecr as the initial RTT estimate.
If SND.UNA > ISS (our SYN has been ACKed), change the connection state to ESTABLISHED, form an <ACK> segment:
如果SND.UNA>ISS（我们的SYN已确认），将连接状态更改为已建立，形成<ACK>段：
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
| and send it. If the Snd.TS.OK bit is on, include a TSopt
| option <TSval=Snd.TSclock,TSecr=TS.Recent> in this <ACK>
| segment. Last.ACK.sent is set to RCV.NXT.
| and send it. If the Snd.TS.OK bit is on, include a TSopt
| option <TSval=Snd.TSclock,TSecr=TS.Recent> in this <ACK>
| segment. Last.ACK.sent is set to RCV.NXT.
Data or controls that were queued for transmission may be included. If there are other controls or text in the segment, then continue processing at the sixth step below where the URG bit is checked; otherwise, return.
可能包括排队等待传输的数据或控件。如果段中有其他控件或文本，则在下面的第六步继续处理，检查URG位；否则，返回。
Otherwise, enter SYN-RECEIVED, form a <SYN,ACK> segment:
否则，输入SYN-RECEIVED，形成一个<SYN，ACK>段：
<SEQ=ISS><ACK=RCV.NXT><CTL=SYN,ACK>
<SEQ=ISS><ACK=RCV.NXT><CTL=SYN,ACK>
| and send it. If the Snd.TS.OK bit is on, include a TSopt
| option <TSval=Snd.TSclock,TSecr=TS.Recent> in this segment.
| If the Snd.WS.OK bit is on, include a WSopt option
| <WSopt=Rcv.Wind.Shift> in this segment. Last.ACK.sent is
| set to RCV.NXT.
| and send it. If the Snd.TS.OK bit is on, include a TSopt
| option <TSval=Snd.TSclock,TSecr=TS.Recent> in this segment.
| If the Snd.WS.OK bit is on, include a WSopt option
| <WSopt=Rcv.Wind.Shift> in this segment. Last.ACK.sent is
| set to RCV.NXT.
If there are other controls or text in the segment, queue them for processing after the ESTABLISHED state has been reached, return.
如果段中有其他控件或文本，请在达到已建立状态后将其排队以进行处理，然后返回。
fifth, if neither of the SYN or RST bits is set then drop the segment and return.
第五，如果没有设置SYN或RST位，则删除该段并返回。
Otherwise
否则
first check the sequence number
首先检查序列号
SYN-RECEIVED STATE ESTABLISHED STATE FIN-WAIT-1 STATE FIN-WAIT-2 STATE CLOSE-WAIT STATE CLOSING STATE LAST-ACK STATE TIME-WAIT STATE
SYN接收状态建立状态FIN-WAIT-1状态FIN-WAIT-2状态关闭等待状态关闭状态LAST-ACK状态TIME-WAIT状态
Segments are processed in sequence. Initial tests on arrival are used to discard old duplicates, but further processing is done in SEG.SEQ order. If a segment's contents straddle the boundary between old and new, only the new parts should be processed.
分段按顺序处理。到达时的初始测试用于丢弃旧的副本，但进一步的处理按SEG.SEQ顺序进行。如果段的内容跨越新旧边界，则只应处理新零件。
| Rescale the received window field:
|
| TrueWindow = SEG.WND << Snd.Wind.Shift,
|
| and use "TrueWindow" in place of SEG.WND in the following
| steps.
|
| Check whether the segment contains a Timestamps option and
| if bit Snd.TS.OK is on. If so:
|
| If SEG.TSval < TS.Recent and the RST bit is off:
|
| If the connection has been idle more than 24 days,
| save SEG.TSval in variable TS.Recent, else the segment
| is not acceptable; follow the steps below for an
| unacceptable segment.
|
| If SEG.TSval >= TS.Recent and SEG.SEQ <= Last.ACK.sent,
| then save SEG.TSval in variable TS.Recent.
| Rescale the received window field:
|
| TrueWindow = SEG.WND << Snd.Wind.Shift,
|
| and use "TrueWindow" in place of SEG.WND in the following
| steps.
|
| Check whether the segment contains a Timestamps option and
| if bit Snd.TS.OK is on. If so:
|
| If SEG.TSval < TS.Recent and the RST bit is off:
|
| If the connection has been idle more than 24 days,
| save SEG.TSval in variable TS.Recent, else the segment
| is not acceptable; follow the steps below for an
| unacceptable segment.
|
| If SEG.TSval >= TS.Recent and SEG.SEQ <= Last.ACK.sent,
| then save SEG.TSval in variable TS.Recent.
There are four cases for the acceptability test for an incoming segment:
进入段的可接受性测试有四种情况：
...
...
If an incoming segment is not acceptable, an acknowledgment should be sent in reply (unless the RST bit is set; if so drop the segment and return):
如果传入段不可接受，则应发送应答确认（除非设置了RST位；如果设置了RST位，则删除该段并返回）：
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
| Last.ACK.sent is set to SEG.ACK of the acknowledgment. If
| the Snd.TS.OK bit is on, include the Timestamps option
| <TSval=Snd.TSclock,TSecr=TS.Recent> in this <ACK> segment.
Set Last.ACK.sent to SEG.ACK and send the <ACK> segment.
After sending the acknowledgment, drop the unacceptable
segment and return.
| Last.ACK.sent is set to SEG.ACK of the acknowledgment. If
| the Snd.TS.OK bit is on, include the Timestamps option
| <TSval=Snd.TSclock,TSecr=TS.Recent> in this <ACK> segment.
Set Last.ACK.sent to SEG.ACK and send the <ACK> segment.
After sending the acknowledgment, drop the unacceptable
segment and return.
...
...
fifth check the ACK field,
第五，检查确认字段，
if the ACK bit is off drop the segment and return
如果ACK位为off，则删除该段并返回
if the ACK bit is on
如果ACK位为on
...
...
ESTABLISHED STATE
既定国家
If SND.UNA < SEG.ACK <= SND.NXT then, set SND.UNA <-
| SEG.ACK. Also compute a new estimate of round-trip time.
| If Snd.TS.OK bit is on, use Snd.TSclock - SEG.TSecr;
| otherwise, use the elapsed time since the first segment
| in the retransmission queue was sent. Any segments on
the retransmission queue that are thereby entirely
acknowledged...
If SND.UNA < SEG.ACK <= SND.NXT then, set SND.UNA <-
| SEG.ACK. Also compute a new estimate of round-trip time.
| If Snd.TS.OK bit is on, use Snd.TSclock - SEG.TSecr;
| otherwise, use the elapsed time since the first segment
| in the retransmission queue was sent. Any segments on
the retransmission queue that are thereby entirely
acknowledged...
...
...
seventh, process the segment text,
第七，处理段文本，
ESTABLISHED STATE FIN-WAIT-1 STATE FIN-WAIT-2 STATE
已建立状态FIN-WAIT-1状态FIN-WAIT-2状态
...
...
Send an acknowledgment of the form:
发送对表格的确认：
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
| If the Snd.TS.OK bit is on, include the Timestamps option
| <TSval=Snd.TSclock,TSecr=TS.Recent> in this <ACK> segment.
| Set Last.ACK.sent to SEG.ACK of the acknowledgment, and send
| it. This acknowledgment should be piggybacked on a segment
being transmitted if possible without incurring undue delay.
| If the Snd.TS.OK bit is on, include the Timestamps option
| <TSval=Snd.TSclock,TSecr=TS.Recent> in this <ACK> segment.
| Set Last.ACK.sent to SEG.ACK of the acknowledgment, and send
| it. This acknowledgment should be piggybacked on a segment
being transmitted if possible without incurring undue delay.
...
...
While the rules laid out for when to calculate RTTM produce the correct results most of the time, there are some edge cases where an incorrect RTTM can be calculated. All of these situations involve the loss of segments. It is felt that these scenarios are rare, and that if they should happen, they will cause a single RTTM measurement to be inflated, which mitigates its effects on RTO calculations.
虽然为何时计算RTTM制定的规则在大多数情况下都会产生正确的结果，但在某些情况下，可能会计算出不正确的RTTM。所有这些情况都涉及到段的丢失。人们认为，这些场景非常罕见，如果发生，将导致单个RTTM测量值膨胀，从而减轻其对RTO计算的影响。
[Martin03] cites two similar cases when the returning <ACK> is lost, and before the retransmission timer fires, another returning <ACK> segment arrives, which acknowledges the data. In this case, the RTTM calculated will be inflated:
[Martin03]列举了两种类似的情况，返回的<ACK>丢失，在重新传输计时器启动之前，另一个返回的<ACK>段到达，确认数据。在这种情况下，计算的RTTM将充气：
clock
tc=1 <A, TSval=1> ------------------->
clock
tc=1 <A, TSval=1> ------------------->
tc=2 (lost) <---- <ACK(A), TSecr=1, win=n>
(RTTM would have been 1)
tc=2 (lost) <---- <ACK(A), TSecr=1, win=n>
(RTTM would have been 1)
(receive window opens, window update is sent)
tc=5 <---- <ACK(A), TSecr=1, win=m>
(RTTM is calculated at 4)
(receive window opens, window update is sent)
tc=5 <---- <ACK(A), TSecr=1, win=m>
(RTTM is calculated at 4)
One thing to note about this situation is that it is somewhat bounded by RTO + RTT, limiting how far off the RTTM calculation will be. While more complex scenarios can be constructed that produce larger inflations (e.g., retransmissions are lost), those scenarios involve multiple segment losses, and the connection will have other more serious operational problems than using an inflated RTTM in the RTO calculation.
关于这种情况需要注意的一点是，它在某种程度上受到RTO+RTT的限制，限制了RTTM计算的距离。虽然可以构建更复杂的场景，以产生更大的膨胀（例如，重新传输丢失），但这些场景涉及多个网段丢失，并且与在RTO计算中使用膨胀的RTTM相比，连接将有其他更严重的操作问题。
Consider an established TCP connection using a scale factor of 128, Snd.Wind.Shift=7 and Rcv.Wind.Shift=7, that is running with a very small window because the receiver is bottlenecked and both ends are doing small reads and writes.
考虑使用比例因子为128、SND.Wind、SHIFT＝7和RCV.Wind .SHIFT＝7的一个已建立的TCP连接，这是因为一个非常小的窗口运行，因为接收器是瓶颈的，两端都在进行小的读写。
Consider the ACKs coming back:
考虑一下ACK的回归：
SEG.ACK SEG.WIN computed SND.WIN receiver's actual window 1000 2 1256 1300
SEG.ACK SEG.WIN计算SND.WIN接收器的实际窗口1000 2 1256 1300
The sender writes 40 bytes and receiver ACKs:
发送方写入40字节，接收方确认：
1040 2 1296 1300
1040 2 1296 1300
The sender writes 5 additional bytes and the receiver has a problem. Two choices:
发送方额外写入5个字节，接收方出现问题。两种选择：
1045 2 1301 1300 - BEYOND BUFFER
1045 2 1301 1300-超出缓冲区
1045 1 1173 1300 - RETRACTED WINDOW
1045 1 1173 1300-收缩式车窗
This is a general problem and can happen any time the sender does a write, which is smaller than the window scale factor.
这是一个普遍的问题，并且在发送方执行小于窗口比例因子的写入操作的任何时候都可能发生。
In most stacks, it is at least partially obscured when the window size is larger than some small number of segments because the stacks prefer to announce windows that are an integral number of segments, rounded up to the next scale factor. This plus silly window suppression tends to cause less frequent, larger window updates. If the window was rounded down to a segment size, there is more opportunity to advance the window, the BEYOND BUFFER case above, rather than retracting it.
在大多数堆栈中，当窗口大小大于一些小的分段数时，它至少部分被遮挡，因为堆栈更喜欢宣布分段数为整数的窗口，四舍五入到下一个比例因子。这种加上愚蠢的窗口抑制往往会导致不太频繁、更大的窗口更新。如果窗口被四舍五入到一个段大小，则有更多的机会推进窗口，即上面的超出缓冲区的情况，而不是将其收回。
Appendix G. RTO Calculation Modification
附录G.RTO计算修改
Taking multiple RTT samples per window would shorten the history calculated by the RTO mechanism in [RFC6298], and the below algorithm aims to maintain a similar history as originally intended by [RFC6298].
每个窗口采集多个RTT样本将缩短[RFC6298]中RTO机制计算的历史记录，下面的算法旨在维护[RFC6298]最初预期的类似历史记录。
It is roughly known how many samples a congestion window worth of data will yield, not accounting for ACK compression, and ACK losses. Such events will result in more history of the path being reflected in the final value for RTO, and are uncritical. This modification will ensure that a similar amount of time is taken into account for the RTO estimation, regardless of how many samples are taken per window:
在不考虑ACK压缩和ACK损失的情况下，大致可以知道一个拥塞窗口值的数据将产生多少个样本。此类事件将导致更多路径的历史记录反映在RTO的最终值中，且不具有批判性。这一修改将确保RTO估算考虑的时间量相似，无论每个窗口采集多少样本：
ExpectedSamples = ceiling(FlightSize / (SMSS * 2))
ExpectedSamples = ceiling(FlightSize / (SMSS * 2))
alpha' = alpha / ExpectedSamples
alpha'=alpha/预期样本
beta' = beta / ExpectedSamples
beta'=beta/预期样本
Note that the factor 2 in ExpectedSamples is due to "Delayed ACKs".
请注意，ExpectedSamples中的系数2是由于“延迟确认”。
Instead of using alpha and beta in the algorithm of [RFC6298], use alpha' and beta' instead:
在[RFC6298]的算法中不使用alpha和beta，而是使用alpha和beta：
RTTVAR <- (1 - beta') * RTTVAR + beta' * |SRTT - R'|
RTTVAR <- (1 - beta') * RTTVAR + beta' * |SRTT - R'|
SRTT <- (1 - alpha') * SRTT + alpha' * R'
SRTT <- (1 - alpha') * SRTT + alpha' * R'
(for each sample R')
（对于每个样品R'）
Appendix H. Changes from RFC 1323
附录H.对RFC 1323的变更
Several important updates and clarifications to the specification in RFC 1323 are made in this document. The technical changes are summarized below:
本文件对RFC 1323中的规范进行了几次重要更新和澄清。技术变化总结如下：
(a) A wrong reference to SND.WND was corrected to SEG.WND in Section 2.3.
(a) 在第2.3节中，对SND.WND的错误引用被更正为SEG.WND。
(b) Section 2.4 was added describing the unavoidable window retraction issue and explicitly describing the mitigation steps necessary.
(b) 增加了第2.4节，描述了不可避免的车窗收缩问题，并明确描述了必要的缓解步骤。
(c) In Section 3.2, the wording how the Timestamps option negotiation is to be performed was updated with RFC2119 wording. Further, a number of paragraphs were added to clarify the expected behavior with a compliant implementation using TSopt, as RFC 1323 left room for interpretation -- e.g., potential late enablement of TSopt.
(c) 在第3.2节中，如何执行时间戳选项协商的措辞更新为RFC2119措辞。此外，添加了许多段落，以澄清使用TSopt的兼容实现的预期行为，因为RFC 1323留下了解释的空间——例如，TSopt的潜在延迟启用。
(d) The description of which TSecr values can be used to update the measured RTT has been clarified. Specifically, with timestamps, the Karn algorithm [Karn87] is disabled. The Karn algorithm disables all RTT measurements during retransmission, since it is ambiguous whether the <ACK> is for the original segment, or the retransmitted segment. With timestamps, that ambiguity is removed since the TSecr in the <ACK> will contain the TSval from whichever data segment made it to the destination.
(d) 已澄清了可用于更新测量RTT的TSecr值的说明。具体而言，使用时间戳时，禁用Karn算法[Karn87]。Karn算法在重传期间禁用所有RTT测量，因为<ACK>是用于原始段还是重传段是不明确的。对于时间戳，这种模糊性被消除，因为<ACK>中的TSecr将包含从到达目的地的任何数据段的TSval。
(e) RTTM update processing explicitly excludes segments not updating SND.UNA. The original text could be interpreted to allow taking RTT samples when SACK acknowledges some new, non-continuous data.
(e) RTTM更新处理明确排除未更新SND.UNA的段。原始文本可以解释为允许在SACK确认一些新的、非连续的数据时采集RTT样本。
(f) In RFC 1323, Section 3.4, step (2) of the algorithm to control which timestamp is echoed was incorrect in two regards:
(f) 在RFC 1323第3.4节中，控制回显哪个时间戳的算法步骤（2）在两个方面不正确：
(1) It failed to update TS.Recent for a retransmitted segment that resulted from a lost <ACK>.
(1) 它无法为丢失的<ACK>导致的重新传输段更新TS.Recent。
(2) It failed if SEG.LEN = 0.
(2) 如果SEG.LEN=0，则失败。
In the new algorithm, the case of SEG.TSval >= TS.Recent is included for consistency with the PAWS test.
在新算法中，为了与PAWS测试的一致性，包括SEG.TSval>=TS.Recent的情况。
(g) It is now recommended that the Timestamps option is included in <RST> segments if the incoming segment contained a Timestamps option.
(g) 现在，如果传入段包含时间戳选项，则建议在<RST>段中包含时间戳选项。
(h) <RST> segments are explicitly excluded from PAWS processing.
(h) <RST>段被明确排除在PAWS处理之外。
(i) Added text to clarify the precedence between regular TCP [RFC0793] and this document's Timestamps option / PAWS processing. Discussion about combined acceptability checks are ongoing.
(i) 添加文本以澄清常规TCP[RFC0793]和本文档的时间戳选项/PAWS处理之间的优先级。关于联合可接受性检查的讨论正在进行中。
(j) Snd.TSoffset and Snd.TSclock variables have been added. Snd.TSclock is the sum of my.TSclock and Snd.TSoffset. This allows the starting points for timestamp values to be randomized on a per-connection basis. Setting Snd.TSoffset to zero yields the same results as [RFC1323]. Text was added to guide implementers to the proper selection of these offsets, as entirely random offsets for each new connection will conflict with PAWS.
(j) 添加了Snd.TSoffset和Snd.TSclock变量。Snd.TSclock是my.TSclock和Snd.TSoffset之和。这允许在每个连接的基础上随机化时间戳值的起始点。将Snd.TSoffset设置为零会产生与[RFC1323]相同的结果。添加文本是为了指导实现者正确选择这些偏移，因为每个新连接的完全随机偏移将与PAW冲突。
(k) Appendix A has been expanded with information about the TCP Urgent Pointer. An earlier revision contained text around the TCP MSS option, which was split off into [RFC6691].
(k) 附录A已扩展为关于TCP紧急指针的信息。早期版本包含关于TCP MSS选项的文本，该选项分为[RFC6691]。
(l) One correction was made to the Event Processing Summary in Appendix D. In SEND CALL/ESTABLISHED STATE, RCV.WND is used to fill in the SEG.WND value, not SND.WND.
(l) 对附录D中的事件处理摘要进行了一次更正。在发送呼叫/建立状态下，RCV.WND用于填写SEG.WND值，而不是SND.WND。
(m) Appendix G was added to exemplify how an RTO calculation might be updated to properly take the much higher RTT sampling frequency enabled by the Timestamps option into account.
(m) 添加附录G是为了举例说明如何更新RTO计算，以适当考虑时间戳选项启用的更高RTT采样频率。
Editorial changes to the document, that don't impact the implementation or function of the mechanisms described in this document, include:
不影响本文件所述机制的实施或功能的文件编辑变更包括：
(a) Removed much of the discussion in Section 1 to streamline the document. However, detailed examples and discussions in Sections 2, 3, and 5 are kept as guidelines for implementers.
(a) 删除了第1节中的大部分讨论以简化文档。但是，第2、3和5节中的详细示例和讨论将作为实施者的指南。
(b) Added short text that the use of WS increases the chances of sequence number wrap, thus the PAWS mechanism is required in certain environments.
(b) 添加了简短的文字说明WS的使用增加了序列号换行的机会，因此在某些环境中需要PAWS机制。
(c) Removed references to "new" options, as the options were introduced in [RFC1323] already. Changed the text in Section 1.3 to specifically address TS and WS options.
(c) 删除了对“新”选项的引用，因为这些选项已在[RFC1323]中引入。更改了第1.3节中的文本，以明确说明TS和WS选项。
(d) Section 1.4 was added for [RFC2119] wording. Normative text was updated with the appropriate phrases.
(d) [RFC2119]措辞增加了第1.4节。用适当的短语更新了规范性文本。
(e) Added < > brackets to mark specific types of segments, and replaced most occurrences of "packet" with "segment", where TCP segments are referred to.
(e) 添加了<>括号以标记特定类型的段，并将大多数出现的“数据包”替换为“段”，其中涉及TCP段。
(f) Updated the text in Section 3 to take into account what has been learned since [RFC1323].
(f) 更新第3节中的文本，以考虑自[RFC1323]以来学到的内容。
(g) Removed some unused references.
(g) 删除了一些未使用的引用。
(h) Removed the list of changes between [RFC1323] and prior versions. These changes are mentioned in Appendix C of [RFC1323].
(h) 删除了[RFC1323]与以前版本之间的更改列表。[RFC1323]附录C中提到了这些变更。
(i) Moved "Changes from RFC 1323" to the end of the appendices for easier lookup. In addition, the entries were split into a technical and an editorial part, and sorted to roughly correspond with the sections in the text where they apply.
(i) 将“RFC 1323变更”移至附录末尾，以便于查找。此外，这些条目被分为技术部分和编辑部分，并进行分类，以大致符合文本中它们适用的部分。
Authors' Addresses
作者地址
David Borman Quantum Corporation Mendota Heights, MN 55120 USA
David Borman Quantum Corporation美国明尼苏达州门多塔高地55120
EMail: david.borman@quantum.com
EMail: david.borman@quantum.com
Bob Braden University of Southern California 4676 Admiralty Way Marina del Rey, CA 90292 USA
鲍勃布雷登南加州大学4676海军路玛丽娜德雷，CA 90292美国
EMail: braden@isi.edu
EMail: braden@isi.edu
Van Jacobson Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 USA
Van Jacobson Google，Inc.美国加利福尼亚州山景大道1600号圆形剧场，邮编94043
EMail: vanj@google.com
EMail: vanj@google.com
Richard Scheffenegger (editor) NetApp, Inc. Am Euro Platz 2 Vienna, 1120 Austria
Richard Scheffenegger（编辑）NetApp，Inc.Am Euro Platz 2维也纳，1120奥地利
EMail: rs@netapp.com
EMail: rs@netapp.com