Network Working Group L. Eggert
Request for Comments: 5482 Nokia
Category: Standards Track F. Gont
UTN/FRH
March 2009
Network Working Group L. Eggert
Request for Comments: 5482 Nokia
Category: Standards Track F. Gont
UTN/FRH
March 2009
TCP User Timeout Option
TCP用户超时选项
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Abstract
摘要
The TCP user timeout controls how long transmitted data may remain unacknowledged before a connection is forcefully closed. It is a local, per-connection parameter. This document specifies a new TCP option -- the TCP User Timeout Option -- that allows one end of a TCP connection to advertise its current user timeout value. This information provides advice to the other end of the TCP connection to adapt its user timeout accordingly. Increasing the user timeouts on both ends of a TCP connection allows it to survive extended periods without end-to-end connectivity. Decreasing the user timeouts allows busy servers to explicitly notify their clients that they will maintain the connection state only for a short time without connectivity.
TCP用户超时控制在强制关闭连接之前传输的数据未确认的时间。它是一个本地的每个连接参数。本文档指定了一个新的TCP选项—TCP用户超时选项—该选项允许TCP连接的一端公布其当前用户超时值。此信息向TCP连接的另一端提供建议，以相应地调整其用户超时。增加TCP连接两端的用户超时可以使其在没有端到端连接的情况下存活较长时间。减少用户超时允许繁忙的服务器显式通知其客户端，它们将仅在短时间内保持连接状态而不连接。
Table of Contents
目录
1. Introduction ....................................................2
2. Conventions .....................................................3
3. Operation .......................................................4
3.1. Changing the Local User Timeout ............................5
3.2. UTO Option Reliability .....................................8
3.3. Option Format ..............................................8
3.4. Reserved Option Values .....................................9
4. Interoperability Issues .........................................9
4.1. Middleboxes ................................................9
4.2. TCP Keep-Alives ...........................................10
5. Programming and Manageability Considerations ...................10
6. Security Considerations ........................................10
7. IANA Considerations ............................................12
8. Acknowledgments ................................................12
9. References .....................................................12
9.1. Normative References ......................................12
9.2. Informative References ....................................13
1. Introduction ....................................................2
2. Conventions .....................................................3
3. Operation .......................................................4
3.1. Changing the Local User Timeout ............................5
3.2. UTO Option Reliability .....................................8
3.3. Option Format ..............................................8
3.4. Reserved Option Values .....................................9
4. Interoperability Issues .........................................9
4.1. Middleboxes ................................................9
4.2. TCP Keep-Alives ...........................................10
5. Programming and Manageability Considerations ...................10
6. Security Considerations ........................................10
7. IANA Considerations ............................................12
8. Acknowledgments ................................................12
9. References .....................................................12
9.1. Normative References ......................................12
9.2. Informative References ....................................13
The Transmission Control Protocol (TCP) specification [RFC0793] defines a local, per-connection "user timeout" parameter that specifies the maximum amount of time that transmitted data may remain unacknowledged before TCP will forcefully close the corresponding connection. Applications can set and change this parameter with OPEN and SEND calls. If an end-to-end connectivity disruption lasts longer than the user timeout, a sender will receive no acknowledgments for any transmission attempt, including keep-alives, and it will close the TCP connection when the user timeout occurs.
传输控制协议（TCP）规范[RFC0793]定义了一个每个连接的本地“用户超时”参数，该参数指定了TCP强制关闭相应连接之前，传输数据可能保持未确认的最长时间。应用程序可以通过OPEN和SEND调用设置和更改此参数。如果端到端连接中断持续时间超过用户超时时间，则发送方将不会收到任何传输尝试的确认，包括保持有效，并且在用户超时时将关闭TCP连接。
This document specifies a new TCP option -- the TCP User Timeout Option (UTO) -- that allows one end of a TCP connection to advertise its current user timeout value. This information provides advice to the other end of the connection to adapt its user timeout accordingly. That is, TCP remains free to disregard the advice provided by the UTO option if local policies suggest it to be appropriate.
本文档指定了一个新的TCP选项——TCP用户超时选项（UTO）——它允许TCP连接的一端公布其当前用户超时值。此信息向连接的另一端提供建议，以相应地调整其用户超时。也就是说，如果当地政策认为UTO选项是合适的，TCP可以自由地忽略UTO选项提供的建议。
Increasing the user timeouts on both ends of a TCP connection allows it to survive extended periods without end-to-end connectivity. Decreasing the user timeouts allows busy servers to explicitly notify their clients that they will maintain the connection state only for a short time without connectivity.
增加TCP连接两端的用户超时可以使其在没有端到端连接的情况下存活较长时间。减少用户超时允许繁忙的服务器显式通知其客户端，它们将仅在短时间内保持连接状态而不连接。
In the absence of an application-specified user timeout, the TCP specification [RFC0793] defines a default user timeout of 5 minutes. The Host Requirements RFC [RFC1122] refines this definition by introducing two thresholds, R1 and R2 (R2 > R1), that control the number of retransmission attempts for a single segment. It suggests that TCP should notify applications when R1 is reached for a segment, and close the connection when R2 is reached. [RFC1122] also defines the recommended values for R1 (3 retransmissions) and R2 (100 seconds), noting that R2 for SYN segments should be at least 3 minutes. Instead of a single user timeout, some TCP implementations offer finer-grained policies. For example, Solaris supports different timeouts depending on whether a TCP connection is in the SYN-SENT, SYN-RECEIVED, or ESTABLISHED state [SOLARIS].
如果没有应用程序指定的用户超时，TCP规范[RFC0793]将默认用户超时定义为5分钟。主机需求RFC[RFC1122]通过引入两个阈值R1和R2（R2>R1）来细化该定义，这两个阈值控制单个网段的重传尝试次数。它建议TCP在到达某个段的R1时通知应用程序，并在到达R2时关闭连接。[RFC1122]还定义了R1（3次重传）和R2（100秒）的建议值，注意SYN段的R2应至少为3分钟。一些TCP实现提供了更细粒度的策略，而不是单用户超时。例如，Solaris支持不同的超时，具体取决于TCP连接是处于SYN-SENT、SYN-RECEIVE还是已建立状态[Solaris]。
Although some TCP implementations allow applications to set their local user timeout, TCP has no in-protocol mechanism to signal changes to the local user timeout to the other end of a connection. This causes local changes to be ineffective in allowing a connection to survive extended periods without connectivity, because the other end will still close the connection after its user timeout expires.
尽管某些TCP实现允许应用程序设置其本地用户超时，但TCP没有协议内机制将本地用户超时的更改通知到连接的另一端。这会导致本地更改在允许连接在没有连接的情况下长时间存在时无效，因为另一端在其用户超时过期后仍将关闭连接。
The ability to inform the other end of a connection about the local user timeout can improve TCP operation in scenarios that are currently not well supported. One example of such a scenario is mobile hosts that change network attachment points. Such hosts, maybe using Mobile IP [RFC3344], HIP [RFC4423], or transport-layer mobility mechanisms [TCP_MOB], are only intermittently connected to the Internet. In between connected periods, mobile hosts may experience periods without end-to-end connectivity. Other factors that can cause transient connectivity disruptions are high levels of congestion or link or routing failures inside the network. In these scenarios, a host may not know exactly when or for how long connectivity disruptions will occur, but it might be able to determine an increased likelihood for such events based on past mobility patterns and thus benefit from using longer user timeouts. In other scenarios, the time and duration of a connectivity disruption may even be predictable. For example, a node in space might experience connectivity disruptions due to line-of-sight blocking by planetary bodies. The timing of these events may be computable from orbital mechanics.
向连接的另一端通知本地用户超时的功能可以在当前不受很好支持的场景中改进TCP操作。这种情况的一个例子是更改网络连接点的移动主机。这样的主机，可能使用移动IP[RFC3344]、HIP[RFC4423]或传输层移动机制[TCP_MOB]，只是间歇性地连接到互联网。在连接的时段之间，移动主机可能会经历没有端到端连接的时段。可能导致暂时连接中断的其他因素是网络内部的高水平拥塞或链路或路由故障。在这些场景中，主机可能不知道何时或多长时间会发生连接中断，但它可能能够根据过去的移动模式确定此类事件发生的可能性增加，从而受益于使用更长的用户超时。在其他情况下，连接中断的时间和持续时间甚至可以预测。例如，由于行星体阻挡视线，空间中的节点可能会经历连接中断。这些事件的时间可以通过轨道力学来计算。
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]中所述进行解释。
Use of the TCP User Timeout Option can be either enabled on a per-connection basis, e.g., through an API option, or controlled by a system-wide setting. TCP maintains four per-connection state variables to control the operation of the UTO option, three of which (ADV_UTO, ENABLED, and CHANGEABLE) are new:
TCP用户超时选项的使用可以基于每个连接启用，例如通过API选项启用，也可以通过系统范围的设置控制。TCP为每个连接维护四个状态变量以控制UTO选项的操作，其中三个（ADV_UTO、ENABLED和Changed）是新的：
USER_TIMEOUT TCP's USER TIMEOUT parameter, as specified in [RFC0793].
用户超时TCP的用户超时参数，如[RFC0793]中所指定。
ADV_UTO UTO option advertised to the remote TCP peer. This is an application-specified value, and may be specified on a system-wide basis. If unspecified, it defaults to the default system-wide USER TIMEOUT.
ADV_UTO UTO选项播发给远程TCP对等方。这是应用程序指定的值，可以在系统范围内指定。如果未指定，则默认为默认的系统范围用户超时。
ENABLED (Boolean) Flag that controls whether the UTO option is enabled for a connection. This flag applies to both sending and receiving. Defaults to false.
启用（布尔）标志，用于控制是否为连接启用UTO选项。此标志同时适用于发送和接收。默认为false。
CHANGEABLE (Boolean) Flag that controls whether USER_TIMEOUT (TCP's USER TIMEOUT parameter) may be changed based on an UTO option received from the other end of the connection. Defaults to true and becomes false when an application explicitly sets USER_TIMEOUT.
可变（布尔）标志，用于控制是否可以根据从连接另一端接收的UTO选项更改用户超时（TCP的用户超时参数）。默认值为true，当应用程序显式设置用户超时时变为false。
Note that an exchange of UTO options between both ends of a connection is not a binding negotiation. Transmission of a UTO option is a suggestion that the other end consider adapting its user timeout. This adaptation only happens if the other end of the connection has explicitly allowed it (both ENABLED and CHANGEABLE are true).
请注意，连接两端之间的UTO选项交换不是具有约束力的协商。UTO选项的传输是另一端考虑调整其用户超时的建议。只有当连接的另一端明确允许时，才会发生这种自适应（ENABLED和Changed都为true）。
Before opening a connection, an application that wishes to use the UTO option enables its use by setting ENABLED to true. It may choose an appropriate local UTO by explicitly setting ADV_UTO; otherwise, UTO is set to the default USER TIMEOUT value. Finally, the application should determine whether it will allow the local USER TIMEOUT to change based on received UTO options from the other end of a connection. The default is to allow this for connections that do not have specific user timeout concerns. If an application explicitly sets the USER_TIMEOUT, CHANGEABLE MUST become false in order to prevent UTO options (from the other end) from overriding local application requests. Alternatively, applications can set or clear CHANGEABLE directly through API calls.
在打开连接之前，希望使用UTO选项的应用程序通过将ENABLED设置为true来启用其使用。它可以通过显式设置ADV_UTO来选择合适的本地UTO；否则，UTO设置为默认用户超时值。最后，应用程序应根据从连接另一端接收到的UTO选项确定是否允许更改本地用户超时。默认情况下，对于没有特定用户超时问题的连接，允许这样做。如果应用程序显式设置用户超时，则“可更改”必须变为false，以防止UTO选项（从另一端）覆盖本地应用程序请求。或者，应用程序可以直接通过API调用设置或清除变量。
Performing these steps before an active or passive open causes UTO options to be exchanged in the SYN and SYN-ACK packets and is a reliable way to initially exchange, and potentially adapt to, UTO values. TCP implementations MAY provide system-wide default settings for the ENABLED, ADV_UTO and CHANGEABLE connection parameters.
在主动或被动打开之前执行这些步骤会导致在SYN和SYN-ACK数据包中交换UTO选项，并且是一种可靠的初始交换和潜在适应UTO值的方法。TCP实现可以为已启用、自动和可更改的连接参数提供系统范围的默认设置。
In addition to exchanging UTO options in the SYN segments, a connection that has enabled UTO options SHOULD include a UTO option in the first packet that does not have the SYN flag set. This helps to minimize the amount of state information TCP must keep for connections in non-synchronized states. Also, it is particularly useful when mechanisms such as "SYN cookies" [RFC4987] are implemented, allowing a newly-established TCP connection to benefit from the information advertised by the UTO option, even if the UTO contained in the initial SYN segment was not recorded.
除了在SYN段中交换UTO选项外，已启用UTO选项的连接还应在未设置SYN标志的第一个数据包中包含UTO选项。这有助于最小化TCP必须为处于非同步状态的连接保留的状态信息量。此外，当实现诸如“SYN cookies”[RFC4987]等机制时，它特别有用，允许新建立的TCP连接受益于UTO选项公布的信息，即使初始SYN段中包含的UTO未被记录。
A host that supports the UTO option SHOULD include one in the next possible outgoing segment whenever it starts using a new user timeout for the connection. This allows the other end of the connection to adapt its local user timeout accordingly. A TCP implementation that does not support the UTO option MUST silently ignore it [RFC1122], thus ensuring interoperability.
支持UTO选项的主机在开始使用新用户超时进行连接时，应在下一个可能的传出段中包含一个UTO选项。这允许连接的另一端相应地调整其本地用户超时。不支持UTO选项的TCP实现必须默默地忽略它[RFC1122]，从而确保互操作性。
Hosts MUST impose upper and lower limits on the user timeouts they use for a connection. Section 3.1 discusses user timeout limits and potentially problematic effects of some user timeout settings.
主机必须对用于连接的用户超时设置上限和下限。第3.1节讨论了用户超时限制以及某些用户超时设置可能产生的问题。
Finally, it is worth noting that TCP's option space is limited to 40 bytes. As a result, if other TCP options are in use, they may already consume all the available TCP option space, thus preventing the use of the UTO option specified in this document. Therefore, TCP option space issues should be considered before enabling the UTO option.
最后，值得注意的是，TCP的选项空间限制为40字节。因此，如果正在使用其他TCP选项，它们可能已经占用了所有可用的TCP选项空间，从而阻止使用本文档中指定的UTO选项。因此，在启用UTO选项之前，应考虑TCP选项空间问题。
When a host receives a TCP User Timeout Option, it must decide whether to change the local user timeout of the corresponding connection. If the CHANGEABLE flag is false, USER_TIMEOUT MUST NOT be changed, regardless of the received UTO option. Without this restriction, the UTO option would modify TCP semantics, because an application-requested USER TIMEOUT could be overridden by peer requests. In this case TCP SHOULD, however, notify the application about the user timeout value received from the other end system.
当主机收到TCP用户超时选项时，它必须决定是否更改相应连接的本地用户超时。如果可变标志为false，则无论收到的UTO选项是什么，都不得更改用户超时。如果没有此限制，UTO选项将修改TCP语义，因为应用程序请求的用户超时可能会被对等请求覆盖。但是，在这种情况下，TCP应该通知应用程序从另一端系统接收到的用户超时值。
In general, unless the application on the local host has requested a specific USER TIMEOUT for the connection, CHANGEABLE will be true and hosts SHOULD adjust the local TCP USER TIMEOUT (USER_TIMEOUT) in response to receiving a UTO option, as described in the remainder of this section.
通常，除非本地主机上的应用程序已请求连接的特定用户超时，否则“可更改”将为true，主机应调整本地TCP用户超时（用户超时），以响应接收到的UTO选项，如本节其余部分所述。
The UTO option specifies the user timeout in seconds or minutes, rather than in number of retransmissions or round-trip times (RTTs). Thus, the UTO option allows hosts to exchange user timeout values from 1 second to over 9 hours at a granularity of seconds, and from 1 minute to over 22 days at a granularity of minutes.
UTO选项以秒或分钟为单位指定用户超时，而不是以重传次数或往返时间（RTT）为单位。因此，UTO选项允许主机以秒的粒度从1秒到9小时以上，以分钟的粒度从1分钟到22天以上交换用户超时值。
Very short USER TIMEOUT values can affect TCP transmissions over high-delay paths. If the user timeout occurs before an acknowledgment for an outstanding segment arrives, possibly due to packet loss, the connection closes. Many TCP implementations default to USER TIMEOUT values of a few minutes. Although the UTO option allows suggestion of short timeouts, applications advertising them should consider these effects.
非常短的用户超时值会影响高延迟路径上的TCP传输。如果用户超时发生在未完成段的确认到达之前（可能是由于数据包丢失），则连接将关闭。许多TCP实现默认用户超时值为几分钟。虽然UTO选项允许短期超时的建议，但广告应用应该考虑这些效果。
Long USER TIMEOUT values allow hosts to tolerate extended periods without end-to-end connectivity. However, they also require hosts to maintain the TCP state information associated with connections for long periods of time. Section 6 discusses the security implications of long timeout values.
长用户超时值允许主机在没有端到端连接的情况下容忍较长时间。但是，它们还需要主机长时间维护与连接相关的TCP状态信息。第6节讨论了长超时值的安全含义。
To protect against these effects, implementations MUST impose limits on the user timeout values they accept and use. The remainder of this section describes a RECOMMENDED scheme to limit TCP's USER TIMEOUT based on upper and lower limits.
为了防止这些影响，实现必须对它们接受和使用的用户超时值施加限制。本节的其余部分描述了一种基于上限和下限限制TCP用户超时的推荐方案。
Under the RECOMMENDED scheme, and when CHANGEABLE is true, each end SHOULD compute the local USER TIMEOUT for a connection according to this formula:
在推荐方案下，当change为true时，每端应根据以下公式计算连接的本地用户超时：
USER_TIMEOUT = min(U_LIMIT, max(ADV_UTO, REMOTE_UTO, L_LIMIT))
USER_TIMEOUT = min(U_LIMIT, max(ADV_UTO, REMOTE_UTO, L_LIMIT))
Each field is to be interpreted as follows:
每个字段的解释如下：
USER_TIMEOUT USER TIMEOUT value to be adopted by the local TCP for this connection.
用户超时本地TCP为此连接采用的用户超时值。
U_LIMIT Current upper limit imposed on the user timeout of a connection by the local host.
U_LIMIT本地主机对用户连接超时施加的当前上限。
ADV_UTO User timeout advertised to the remote TCP peer in a TCP User Timeout Option.
在TCP用户超时选项中将自动用户超时播发给远程TCP对等方。
REMOTE_UTO Last user timeout value received from the other end in a TCP User Timeout Option.
在TCP用户超时选项中从另一端接收的远程自动上次用户超时值。
L_LIMIT Current lower limit imposed on the user timeout of a connection by the local host.
L_LIMIT本地主机对用户连接超时施加的当前下限。
The RECOMMENDED formula results in the maximum of the two advertised values, adjusted for the configured upper and lower limits, to be adopted for the user timeout of the connection on both ends. The rationale is that choosing the maximum of the two values will let the connection survive longer periods without end-to-end connectivity. If the end that announced the lower of the two user timeout values did so in order to reduce the amount of TCP state information that must be kept on the host, it can close or abort the connection whenever it wants.
建议的公式得出两个公布值的最大值，根据配置的上限和下限进行调整，以用于两端连接的用户超时。其基本原理是，选择这两个值中的最大值将使连接能够在没有端到端连接的情况下存活更长的时间。如果宣布两个用户超时值中较低值的端这样做是为了减少主机上必须保留的TCP状态信息量，那么它可以随时关闭或中止连接。
It must be noted that the two endpoints of the connection will not necessarily adopt the same user timeout.
必须注意，连接的两个端点不一定采用相同的用户超时。
Enforcing a lower limit (L_LIMIT) prevents connections from closing due to transient network conditions, including temporary congestion, mobility hand-offs, and routing instabilities.
强制实施下限（L_limit）可防止连接因瞬态网络条件（包括临时拥塞、移动性切换和路由不稳定性）而关闭。
An upper limit (U_LIMIT) can reduce the effect of resource exhaustion attacks. Section 6 discusses the details of these attacks.
上限（U_limit）可以减少资源耗尽攻击的影响。第6节讨论了这些攻击的细节。
Note that these limits MAY be specified as system-wide constants or at other granularities, such as on per-host, per-user, per-outgoing-interface, or even per-connection basis. Furthermore, these limits need not be static. For example, they MAY be a function of system resource utilization or attack status and could be dynamically adapted.
请注意，这些限制可以指定为系统范围的常量，也可以指定为其他粒度，例如每主机、每用户、每输出接口，甚至每连接。此外，这些限制不必是静态的。例如，它们可能是系统资源利用率或攻击状态的函数，并且可以动态调整。
The Host Requirements RFC [RFC1122] does not impose any limits on the length of the user timeout. However, it recommends a time interval of at least 100 seconds. Consequently, the lower limit (L_LIMIT) SHOULD be set to at least 100 seconds when following the RECOMMENDED scheme described in this section. Adopting a user timeout smaller than the current retransmission timeout (RTO) for the connection would likely cause the connection to be aborted unnecessarily. Therefore, the lower limit (L_LIMIT) MUST be larger than the current
主机要求RFC[RFC1122]对用户超时的长度没有任何限制。但是，建议时间间隔至少为100秒。因此，当遵循本节所述的推荐方案时，下限（L_限制）应设置为至少100秒。为连接采用小于当前重传超时（RTO）的用户超时可能会导致不必要地中止连接。因此，下限（L_limit）必须大于当前值
retransmission timeout (RTO) for the connection. It is worth noting that an upper limit may be imposed on the RTO, provided it is at least 60 seconds [RFC2988].
连接的重新传输超时（RTO）。值得注意的是，可以对RTO施加上限，前提是至少60秒[RFC2988]。
The TCP User Timeout Option is an advisory TCP option that does not change processing of subsequent segments. Unlike other TCP options, it need not be exchanged reliably. Consequently, the specification does not define a reliability handshake for UTO option exchanges. When a segment that carries a UTO option is lost, the other end will simply not have the opportunity to update its local USER TIMEOUT.
TCP用户超时选项是一个建议性TCP选项，不会更改后续段的处理。与其他TCP选项不同，它不需要可靠地交换。因此，本规范未定义UTO期权交换的可靠性握手。当带有UTO选项的段丢失时，另一端将根本没有机会更新其本地用户超时。
Implementations MAY implement local mechanisms to improve delivery reliability, such as retransmitting a UTO option when they retransmit a segment that originally carried it, or "attaching" the option to a byte in the stream and retransmitting the option whenever that byte or its ACK are retransmitted.
实现可以实现本地机制以提高交付可靠性，例如当它们重新传输最初携带UTO选项的段时，重新传输UTO选项，或者将该选项“附加”到流中的字节，并且每当该字节或其ACK被重新传输时，重新传输该选项。
It is important to note that although these mechanisms can improve transmission reliability for the UTO option, they do not guarantee delivery (a three-way handshake would be required for this). Consequently, implementations MUST NOT assume that UTO options are transmitted reliably.
需要注意的是，尽管这些机制可以提高UTO选项的传输可靠性，但它们不能保证传输（这需要三方握手）。因此，实现不能假设UTO选项被可靠地传输。
Sending a TCP User Timeout Option informs the other end of the connection of the current local user timeout and suggests that the other end adapt its user timeout accordingly. The user timeout value included in a UTO option contains the ADV_UTO value that is expected to be adopted for the TCP's USER TIMEOUT parameter during the synchronized states of a connection (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, or LAST-ACK). Connections in other states MUST use the default timeout values defined in [RFC0793] and [RFC1122].
发送TCP用户超时选项将通知连接的另一端当前本地用户超时，并建议另一端相应地调整其用户超时。UTO选项中包含的用户超时值包含在连接的同步状态（已建立、FIN-WAIT-1、FIN-WAIT-2、CLOSE-WAIT、CLOSE或LAST-ACK）期间TCP的用户超时参数预期采用的ADV_UTO值。其他状态下的连接必须使用[RFC0793]和[RFC1122]中定义的默认超时值。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind = 28 | Length = 4 |G| User Timeout |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind = 28 | Length = 4 |G| User Timeout |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(One tick mark represents one bit.)
（一个勾号代表一位。）
Figure 1: Format of the TCP User Timeout Option
图1:TCP用户超时选项的格式
Figure 1 shows the format of the TCP User Timeout Option. It contains these fields:
图1显示了TCP用户超时选项的格式。它包含以下字段：
Kind (8 bits) This MUST be 28, i.e., the TCP option number [RFC0793] that has been assigned by IANA (see Section 7).
种类（8位）这必须是28，即IANA分配的TCP选项号[RFC0793]（见第7节）。
Length (8 bits) Length of the TCP option in octets [RFC0793]; its value MUST be 4.
TCP选项的长度（8位），以八位字节为单位[RFC0793]；其值必须为4。
Granularity (1 bit) Granularity bit, indicating the granularity of the "User Timeout" field. When set (G = 1), the time interval in the "User Timeout" field MUST be interpreted as minutes. Otherwise (G = 0), the time interval in the "User Timeout" field MUST be interpreted as seconds.
粒度（1位）粒度位，指示“用户超时”字段的粒度。设置（G=1）时，“用户超时”字段中的时间间隔必须解释为分钟。否则（G=0），“用户超时”字段中的时间间隔必须解释为秒。
User Timeout (15 bits) Specifies the user timeout suggestion for this connection. It MUST be interpreted as a 15-bit unsigned integer. The granularity of the timeout (minutes or seconds) depends on the "G" field.
用户超时（15位）指定此连接的用户超时建议。它必须解释为15位无符号整数。超时的粒度（分钟或秒）取决于“G”字段。
A TCP User Timeout Option with a "User Timeout" field of zero and a "Granularity" bit of either minutes (1) or seconds (0) is reserved for future use. Current TCP implementations MUST NOT send it and MUST ignore it upon reception.
TCP用户超时选项的“用户超时”字段为零，“粒度”位为分钟（1）或秒（0），保留供将来使用。当前的TCP实现不能发送它，必须在接收时忽略它。
This section discusses interoperability issues related to introducing the TCP User Timeout Option.
本节讨论与引入TCP用户超时选项相关的互操作性问题。
A TCP implementation that does not support the TCP User Timeout Option MUST silently ignore it [RFC1122], thus ensuring interoperability. In a study of the effects of middleboxes on transport protocols, Medina et al. have shown that the vast majority of modern TCP stacks correctly handle unknown TCP options [MEDINA]. In this study, 3% of connections failed when an unknown TCP option appeared in the middle of a connection. Because the number of failures caused by unknown options is small and they are a result of incorrectly implemented TCP stacks that violate existing requirements to ignore unknown options, they do not warrant special measures. Thus, this document does not define a mechanism to negotiate support of the TCP User Timeout Option during the three-way handshake.
不支持TCP用户超时选项的TCP实现必须静默忽略它[RFC1122]，从而确保互操作性。在一项关于中间盒对传输协议影响的研究中，Medina等人表明，绝大多数现代TCP协议栈都能正确处理未知的TCP选项[Medina]。在这项研究中，当一个未知的TCP选项出现在连接的中间时，3%的连接失败。由于未知选项导致的故障数量很少，而且它们是由于错误实现的TCP堆栈违反了忽略未知选项的现有要求而导致的，因此不需要采取特殊措施。因此，本文档没有定义在三方握手期间协商支持TCP用户超时选项的机制。
Implementations may want to exchange UTO options on the very first data segments after the three-way handshake to determine if such a middlebox exists on the path. When segments carrying UTO options are persistently lost, an implementation should turn off the use of UTO for the connection. When the connection itself is reset, an implementation may be able to transparently re-establish another connection instance that does not use UTO before any application data has been successfully exchanged.
实现可能需要在三方握手后的第一个数据段上交换UTO选项，以确定路径上是否存在这样的中间盒。当带有UTO选项的段持续丢失时，实现应该关闭UTO对连接的使用。当连接本身被重置时，实现可能能够透明地重新建立另一个连接实例，该实例在任何应用程序数据成功交换之前不使用UTO。
Stateful firewalls usually time out connection state after a period of inactivity. If such a firewall exists along the path, it may close or abort connections regardless of the use of the TCP User Timeout Option. In the future, such firewalls may learn to parse the TCP User Timeout Option in unencrypted TCP segments and adapt connection state management accordingly.
有状态防火墙通常在一段时间不活动后超时连接状态。如果路径上存在这样的防火墙，则无论使用TCP用户超时选项，它都可能关闭或中止连接。将来，此类防火墙可能会学习在未加密的TCP段中解析TCP用户超时选项，并相应地调整连接状态管理。
Some TCP implementations, such as those in BSD systems, use a different abort policy for TCP keep-alives than for user data. Thus, the TCP keep-alive mechanism might abort a connection that would otherwise have survived the transient period without connectivity. Therefore, if a connection that enables keep-alives is also using the TCP User Timeout Option, then the keep-alive timer MUST be set to a value larger than that of the adopted USER TIMEOUT.
某些TCP实现（如BSD系统中的实现）对TCP保持有效性使用与用户数据不同的中止策略。因此，TCP保持活动机制可能会中止一个连接，否则该连接将在没有连接的情况下在过渡期内存活。因此，如果启用keep alives的连接也使用TCP用户超时选项，则keep alive计时器必须设置为大于所采用的用户超时的值。
The IETF specification for TCP [RFC0793] includes a simple, abstract application programming interface (API). Similarly, the API for the UTO extension in Section 3 is kept abstract. TCP implementations, however, usually provide more complex and feature-rich APIs. The "socket" API that originated with BSD Unix and is now standardized by POSIX is one such example [POSIX]. It is expected that TCP implementations that choose to include the UTO extension will extend their API to allow applications to use and configure its parameters.
IETF TCP规范[RFC0793]包括一个简单、抽象的应用程序编程接口（API）。同样，第3节中UTO扩展的API也是抽象的。然而，TCP实现通常提供更复杂、功能更丰富的API。源于BSD Unix并由POSIX标准化的“套接字”API就是这样一个例子[POSIX]。预计选择包含UTO扩展的TCP实现将扩展其API，以允许应用程序使用和配置其参数。
The MIB objects defined in [RFC4022] and [RFC4898] allow management of TCP connections. It is expected that revisions to these documents will include definitions of objects for managing the UTO extension defined in this document.
[RFC4022]和[RFC4898]中定义的MIB对象允许管理TCP连接。预计这些文件的修订版将包括管理本文件中定义的UTO扩展的对象定义。
Lengthening user timeouts has obvious security implications. Flooding attacks cause denial of service by forcing servers to commit resources for maintaining the state of throw-away connections. However, TCP implementations do not become more vulnerable to simple
延长用户超时时间具有明显的安全影响。洪泛攻击通过强制服务器提交资源以维持丢弃连接的状态而导致拒绝服务。但是，TCP实现不会变得更容易受到简单攻击
SYN flooding by implementing the TCP User Timeout Option, because user timeouts exchanged during the handshake only affect the synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK), which simple SYN floods never reach.
通过实现TCP用户超时选项实现SYN泛洪，因为在握手过程中交换的用户超时只会影响同步状态（已建立、FIN-WAIT-1、FIN-WAIT-2、CLOSE-WAIT、CLOSE、LAST-ACK），而简单的SYN泛洪永远达不到这些状态。
However, when an attacker completes the three-way handshakes of its throw-away connections, it can amplify the effects of resource exhaustion attacks because the attacked server must maintain the connection state associated with the throw-away connections for longer durations. Because connection state is kept longer, lower-frequency attack traffic, which may be more difficult to detect, can already exacerbate resource exhaustion.
但是，当攻击者完成其丢弃连接的三方握手时，会放大资源耗尽攻击的影响，因为受攻击的服务器必须在更长的时间内保持与丢弃连接相关的连接状态。由于连接状态保持的时间更长，较低频率的攻击流量（可能更难检测）可能已经加剧了资源消耗。
Several approaches can help mitigate this issue. First, implementations can require prior peer authentication, e.g., using IPsec [RFC4301] or TCP-MD5 [RFC2385], before accepting long user timeouts for the peer's connections. (Implementors that decide to use TCP-MD5 for this purpose are encouraged to monitor the development of TCP-AO [AUTH_OPT], its designated successor, and update their implementation when it is published as an RFC.) A similar approach is for a host to start accepting long user timeouts for an established connection only after in-band authentication has occurred, for example, after a TLS handshake across the connection has succeeded [RFC5246]. Although these are arguably the most complete solutions, they depend on external mechanisms to establish a trust relationship.
有几种方法可以帮助缓解这个问题。首先，实现可能需要事先进行对等身份验证，例如使用IPsec[RFC4301]或TCP-MD5[RFC2385]，然后才能接受对等连接的长时间用户超时。（鼓励决定为此目的使用TCP-MD5的实施者监控TCP-AO[AUTH_OPT]及其指定继任者的开发，并在其作为RFC发布时更新其实现。）类似的方法是，主机仅在发生带内身份验证后（例如，在连接上的TLS握手成功后）才开始接受已建立连接的长时间用户超时[RFC5246]。尽管这些可以说是最完整的解决方案，但它们依赖于外部机制来建立信任关系。
A second alternative that does not depend on external mechanisms would introduce a per-peer limit on the number of connections that may use increased user timeouts. Several variants of this approach are possible, such as fixed limits or shortening accepted user timeouts with a rising number of connections. Although this alternative does not eliminate resource exhaustion attacks from a single peer, it can limit their effects. Reducing the number of high-UTO connections a server supports in the face of an attack turns that attack into a denial-of-service attack against the service of high-UTO connections.
第二种不依赖于外部机制的替代方案将对可能使用增加的用户超时的连接数引入每个对等点的限制。这种方法的几种变体是可能的，例如固定限制或随着连接数的增加缩短可接受的用户超时。尽管此替代方案不能消除来自单个对等方的资源耗尽攻击，但它可以限制其影响。面对攻击时，减少服务器支持的高UTO连接数会将该攻击转化为针对高UTO连接服务的拒绝服务攻击。
Per-peer limits cannot protect against distributed denial-of-service attacks, where multiple clients coordinate a resource exhaustion attack that uses long user timeouts. To protect against such attacks, TCP implementations could reduce the duration of accepted user timeouts with increasing resource utilization.
每对等限制无法抵御分布式拒绝服务攻击，在这种情况下，多个客户端协调使用长时间用户超时的资源耗尽攻击。为了防止此类攻击，TCP实现可以减少可接受的用户超时的持续时间，同时提高资源利用率。
TCP implementations under attack may be forced to shed load by resetting established connections. Some load-shedding heuristics, such as resetting connections with long idle times first, can negatively affect service for intermittently connected, trusted peers
受到攻击的TCP实现可能会通过重置已建立的连接而被迫卸载。一些减载启发式方法，例如首先重置长空闲时间的连接，可能会对间歇性连接的可信对等方的服务产生负面影响
that have suggested long user timeouts. On the other hand, resetting connections to untrusted peers that use long user timeouts may be effective. In general, using the peers' level of trust as a parameter during the load-shedding decision process may be useful. Note that if TCP needs to close or abort connections with a long TCP User Timeout Option to shed load, these connections are still no worse off than without the option.
这表明用户超时时间过长。另一方面，重置与使用长用户超时的不受信任对等方的连接可能是有效的。一般来说，在甩负荷决策过程中使用对等方的信任级别作为参数可能是有用的。请注意，如果TCP需要关闭或中止具有长TCP用户超时选项的连接以卸载，则这些连接的情况仍然不会比没有该选项的情况更糟。
Finally, upper and lower limits on user timeouts, discussed in Section 3.1, can be an effective tool to limit the impact of these sorts of attacks.
最后，第3.1节讨论的用户超时的上限和下限是限制此类攻击影响的有效工具。
This section is to be interpreted according to [RFC5226].
本节将根据[RFC5226]进行解释。
This document does not define any new namespaces. IANA has allocated a new 8-bit TCP option number (28) for the UTO option from the "TCP Option Kind Numbers" registry maintained at http://www.iana.org.
本文档不定义任何新名称空间。IANA已从维护于的“TCP选项种类号”注册表中为UTO选项分配了一个新的8位TCP选项号（28）http://www.iana.org.
The following people have improved this document through thoughtful suggestions: Mark Allman, Caitlin Bestler, David Borman, Bob Braden, Scott Brim, Marcus Brunner, Wesley Eddy, Gorry Fairhurst, Abolade Gbadegesin, Ted Faber, Guillermo Gont, Tom Henderson, Joseph Ishac, Jeremy Harris, Alfred Hoenes, Phil Karn, Michael Kerrisk, Dan Krejsa, Jamshid Mahdavi, Kostas Pentikousis, Juergen Quittek, Anantha Ramaiah, Joe Touch, Stefan Schmid, Simon Schuetz, Tim Shepard, and Martin Stiemerling.
以下人员通过深思熟虑的建议改进了本文件：马克·奥尔曼、凯特琳·贝斯勒、大卫·鲍曼、鲍勃·布拉登、斯科特·布里姆、马库斯·布伦纳、卫斯理·艾迪、戈里·费尔赫斯特、阿博拉德·巴德格辛、特德·费伯、吉列莫·冈特、汤姆·亨德森、约瑟夫·伊萨克、杰里米·哈里斯、阿尔弗雷德·霍恩斯、菲尔·卡恩、迈克尔·克里克斯和克雷萨，Jamshid Mahdavi、Kostas Pentikousis、Juergen Quitek、Anantha Ramaiah、Joe Touch、Stefan Schmid、Simon Schuetz、Tim Shepard和Martin Stiemering。
Lars Eggert is partly funded by [TRILOGY], a research project supported by the European Commission under its Seventh Framework Program.
拉尔斯·艾格特（Lars Eggert）的部分资金来自于[三部曲]，这是一个由欧盟委员会第七框架计划支持的研究项目。
Fernando Gont wishes to thank Secretaria de Extension Universitaria at Universidad Tecnologica Nacional and Universidad Tecnologica Nacional/Facultad Regional Haedo for supporting him in this work.
费尔南多·冈特感谢国家技术大学和国家技术大学/区域哈多学院的大学推广秘书处对他的支持。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]Braden，R.，“互联网主机的要求-通信层”，标准3，RFC 1122，1989年10月。
[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月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[AUTH_OPT] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", Work in Progress, November 2008.
[AUTH_OPT]Touch，J.，Mankin，A.，和R.Bonica，“TCP认证选项”，正在进行的工作，2008年11月。
[MEDINA] Medina, A., Allman, M., and S. Floyd, "Measuring Interactions Between Transport Protocols and Middleboxes", Proc. 4th ACM SIGCOMM/USENIX Conference on Internet Measurement, October 2004.
[MEDINA]MEDINA，A.，Allman，M.，和S.Floyd，“测量传输协议和中间盒之间的交互”，Proc。第四届ACM SIGCOMM/USENIX互联网测量会议，2004年10月。
[POSIX] IEEE Std. 1003.1-2001, "Standard for Information Technology - Portable Operating System Interface (POSIX)", Open Group Technical Standard: Base Specifications Issue 6, ISO/IEC 9945:2002, December 2001.
[POSIX]IEEE标准1003.1-2001，“信息技术标准-便携式操作系统接口（POSIX）”，开放组技术标准：基本规范第6版，ISO/IEC 9945:2002，2001年12月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385]Heffernan，A.，“通过TCP MD5签名选项保护BGP会话”，RFC 2385，1998年8月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[RFC2988]Paxson，V.和M.Allman，“计算TCP的重传计时器”，RFC 2988，2000年11月。
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344]Perkins，C.，“IPv4的IP移动支持”，RFC 3344，2002年8月。
[RFC4022] Raghunarayan, R., "Management Information Base for the Transmission Control Protocol (TCP)", RFC 4022, March 2005.
[RFC4022]Raghunarayan，R.，“传输控制协议（TCP）的管理信息库”，RFC 40222，2005年3月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006.
[RFC4423]Moskowitz，R.和P.Nikander，“主机身份协议（HIP）体系结构”，RFC 4423，2006年5月。
[RFC4898] Mathis, M., Heffner, J., and R. Raghunarayan, "TCP Extended Statistics MIB", RFC 4898, May 2007.
[RFC4898]Mathis，M.，Heffner，J.和R.Raghunarayan，“TCP扩展统计MIB”，RFC 4898，2007年5月。
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, August 2007.
[RFC4987]Eddy，W.“TCP SYN洪泛攻击和常见缓解措施”，RFC 4987，2007年8月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[SOLARIS] Sun Microsystems, "Solaris Tunable Parameters Reference Manual", Part No. 806-7009-10, 2002.
[SOLARIS]Sun Microsystems，“SOLARIS可调参数参考手册”，零件号806-7009-102002。
[TCP_MOB] Eddy, W., "Mobility Support For TCP", Work in Progress, April 2004.
[TCP_MOB]Eddy，W.，“TCP的移动性支持”，正在进行的工作，2004年4月。
[TRILOGY] "Trilogy Project", <http://www.trilogy-project.org/>.
[三部曲]“三部曲项目”<http://www.trilogy-project.org/>.
Authors' Addresses
作者地址
Lars Eggert Nokia Research Center P.O. Box 407 Nokia Group 00045 Finland
芬兰诺基亚集团00045诺基亚研究中心邮政信箱407
Phone: +358 50 48 24461
EMail: lars.eggert@nokia.com
URI: http://research.nokia.com/people/lars_eggert/
Phone: +358 50 48 24461
EMail: lars.eggert@nokia.com
URI: http://research.nokia.com/people/lars_eggert/
Fernando Gont Universidad Tecnologica Nacional / Facultad Regional Haedo Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina
阿根廷布宜诺斯艾利斯省费尔南多·冈特国家技术大学/学院地区哈多·埃瓦里斯托·卡里戈2644哈多1706
Phone: +54 11 4650 8472
EMail: fernando@gont.com.ar
URI: http://www.gont.com.ar/
Phone: +54 11 4650 8472
EMail: fernando@gont.com.ar
URI: http://www.gont.com.ar/