RFC6298
摘要
本文档定义了传输控制协议（TCP）发送方用于计算和管理其重传计时器的标准算法。它扩展了 RFC1122 第4.2.3.1节中的讨论，并将支持算法的要求从“应该”升级为“必须”。本文件淘汰了 RFC 2988。
此 Memo 的状态
这是一个互联网标准跟踪文件。
本文档是Internet工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经收到了公众的审查，并已批准出版的互联网工程指导小组（IESG）。有关互联网标准的更多信息，请参阅RFC 5741第2节。
有关本文件的当前状态、任何勘误表以及如何提供反馈的信息，请访问 http://www.rfc-editor.org/info/rfc6298.
1. 介绍
传输控制协议（TCP）[Pos81]使用重传定时器来确保在没有来自远程数据接收器的任何反馈的情况下进行数据传送。此计时器的持续时间称为RTO（重传超时）。RFC 1122[Bra89]规定RTO应按照[Jac88]中所述进行计算。
本文档对设置RTO的算法进行了编码。此外，本文件扩展了RFC 1122第4.2.3.1节中的讨论，并将支持算法的要求从“应该”升级为“必须”。RFC5681[APB09]概述了TCP在RTO过期并发送重传后开始发送的算法。本文件不改变RFC 5681[APB09]中概述的行为。
在某些情况下，TCP发送方比本文中详细介绍的算法更保守可能是有益的。但是，TCP不能比下列算法允许的攻击性更强。本文件淘汰RFC 2988[PA00]。
本文件中的关键词“必须”、“不得”、“必须”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[Bra97]中的描述进行解释。
2. 基本算法（The Basic Algorithm）
为了计算当前的 RTO ，TCP发送器维护两个状态变量 SRTT（平滑往返时间）和 RTTVAR （往返时间变化）。此外，我们假设时钟粒度为G秒。
SRTT , RTTVAR , 和 RTO 的计算规则如下：
-
在对发送方和接收方之间发送的 segment 进行往返时间（RTT）测量之前，发送方应设置 RTO < -1秒 ，尽管（5.5）中讨论的重复重传的“后退”仍然适用。
请注意，本文档的早期版本使用了 **3秒的初始 RTO ** [PA00]。TCP实现仍然可以使用此值（或任何其他大于1秒的值）。初始 RTO 下限的这种变化将在附录A中进一步详细讨论。
-
当第一次测量到 RTT 的值 R 时，主机必须进行以下初始化：
- 其中
-
之后每测量到一个 RTT 值 ，主机必须进行以下更新：
[JK88]中建议应使用α=1/8和β=1/4（如图所示）计算上述值
-
每当计算得到一个 RTO 时，如果小于1秒，则 RTO 应该四舍五入到1秒。
传统上，TCP实现使用粗粒度时钟测量RTT并触发RTO，这会产生较大的最小 RTO 值。研究表明为了保证TCP的保守性和避免误码，需要最小的 RTO 来避免伪重传[AP99]。因此，本规范作为一种保守的方法，需要设置一个较大的最小 RTO 。研究表明，在未来的场景中，使用较小的最小 RTO 是可以接受的，甚至是更好的。
RTO 上的最大值至少为60秒。
3. 采集 RTT 样本
TCP必须使用Karn算法[KP87]来获取RTT样本。也就是说，RTT样本不能使用重新传输的 segment（因为对于该 segment 而言，应答是针对包的第一个实例还是稍后的实例是不明确的）。TCP可以安全地从重传的 segment 中获取RTT样本的唯一情况是使用TCP时间戳选项[JBB92]，因为时间戳选项消除了关于哪个数据段实例触发了确认的模糊性。
传统上，TCP实现一次测量一个RTT（通常，每个RTT测量一次）。但是，当使用timestamp选项时，每个ACK都可以用作RTT样本。RFC 1323[JBB92]建议，利用大拥塞窗口的TCP连接应该对每个数据窗口进行许多RTT采样，以避免估计的RTT中的混叠效应。一个TCP实现必须对每个RTT至少进行一次RTT测量。
对于相当适度的拥塞窗口大小，研究表明，对每一段进行定时并不能产生更好的RTT估计器[AP99]。此外，当每个RTT采集多个样本时，第2节中定义的 和 可能会保留不充分的RTT历史。改变这些常数的方法目前是一个开放的研究问题。
4. 时钟粒度
不需要将时钟粒度 G 用于计算 RTT 测量值和不同状态变量。然而，如果 RTO 计算中的 k * RTTVAR 项等于零，方差项必须四舍五入到 G 秒(即，使用步骤2.3中给出的方程)。
经验表明，较细的时钟粒度（<=100毫秒）比较粗的粒度性能要好一些。注意，[Jac88]概述了几个巧妙的技巧，这些技巧可以用来从粗粒度计时器获得更好的精度。这些变化在当前的TCP实现中得到了广泛的实现。
5. 管理RTO计时器
一个具体的实现必须以这样的方式管理重传计时器，在一个 RTO 内同一个 segment 最多只能被传输一次。以下是管理重传计时器的推荐算法：
- 每次发送包含数据的 segment（包括重传）时，如果计时器未运行，则启动计时器，使其在 RTO 秒后过期（使用 RTO 的当前值）；
- 确认所有未完成的数据后，关闭重传计时器；
- 当接收到确认新数据的ACK时，重新启动重传计时器，使其在 RTO 秒后过期（使用 RTO 的当前值）。
重传计时器过期时，请执行以下操作：
- 重传已发出未确认的序列号最小的包；
- 主机必须设置 (同时停止计时器)，上面(2.5)中讨论的最大值可用于提供这种倍增操作的上界；
- 启动重传计时器，使其在 RTO 秒后过期（使用上一步所述加倍操作后的 RTO 值）；
- 如果等待SYN段的ACK的计时器过期，并且TCP实现使用的RTO少于3秒，则必须在数据传输开始时（即，在三方握手完成之后）将RTO重新初始化为3秒。
请注意，在重传后，一旦获得新的 RTT 测量值（仅在发送和确认新数据时发生），将执行第2节中概述的计算，包括RTO的计算，这可能导致RTO在经历指数倍增后又退避回来（规则5.5）。
注意，TCP实现可能在多次退出计时器后清除SRTT和RTTVAR，因为在这种情况下，当前SRTT和RTTVAR很可能是假的。一旦SRTT和RTTVAR被清除，就应该使用根据（2.2）而不是使用（2.3）获取的下一个RTT样本来初始化它们。
6. 安全考虑
此文档要求TCP在重传未确认的 segment 之前等待给定的时间间隔。攻击者可以通过向定时数据包的延迟或其确认延迟中添加延迟，使TCP发送方计算出较大的RTO值。但是，向数据包的延迟添加延迟的能力通常与导致数据包丢失的能力相一致，因此很难看出攻击者可能从这种攻击中获得什么，这种攻击可能会造成比丢弃一些TCP连接数据包更大的损害。
因特网在很大程度上依赖于RTO算法的正确实现（以及rfc5681中描述的那些），以保持网络的稳定性和避免拥塞崩溃。攻击者可以在接收端实际收到数据之前伪造对数据段的确认，从而使TCP端点在遇到拥塞时做出更积极的响应，从而将RTO降低到不安全的值。但要做到这一点，需要正确地欺骗确认，除非攻击者能够监视发送方和接收方之间路径上的通信量，否则这是很困难的。此外，即使攻击者可以使发送方的RTO达到一个太小的值，看起来攻击者也无法利用这个值进行攻击（相比之下，如果他们可以欺骗属于连接的数据包，他们可以造成的其他损害），因为发送TCP仍然会在由于实际拥塞而导致错误传输的数据包丢失的情况下退出其计时器。
RFC 5681[APB09]中的安全注意事项也适用于本文档。