4.1. 独立的包编号 空间

QUIC 为每个加密级别使用独立的包编号空间， 但 0-RTT 以及所有代的 1-RTT 密钥使用相同的包 编号空间。独立的包编号空间确保 使用某个加密级别发送的包的确认不会 导致使用另一个加密级别发送的包发生伪 重传。拥塞控制和往返时间 (RTT) 测量在各个包编号空间之间是统一的。¶

4.2. 单调递增的 包编号

TCP 将发送方的传输顺序与接收方的交付顺序混为一谈， 从而产生重传歧义问题 [RETRANSMISSION]。QUIC 将 传输顺序与交付顺序分离： 包编号指示传输顺序，而交付顺序由 STREAM 帧中的 流偏移确定。¶

QUIC 的包编号在包编号空间内严格递增， 并直接编码传输顺序。更高的包编号表示 该包发送得更晚，更低的包编号表示 该包发送得更早。当检测到包含诱发 ACK 帧的包丢失时，QUIC 会将必要的帧包含在一个具有 新包编号的新包中，从而消除在收到 ACK 时哪个包被 确认的歧义。因此，可以进行更准确的 RTT 测量，可以轻易检测到伪重传，并且 快速重传等机制可以仅基于 包编号而普遍应用。¶

这一设计点显著简化了 QUIC 的丢包检测机制。 大多数 TCP 机制会隐式地尝试基于 TCP 序列号推断传输顺序——这是一项并不简单的任务， 尤其是在 TCP 时间戳不可用时。¶

4.3. 更清晰的丢包时期

QUIC 在包丢失时开始一个丢包时期。当该时期开始后发送的任何 包得到确认时，该丢包时期结束。TCP 会等待序列号空间中的空缺 被填补，因此如果一个段连续多次丢失， 丢包时期可能在几个往返时间内都不会结束。由于二者都应当 每个时期只降低一次拥塞窗口，因此 QUIC 会对每个经历丢包的 往返时间降低一次，而 TCP 可能只会在多个 往返时间内降低一次。¶

4.4. 不撤销确认

QUIC ACK 帧包含的信息类似于 TCP 选择性 确认 (SACK) [RFC2018] 中的信息。不过， QUIC 不允许撤销包的 确认，这大大简化了双方的实现， 并降低了发送方的内存压力。¶

4.5. 更多 ACK 范围

QUIC 支持许多 ACK 范围，而 TCP 只有三个 SACK 范围。在 高丢包环境中，这会加快恢复、减少伪重传，并 确保无需依赖超时即可取得前进进展。¶

4.6. 对延迟确认的显式校正

QUIC 端点会测量从接收包到 发送相应确认之间产生的延迟，从而允许对端维护 更准确的 RTT 估计；见 [QUIC-TRANSPORT] 的 第 13.2 节。¶

4.7. 探测超时代替 RTO 和 TLP

QUIC 使用探测超时（PTO；见第 6.2 节），其定时器基于 TCP 的 重传超时 (RTO) 计算；见 [RFC6298]。QUIC 的 PTO 包含 对端的最大预期确认延迟，而不是使用固定的 最小超时。¶

与 TCP 的 RACK-TLP 丢包检测算法 [RFC8985] 类似，QUIC 不会 在 PTO 过期时收缩拥塞窗口，因为尾部的单个包 丢失并不表示持续拥塞。相反，QUIC 会在声明持续拥塞时收缩拥塞窗口；见 第 7.6 节。这样做时，QUIC 避免了 不必要的拥塞 窗口降低，也消除了对 Forward RTO-Recovery (F-RTO) [RFC5682] 等校正机制的需要。由于 QUIC 不会 在 PTO 过期时收缩拥塞 窗口，如果在 PTO 过期后仍有可用的拥塞 窗口，QUIC 发送方就不受限制，仍可发送更多 传输中的包。当发送方受应用限制且 PTO 定时器 过期时，就会发生这种情况。与 TCP 的 RTO 机制相比，这在受应用 限制时更激进，但在不受应用限制时相同。¶

每当定时器过期时，QUIC 都允许探测包临时超过拥塞窗口。¶

4.8. 最小拥塞 窗口为两个包

TCP 使用一个包作为最小拥塞窗口。然而，该 单个包的丢失意味着发送方需要等待 PTO 才能恢复（第 6.2 节），这 可能比一个 RTT 长得多。发送单个诱发 ACK 的包也 会增加接收方延迟其 确认时产生额外时延的概率。¶

因此，QUIC 建议最小拥塞窗口为两个 包。虽然这会增加网络负载，但它被认为是安全的，因为 发送方在持续拥塞下仍会以指数方式降低其发送 速率（第 6.2 节）。¶

4.9. 握手包并非 特殊

TCP 将 SYN 或 SYN-ACK 包的丢失视为持续拥塞， 并将拥塞窗口降低到一个包；见 [RFC5681]。QUIC 将 包含握手数据的包的丢失与其他丢包同等处理。¶

5.1. 生成 RTT 样本

端点在收到满足以下两个条件的 ACK 帧时生成 RTT 样本：¶

• 最大的已确认包编号是新近 确认的，并且¶
• 新近确认的包中至少有一个是 诱发 ACK 的。¶

RTT 样本 latest_rtt 生成为自最大 已确认包发送以来经过的时间：¶

latest_rtt = ack_time - send_time_of_largest_acked

RTT 样本只使用接收到的 ACK 帧中的 最大已确认包生成。这是因为对端只会为 ACK 帧中的最大已确认包报告确认延迟。虽然报告的 确认延迟不会用于 RTT 样本测量，但它会用于 在后续 smoothed_rtt 和 rttvar 计算中调整 RTT 样本（第 5.3 节）。¶

为避免为单个包生成多个 RTT 样本，如果 ACK 帧没有新近 确认最大的已确认包，则SHOULD NOT 使用该 ACK 帧更新 RTT 估计。¶

在收到未新近确认至少一个诱发 ACK 包的 ACK 帧时，MUST NOT 生成 RTT 样本。对端通常不会 在只收到非诱发 ACK 的包时发送 ACK 帧。因此， 只包含非诱发 ACK 包确认的 ACK 帧 可能包含任意大的 ACK Delay 值。忽略 这样的 ACK 帧可以避免后续 smoothed_rtt 和 rttvar 计算中的复杂性。¶

当一个 RTT 内收到多个 ACK 帧时，发送方可能会在每个 RTT 中 生成多个 RTT 样本。如 [RFC6298] 所建议，这样做可能会导致 smoothed_rtt 和 rttvar 中的历史不足。确保 RTT 估计 保留足够历史仍是一个开放研究问题。¶

5.2. 估算 min_rtt

min_rtt 是发送方对给定网络 路径在一段时间内观测到的最小 RTT 的估计。在本文档中，min_rtt 由丢包检测 用来拒绝不合理地小的 RTT 样本。¶

在第一个 RTT 样本上，min_rtt MUST 设置为 latest_rtt。在所有其他 样本上，min_rtt MUST 设置为 min_rtt 和 latest_rtt（第 5.1 节）中的较小者。¶

端点在计算 min_rtt 时仅使用本地观测到的时间， 并且不会根据对端报告的确认延迟进行调整。这样做允许 端点完全基于自身观测为 smoothed_rtt 设置下界 （见 第 5.3 节），并限制 对端错误报告延迟造成的潜在低估。¶

网络路径的 RTT 可能会随时间变化。如果路径的实际 RTT 降低，min_rtt 会在第一个较低样本上立即适应。如果 路径的实际 RTT 增加，min_rtt 则不会适应它，从而允许 小于新 RTT 的未来 RTT 样本被纳入 smoothed_rtt。¶

端点在确定持续 拥塞后，SHOULD 将 min_rtt 设置为最新的 RTT 样本。 这避免在 RTT 增加时反复声明持续 拥塞。这也允许连接在发生破坏性网络事件后 重置其 min_rtt 和 smoothed_rtt 的估计； 见 第 5.3 节。¶

端点 MAY 在连接中的其他 时间重新建立 min_rtt，例如 当流量较低且收到确认延迟较低的确认时。 实现 SHOULD NOT 过于频繁地刷新 min_rtt 值，因为路径的实际最小 RTT 并不 经常可观测到。¶

5.3. 估算 smoothed_rtt 和 rttvar

smoothed_rtt 是端点 RTT 样本的指数加权移动平均值，而 rttvar 使用平均 变动来估算 RTT 样本中的变动。¶

smoothed_rtt 的计算使用根据 确认延迟调整后的 RTT 样本。这些延迟按 [QUIC-TRANSPORT] 的 第 19.3 节所述，从 ACK 帧的 ACK Delay 字段中解码。¶

对端在握手期间可能会报告大于其 max_ack_delay 的确认延迟（[QUIC-TRANSPORT] 的 第 13.2.1 节）。为 处理这种情况，端点在握手 确认之前，SHOULD 忽略 max_ack_delay，握手确认的定义见 [QUIC-TLS] 的 第 4.1.2 节。 当这些较大的确认延迟出现时，它们很可能不会重复，并且局限于 握手。因此，端点可以在不将它们限制到 max_ack_delay 的情况下使用它们，从而避免不必要地抬高 RTT 估计。¶

请注意，如果对端报告确认延迟出错，或者 端点的 min_rtt 估计出错，则较大的确认延迟可能导致 smoothed_rtt 被显著抬高。因此，在 握手确认之前，如果按确认延迟调整 RTT 样本会导致该样本小于 min_rtt，端点 MAY 忽略该 RTT 样本。¶

握手确认后，对端报告的任何 大于其 max_ack_delay 的确认延迟，都会归因于 无意但可能重复发生的延迟，例如对端的调度器时延 或先前确认的丢失。过量延迟也可能源于 不合规的接收方。因此，这些额外延迟实际上被视为 路径延迟的一部分，并纳入 RTT 估计。¶

因此，当使用对端报告的确认 延迟调整 RTT 样本时，端点：¶

• 对 Initial 包 MAY 忽略确认延迟，因为 这些 确认不会被对端延迟（[QUIC-TRANSPORT] 的 第 13.2.1 节）；¶
• 在握手确认之前，SHOULD 忽略对端的 max_ack_delay；¶
• 握手确认后，MUST 使用确认延迟和对端 max_ack_delay 中的较小者；并且¶
• 如果结果值小于 min_rtt，则 MUST NOT 从 RTT 样本中减去确认延迟。这限制了 由于对端误报而导致的 smoothed_rtt 低估。¶

此外，当相应的解密密钥不能立即使用时， 端点可能会推迟处理确认。例如，客户端可能会 收到对 0-RTT 包的确认，但由于 1-RTT 包保护密钥 尚不可用而无法解密。在 这种情况下，端点在握手确认之前，SHOULD 从其 RTT 样本中减去这类本地延迟。¶

与 [RFC6298] 类似， smoothed_rtt 和 rttvar 按如下方式计算。¶

端点在连接建立期间以及连接迁移时重置估计器时 初始化 RTT 估计器；见 [QUIC-TRANSPORT] 的 第 9.4 节。 在新路径上尚无任何 RTT 样本可用之前，或当 估计器被重置时，估计器使用初始 RTT 进行初始化；见 第 6.2.2 节。¶

smoothed_rtt 和 rttvar 按如下方式初始化，其中 kInitialRtt 包含 初始 RTT 值：¶

smoothed_rtt = kInitialRtt
rttvar = kInitialRtt / 2

网络路径的 RTT 样本记录在 latest_rtt 中；见 第 5.1 节。在初始化后的第一个 RTT 样本上， 估计器使用该样本重置。这确保估计器不保留 过去样本的历史。如 [QUIC-TRANSPORT] 的 第 9.4 节所述，在其他路径上发送的包不会向 当前路径贡献 RTT 样本。¶

在初始化后的第一个 RTT 样本上，smoothed_rtt 和 rttvar 设置 如下：¶

smoothed_rtt = latest_rtt
rttvar = latest_rtt / 2

在后续 RTT 样本上，smoothed_rtt 和 rttvar 按如下方式演化：¶

ack_delay = decoded acknowledgment delay from ACK frame
if (handshake confirmed):
  ack_delay = min(ack_delay, max_ack_delay)
adjusted_rtt = latest_rtt
if (latest_rtt >= min_rtt + ack_delay):
  adjusted_rtt = latest_rtt - ack_delay
smoothed_rtt = 7/8 * smoothed_rtt + 1/8 * adjusted_rtt
rttvar_sample = abs(smoothed_rtt - adjusted_rtt)
rttvar = 3/4 * rttvar + 1/4 * rttvar_sample

6.1. 基于确认的 检测

基于确认的丢包检测体现了 TCP 的快速 重传 [RFC5681]、早期重传 [RFC5827]、转发确认 [FACK]、SACK 丢包恢复 [RFC6675] 以及 RACK-TLP [RFC8985] 等算法的精神。本 节概述这些算法如何在 QUIC 中实现。¶

如果一个包满足以下所有条件，则会被声明为丢失：¶

• 该包未被确认，处于传输中，并且发送时间早于一个 已确认的包。¶
• 该包比一个已确认包早发送 kPacketThreshold 个包 （第 6.1.1 节），或者它已经发送了足够长的 时间 （第 6.1.2 节）。¶

确认表明一个较晚发送的包已被交付，而 包阈值和时间阈值为包重排序提供了一定容忍度。¶

错误地将包声明为丢失会导致不必要的重传， 并且可能因拥塞控制器在检测到丢包时采取的动作而导致性能 下降。实现可以检测伪重传， 并增加包重排序阈值或时间重排序阈值，以 减少未来的伪重传和丢包事件。具有 自适应时间阈值的实现 MAY 选择从较小的初始重排序 阈值开始，以最小化恢复时延。¶

max(kTimeThreshold * max(smoothed_rtt, latest_rtt), kGranularity)

6.2. 探测超时

当诱发 ACK 的包没有在预期时间段内被 确认，或者服务器可能尚未验证客户端地址时， 探测超时 (PTO) 会触发发送一个或两个探测数据报。PTO 使 连接能够从尾部包或确认的丢失中恢复。¶

与丢包检测一样，PTO 按包编号空间分别进行。也就是说， PTO 值按每个包编号空间计算。¶

PTO 定时器过期事件并不表示包丢失，并且MUST NOT 导致 先前未确认的包被标记为丢失。当收到新近确认包的 确认时，丢包检测会按包阈值和时间阈值机制 所规定的方式进行；见 第 6.1 节。¶

QUIC 中使用的 PTO 算法实现了 TCP 的 Tail Loss Probe [RFC8985]、RTO [RFC5681] 和 F-RTO 算法的可靠性功能 [RFC5682]。超时计算基于 TCP 的 RTO 周期 [RFC6298]。¶

PTO = smoothed_rtt + max(4*rttvar, kGranularity) + max_ack_delay

6.3. 处理 Retry 包

Retry 包会导致客户端发送另一个 Initial 包，实际上 重新启动连接过程。Retry 包表示 Initial 包已被接收但未被处理。Retry 包不能被视为 确认，因为它并不表示包已被处理，也没有 指定包编号。¶

收到 Retry 包的客户端会重置拥塞控制和丢包恢复 状态，包括重置任何待处理的定时器。其他连接状态， 特别是加密握手消息，会被保留；见 [QUIC-TRANSPORT] 的 第 17.2.5 节。¶

客户端 MAY 将从发送第一个 Initial 包到收到 Retry 或 Version Negotiation 包之间的时间段计算为到服务器的 RTT 估计。客户端 MAY 使用此值替代其 默认的初始 RTT 估计。¶

6.4. 丢弃密钥和 包状态

当 Initial 和 Handshake 包保护密钥被丢弃 （见 [QUIC-TLS] 的 第 4.9 节）时，所有使用这些密钥 发送的包都无法再被确认，因为其确认无法被处理。 发送方 MUST 丢弃与这些包关联的所有恢复状态， 并且 MUST 将它们从传输中字节数中移除。¶

一旦端点开始交换 Handshake 包，它们就停止发送和接收 Initial 包；见 [QUIC-TRANSPORT] 的 第 17.2.2.1 节。此时， 所有传输中 Initial 包的恢复状态都会被丢弃。¶

当 0-RTT 被拒绝时，所有传输中 0-RTT 包的恢复状态都会 被丢弃。¶

如果服务器接受 0-RTT，但不缓冲在 Initial 包之前到达的 0-RTT 包，则早期 0-RTT 包会被声明为丢失，但这种情况 预计很少发生。¶

预期密钥会在某个时间点被丢弃，即使用这些密钥 加密的包要么已被确认，要么已被声明为丢失之后。然而， 一旦证明客户端和服务器都可使用 Handshake 和 1-RTT 密钥，Initial 和 Handshake 秘密就会立即被丢弃；见 [QUIC-TLS] 的 第 4.9.1 节。¶

7.1. 显式拥塞 通知

如果某条路径已被验证支持显式拥塞通知 (ECN) [RFC3168] [RFC8311]，QUIC 会将 IP 头部中的 Congestion Experienced (CE) 码点 视为拥塞信号。本文档指定了 当对端报告的 ECN-CE 计数增加时端点的响应；见 [QUIC-TRANSPORT] 的 第 13.4.2 节。¶

7.2. 初始和最小 拥塞窗口

QUIC 的每个连接都从慢启动开始，拥塞窗口设置为一个 初始值。端点 SHOULD 使用十倍于 最大数据报大小 (max_datagram_size) 的初始拥塞窗口，同时将窗口限制为 14,720 字节或两倍最大数据报大小中的较大值。这遵循 [RFC6928] 中的分析和建议， 增加字节限制是为了 计入 UDP 相较于 TCP 的 20 字节开销而言更小的 8 字节开销。¶

如果最大数据报大小在连接期间发生变化，则初始 拥塞窗口 SHOULD 使用新的大小重新计算。如果为了完成握手而 减小最大 数据报大小，则拥塞窗口 SHOULD 设置为新的初始拥塞 窗口。¶

在验证客户端地址之前，服务器还可能受到 [QUIC-TRANSPORT] 的 第 8.1 节 所指定的反放大限制的进一步限制。 虽然反放大限制可能阻止拥塞窗口 被充分利用，从而减慢拥塞窗口的增长， 但它不会直接影响拥塞窗口。¶

最小拥塞窗口是拥塞窗口在响应丢包、 对端报告的 ECN-CE 计数增加， 或持续拥塞时可以达到的最小值。RECOMMENDED 值为 2 * max_datagram_size。¶

7.3. 拥塞控制 状态

本文档描述的 NewReno 拥塞控制器具有三个 不同的状态，如图 1所示。¶

                新路径或          +------------+
            持续拥塞              |   慢       |
        (O)---------------------->|   启动     |
                                  +------------+
                                        |
                                丢包或 |
                        ECN-CE 增加    |
                                        v
 +------------+     丢包或       +------------+
 | 拥塞       |  ECN-CE 增加     |  恢复      |
 | 避免       |------------------>|  时期      |
 +------------+                   +------------+
           ^                            |
           |                            |
           +----------------------------+
              对恢复期间发送的包的确认

这些状态及其之间的转换将在后续 小节中描述。¶

7.4. 忽略无法解密包的 丢失

在握手期间，某些包保护密钥在包到达时可能尚不可用， 接收方可以选择丢弃该包。特别是， Handshake 和 0-RTT 包在 Initial 包 到达之前无法处理，1-RTT 包在握手完成之前无法处理。 端点 MAY 忽略可能 在对端拥有处理这些包所需的包保护密钥之前到达的 Handshake、0-RTT 和 1-RTT 包的丢失。 端点 MUST NOT 忽略在给定包编号空间中 最早已确认包之后发送的包的丢失。¶

7.5. 探测超时

探测包 MUST NOT 被拥塞 控制器阻塞。不过，发送方 MUST 将这些包计为额外处于传输中，因为这些包 会增加网络负载，却不建立包丢失。请注意，发送探测 包可能会导致发送方的传输中字节数超过拥塞窗口， 直到收到能够确定包丢失或交付的 确认。¶

7.6. 持续拥塞

当发送方确定在足够长的 持续时间内发送的所有包都丢失时， 网络被认为正在经历持续拥塞。¶

(smoothed_rtt + max(4*rttvar, kGranularity) + max_ack_delay) *
    kPersistentCongestionThreshold

smoothed_rtt + max(4*rttvar, kGranularity) + max_ack_delay = 2
kPersistentCongestionThreshold = 3

7.7. 节奏控制

发送方 SHOULD 基于来自 拥塞控制器的输入，对所有传输中包的发送进行节奏控制。¶

在网络中连续发送多个包而不在它们之间加入任何延迟，会产生 包突发，这可能导致短期拥塞和丢包。发送方 MUST 使用节奏控制或限制此类突发。发送方 SHOULD 将突发限制为 初始拥塞窗口；见 第 7.2 节。如果发送方 知道通向接收方的网络路径可以吸收更大的突发，MAY 使用更高的 限制。¶

实现应注意将其拥塞控制器设计为 能够很好地与节奏控制器配合。例如，节奏控制器可以包装拥塞 控制器并控制拥塞窗口的可用性，或者节奏控制器 可以对拥塞控制器交给它的包进行节奏化发送。¶

ACK 帧的及时交付对于高效丢包恢复很重要。为了 避免延迟它们向对端的交付，仅包含 ACK 帧的包 因此 SHOULD 不进行节奏控制。¶

端点可以按其选择实现节奏控制。完美节奏控制的发送方 会在时间上完全均匀地分散 包。对于基于窗口的拥塞控制器，例如 本文档中的控制器，该速率可以通过在 RTT 上平均 拥塞窗口来计算。以字节每时间为单位的 速率表示，其中 congestion_window 以字节为单位：¶

rate = N * congestion_window / smoothed_rtt

或者以时间为单位的包间隔表示：¶

interval = ( smoothed_rtt * packet_size / congestion_window ) / N

使用一个较小但至少为 1 的 N 值（例如 1.25）可以确保 RTT 的变化不会导致 拥塞窗口利用不足。¶

实际考虑因素，例如分包、调度延迟和 计算效率，可能导致发送方在远短于 RTT 的时间段内 偏离该速率。¶

节奏控制的一种可能实现策略使用漏桶 算法，其中“桶”的容量被限制为最大突发大小，而 “桶”填充的速率由上述函数确定。¶

7.8. 未充分利用 拥塞窗口

当传输中字节数小于拥塞窗口，并且发送不受 节奏控制限制时，拥塞窗口处于未充分利用状态。这可能由于 应用数据不足或流量控制限制而发生。当这种情况发生时， 无论是在慢启动还是拥塞避免中， 拥塞窗口 SHOULD NOT 增加。¶

对包进行节奏控制的发送方（见 第 7.7 节）可能会因该延迟而推迟发送包， 并且未能充分利用拥塞窗口。如果没有节奏控制延迟时发送方本可以 充分利用拥塞窗口，则发送方 SHOULD NOT 认为自己受应用限制。¶

发送方 MAY 实现替代机制，以便在 未充分利用时期之后更新其拥塞窗口，例如 [RFC7661] 中为 TCP 提出的机制。¶

8.1. 丢包和拥塞 信号

丢包检测和拥塞控制从根本上涉及使用来自未经认证 实体的信号，例如延迟、丢包和 ECN 标记。 攻击者可以通过操纵这些信号来导致端点降低其发送速率： 通过丢弃包、策略性地改变路径延迟， 或改变 ECN 码点。¶

8.2. 流量分析

仅承载 ACK 帧的包可以通过观察 包大小以启发式方式识别。 确认模式可能暴露关于链路 特征或应用行为的信息。为了减少泄露的信息， 端点可以将确认与其他帧捆绑，或者可以使用 PADDING 帧，但这可能以性能为代价。¶

8.3. 误报 ECN 标记

接收方可以误报 ECN 标记来改变 发送方的拥塞响应。抑制 ECN-CE 标记报告可能导致发送方 提高其发送速率。这种提高可能导致拥塞和丢包。¶

发送方可以通过将其发送的偶发包标记为 ECN-CE 标记来 检测报告抑制。如果使用 ECN-CE 标记发送的包在被确认时 没有被报告为 CE 标记，则 发送方可以通过不再为该路径上随后发送的包设置 ECN-Capable Transport (ECT) 码点来为该路径禁用 ECN [RFC3168]。¶

报告额外的 ECN-CE 标记会导致发送方降低其 发送 速率，这在效果上类似于宣告降低的连接流量控制 限制，因此这样做并不能获得好处。¶

端点会选择它们使用的拥塞控制器。拥塞 控制器会通过降低速率来响应 ECN-CE 报告，但响应可能有所不同。 标记可以被视为等同于丢包 [RFC3168]，但也可以指定其他 响应，例如 [RFC8511] 或 [RFC8311]。¶

A.1. 跟踪已发送包

为正确实现拥塞控制，QUIC 发送方会跟踪每个 诱发 ACK 的包，直到该包被确认或丢失。 预期实现能够通过包编号和加密上下文访问此信息，并存储每包字段 （附录 A.1.1），用于丢包恢复和 拥塞控制。¶

在包被声明为丢失后，端点仍可在一段时间内维护其状态， 以允许包重排序；见 [QUIC-TRANSPORT] 的 第 13.3 节。这 使发送方能够检测伪重传。¶

已发送包按每个包编号空间进行跟踪，ACK 处理仅适用于单个空间。¶

A.2. 相关常量

丢包恢复中使用的常量基于 RFC、论文 和 通用实践的组合。¶

kPacketThreshold:

在包阈值丢包检测将一个包 视为丢失之前，允许的最大包重排序。 第 6.1.1 节中推荐的值为 3。¶

kTimeThreshold:

在时间阈值丢包检测将一个包 视为丢失之前，允许的最大时间重排序。以 RTT 乘数指定。 第 6.1.2 节中推荐的值为 9/8。¶

kGranularity:

定时器粒度。这是一个依赖系统的值，第 6.1.2 节 推荐值为 1 ms。¶

kInitialRtt:

在取得 RTT 样本之前使用的 RTT。 第 6.2.2 节中推荐的值为 333 ms。¶

kPacketNumberSpace:

一个用于枚举三个包编号空间的枚举：¶

enum kPacketNumberSpace {
  Initial,
  Handshake,
  ApplicationData,
}

A.3. 相关变量

实现拥塞控制机制所需的变量 在本节中描述。¶

latest_rtt:

在收到对 先前未确认包的确认时所作的最近一次 RTT 测量。¶

smoothed_rtt:

连接的平滑 RTT，按 第 5.3 节所述计算。¶

rttvar:

RTT 变动，按第 5.3 节所述计算。¶

min_rtt:

一段时间内看到的最小 RTT，忽略 确认延迟，如 第 5.2 节所述。¶

first_rtt_sample:

获得第一个 RTT 样本的时间。¶

max_ack_delay:

接收方打算延迟确认 Application Data 包编号 空间中的包的最长时间，由同名传输参数定义（[QUIC-TRANSPORT] 的 第 18.2 节）。请注意，收到的 ACK 帧中的实际 ack_delay 可能因定时器较晚、重排序或丢失而更大。¶

loss_detection_timer:

用于丢包检测的多模式定时器。¶

pto_count:

在未收到确认的情况下已发送 PTO 的次数。¶

time_of_last_ack_eliciting_packet[kPacketNumberSpace]:

最近一个诱发 ACK 的包发送的时间。¶

largest_acked_packet[kPacketNumberSpace]:

到目前为止在该包编号空间中被确认的最大包编号。¶

loss_time[kPacketNumberSpace]:

该包编号空间中的下一个包可因超过时间上的重排序窗口而 被视为丢失的时间。¶

sent_packets[kPacketNumberSpace]:

包编号空间中的包编号到其相关信息的 关联。上文附录 A.1中已有详细描述。¶

A.4. 初始化

在连接开始时，按如下方式初始化丢包检测变量：¶

loss_detection_timer.reset()
pto_count = 0
latest_rtt = 0
smoothed_rtt = kInitialRtt
rttvar = kInitialRtt / 2
min_rtt = 0
first_rtt_sample = 0
for pn_space in [ Initial, Handshake, ApplicationData ]:
  largest_acked_packet[pn_space] = infinite
  time_of_last_ack_eliciting_packet[pn_space] = 0
  loss_time[pn_space] = 0

A.5. 发送包时

包发送后，会存储关于该包的信息。 OnPacketSent 的参数已在上文附录 A.1.1中详细描述。¶

OnPacketSent 的伪代码如下：¶

OnPacketSent(packet_number, pn_space, ack_eliciting,
             in_flight, sent_bytes):
  sent_packets[pn_space][packet_number].packet_number =
                                           packet_number
  sent_packets[pn_space][packet_number].time_sent = now()
  sent_packets[pn_space][packet_number].ack_eliciting =
                                           ack_eliciting
  sent_packets[pn_space][packet_number].in_flight = in_flight
  sent_packets[pn_space][packet_number].sent_bytes = sent_bytes
  if (in_flight):
    if (ack_eliciting):
      time_of_last_ack_eliciting_packet[pn_space] = now()
    OnPacketSentCC(sent_bytes)
    SetLossDetectionTimer()

A.6. 接收 数据报时

当服务器受到反放大限制阻塞时，接收 一个数据报会解除其阻塞，即使该 数据报中的包都没有被成功处理。在这种情况下，PTO 定时器需要重新启动。¶

OnDatagramReceived 的伪代码如下：¶

OnDatagramReceived(datagram):
  // If this datagram unblocks the server, arm the
  // PTO timer to avoid deadlock.
  if (server was at anti-amplification limit):
    SetLossDetectionTimer()
    if loss_detection_timer.timeout < now():
      // Execute PTO if it would have expired
      // while the amplification limit applied.
      OnLossDetectionTimeout()

A.7. 接收 确认时

收到 ACK 帧时，它可能新近确认任意数量的 包。¶

OnAckReceived 和 UpdateRtt 的伪代码如下：¶

IncludesAckEliciting(packets):
  for packet in packets:
    if (packet.ack_eliciting):
      return true
  return false

OnAckReceived(ack, pn_space):
  if (largest_acked_packet[pn_space] == infinite):
    largest_acked_packet[pn_space] = ack.largest_acked
  else:
    largest_acked_packet[pn_space] =
        max(largest_acked_packet[pn_space], ack.largest_acked)

  // DetectAndRemoveAckedPackets finds packets that are newly
  // acknowledged and removes them from sent_packets.
  newly_acked_packets =
      DetectAndRemoveAckedPackets(ack, pn_space)
  // Nothing to do if there are no newly acked packets.
  if (newly_acked_packets.empty()):
    return

  // Update the RTT if the largest acknowledged is newly acked
  // and at least one ack-eliciting was newly acked.
  if (newly_acked_packets.largest().packet_number ==
          ack.largest_acked &&
      IncludesAckEliciting(newly_acked_packets)):
    latest_rtt =
      now() - newly_acked_packets.largest().time_sent
    UpdateRtt(ack.ack_delay)

  // Process ECN information if present.
  if (ACK frame contains ECN information):
      ProcessECN(ack, pn_space)

  lost_packets = DetectAndRemoveLostPackets(pn_space)
  if (!lost_packets.empty()):
    OnPacketsLost(lost_packets)
  OnPacketsAcked(newly_acked_packets)

  // Reset pto_count unless the client is unsure if
  // the server has validated the client's address.
  if (PeerCompletedAddressValidation()):
    pto_count = 0
  SetLossDetectionTimer()


UpdateRtt(ack_delay):
  if (first_rtt_sample == 0):
    min_rtt = latest_rtt
    smoothed_rtt = latest_rtt
    rttvar = latest_rtt / 2
    first_rtt_sample = now()
    return

  // min_rtt ignores acknowledgment delay.
  min_rtt = min(min_rtt, latest_rtt)
  // Limit ack_delay by max_ack_delay after handshake
  // confirmation.
  if (handshake confirmed):
    ack_delay = min(ack_delay, max_ack_delay)

  // Adjust for acknowledgment delay if plausible.
  adjusted_rtt = latest_rtt
  if (latest_rtt >= min_rtt + ack_delay):
    adjusted_rtt = latest_rtt - ack_delay

  rttvar = 3/4 * rttvar + 1/4 * abs(smoothed_rtt - adjusted_rtt)
  smoothed_rtt = 7/8 * smoothed_rtt + 1/8 * adjusted_rtt

A.8. 设置丢包 检测定时器

QUIC 丢包检测使用一个单一定时器进行所有超时丢包检测。 定时器的持续时间基于定时器的模式，该模式在下方的包 和定时器事件中设置。下面定义的函数 SetLossDetectionTimer 展示如何设置这个单一定时器。¶

该算法可能导致定时器被设置到过去的时间，尤其是在 定时器唤醒较晚时。设置在过去的定时器会立即触发。¶

SetLossDetectionTimer 的伪代码如下（其中 “^” 运算符 表示 幂运算）：¶

GetLossTimeAndSpace():
  time = loss_time[Initial]
  space = Initial
  for pn_space in [ Handshake, ApplicationData ]:
    if (time == 0 || loss_time[pn_space] < time):
      time = loss_time[pn_space];
      space = pn_space
  return time, space

GetPtoTimeAndSpace():
  duration = (smoothed_rtt + max(4 * rttvar, kGranularity))
      * (2 ^ pto_count)
  // Anti-deadlock PTO starts from the current time
  if (no ack-eliciting packets in flight):
    assert(!PeerCompletedAddressValidation())
    if (has handshake keys):
      return (now() + duration), Handshake
    else:
      return (now() + duration), Initial
  pto_timeout = infinite
  pto_space = Initial
  for space in [ Initial, Handshake, ApplicationData ]:
    if (no ack-eliciting packets in flight in space):
        continue;
    if (space == ApplicationData):
      // Skip Application Data until handshake confirmed.
      if (handshake is not confirmed):
        return pto_timeout, pto_space
      // Include max_ack_delay and backoff for Application Data.
      duration += max_ack_delay * (2 ^ pto_count)

    t = time_of_last_ack_eliciting_packet[space] + duration
    if (t < pto_timeout):
      pto_timeout = t
      pto_space = space
  return pto_timeout, pto_space

PeerCompletedAddressValidation():
  // Assume clients validate the server's address implicitly.
  if (endpoint is server):
    return true
  // Servers complete address validation when a
  // protected packet is received.
  return has received Handshake ACK ||
       handshake confirmed

SetLossDetectionTimer():
  earliest_loss_time, _ = GetLossTimeAndSpace()
  if (earliest_loss_time != 0):
    // Time threshold loss detection.
    loss_detection_timer.update(earliest_loss_time)
    return

  if (server is at anti-amplification limit):
    // The server's timer is not set if nothing can be sent.
    loss_detection_timer.cancel()
    return

  if (no ack-eliciting packets in flight &&
      PeerCompletedAddressValidation()):
    // There is nothing to detect lost, so no timer is set.
    // However, the client needs to arm the timer if the
    // server might be blocked by the anti-amplification limit.
    loss_detection_timer.cancel()
    return

  timeout, _ = GetPtoTimeAndSpace()
  loss_detection_timer.update(timeout)

A.9. 超时时

当丢包检测定时器过期时，定时器的模式决定 要执行的动作。¶

OnLossDetectionTimeout 的伪代码如下：¶

OnLossDetectionTimeout():
  earliest_loss_time, pn_space = GetLossTimeAndSpace()
  if (earliest_loss_time != 0):
    // Time threshold loss Detection
    lost_packets = DetectAndRemoveLostPackets(pn_space)
    assert(!lost_packets.empty())
    OnPacketsLost(lost_packets)
    SetLossDetectionTimer()
    return

  if (no ack-eliciting packets in flight):
    assert(!PeerCompletedAddressValidation())
    // Client sends an anti-deadlock packet: Initial is padded
    // to earn more anti-amplification credit,
    // a Handshake packet proves address ownership.
    if (has Handshake keys):
      SendOneAckElicitingHandshakePacket()
    else:
      SendOneAckElicitingPaddedInitialPacket()
  else:
    // PTO. Send new data if available, else retransmit old data.
    // If neither is available, send a single PING frame.
    _, pn_space = GetPtoTimeAndSpace()
    SendOneOrTwoAckElicitingPackets(pn_space)

  pto_count++
  SetLossDetectionTimer()

A.10. 检测丢失包

每次收到 ACK 或时间 阈值丢包检测定时器过期时，都会调用 DetectAndRemoveLostPackets。 该函数对相应包编号空间的 sent_packets 进行操作， 并返回新近检测为丢失的包列表。¶

DetectAndRemoveLostPackets 的伪代码如下：¶

DetectAndRemoveLostPackets(pn_space):
  assert(largest_acked_packet[pn_space] != infinite)
  loss_time[pn_space] = 0
  lost_packets = []
  loss_delay = kTimeThreshold * max(latest_rtt, smoothed_rtt)

  // Minimum time of kGranularity before packets are deemed lost.
  loss_delay = max(loss_delay, kGranularity)

  // Packets sent before this time are deemed lost.
  lost_send_time = now() - loss_delay

  foreach unacked in sent_packets[pn_space]:
    if (unacked.packet_number > largest_acked_packet[pn_space]):
      continue

    // Mark packet as lost, or set time when it should be marked.
    // Note: The use of kPacketThreshold here assumes that there
    // were no sender-induced gaps in the packet number space.
    if (unacked.time_sent <= lost_send_time ||
        largest_acked_packet[pn_space] >=
          unacked.packet_number + kPacketThreshold):
      sent_packets[pn_space].remove(unacked.packet_number)
      lost_packets.insert(unacked)
    else:
      if (loss_time[pn_space] == 0):
        loss_time[pn_space] = unacked.time_sent + loss_delay
      else:
        loss_time[pn_space] = min(loss_time[pn_space],
                                  unacked.time_sent + loss_delay)
  return lost_packets

A.11. 丢弃 Initial 或 Handshake 密钥时

当 Initial 或 Handshake 密钥被丢弃时，该空间中的包 会被丢弃，并且丢包检测状态会被更新。¶

OnPacketNumberSpaceDiscarded 的伪代码如下：¶

OnPacketNumberSpaceDiscarded(pn_space):
  assert(pn_space != ApplicationData)
  RemoveFromBytesInFlight(sent_packets[pn_space])
  sent_packets[pn_space].clear()
  // Reset the loss detection and PTO timer
  time_of_last_ack_eliciting_packet[pn_space] = 0
  loss_time[pn_space] = 0
  pto_count = 0
  SetLossDetectionTimer()

B.1. 相关常量

拥塞控制中使用的常量基于 RFC、 论文 和通用实践的组合。¶

kInitialWindow:

对初始传输中字节数的默认限制，如第 7.2 节所述。¶

kMinimumWindow:

以字节为单位的最小拥塞窗口，如第 7.2 节所述。¶

kLossReductionFactor:

检测到新的丢包事件时，用于降低拥塞窗口的 缩放因子。第 7 节推荐值 为 0.5。¶

kPersistentCongestionThreshold:

确定持续拥塞所需的一段时间， 指定为 PTO 乘数。第 7.6 节推荐 值为 3。¶

B.2. 相关变量

实现拥塞控制机制所需的变量 在本节中描述。¶

max_datagram_size:

发送方当前最大载荷大小。这不包括 UDP 或 IP 开销。最大数据报大小用于拥塞窗口 计算。端点基于其路径最大 传输单元（PMTU；见 [QUIC-TRANSPORT] 的 第 14.2 节）设置此变量的值，且 最小值为 1200 字节。¶

ecn_ce_counters[kPacketNumberSpace]:

对端在 ACK 帧中报告的、该包 编号空间内 ECN-CE 计数器的最高值。该值用于检测所报告 ECN-CE 计数器的增加。¶

bytes_in_flight:

所有已发送包的大小之和（以字节计），这些包至少包含一个 诱发 ACK 的帧或 PADDING 帧，且尚未被确认或声明为 丢失。该大小不包括 IP 或 UDP 开销，但包括 QUIC 头部和带关联数据的认证加密 (AEAD) 开销。 仅包含 ACK 帧的包不计入 bytes_in_flight， 以确保拥塞控制不会阻碍拥塞反馈。¶

congestion_window:

允许处于传输中的最大字节数。¶

congestion_recovery_start_time:

由于检测到丢包 或 ECN 而开始当前恢复时期的时间。当在此时间之后发送的包被确认时， QUIC 会退出拥塞恢复。¶

ssthresh:

以字节为单位的慢启动阈值。当拥塞窗口 低于 ssthresh 时， 模式为慢启动，窗口按确认的字节数 增长。¶

拥塞控制伪代码还会访问丢包 恢复伪代码中的一些变量。¶

B.3. 初始化

在连接开始时，按如下方式初始化拥塞控制 变量：¶

congestion_window = kInitialWindow
bytes_in_flight = 0
congestion_recovery_start_time = 0
ssthresh = infinite
for pn_space in [ Initial, Handshake, ApplicationData ]:
  ecn_ce_counters[pn_space] = 0

B.4. 包已发送时

每当发送一个包且该包包含非 ACK 帧时，该包 会增加 bytes_in_flight。¶

OnPacketSentCC(sent_bytes):
  bytes_in_flight += sent_bytes

B.5. 包 确认时

该函数从丢包检测的 OnAckReceived 调用，并提供来自 sent_packets 的新近 acked_packets。¶

在拥塞避免中，使用整数表示 congestion_window 的实现者应谨慎处理除法，并可使用 [RFC3465] 的 第 2.1 节中建议的替代方法。¶

InCongestionRecovery(sent_time):
  return sent_time <= congestion_recovery_start_time

OnPacketsAcked(acked_packets):
  for acked_packet in acked_packets:
    OnPacketAcked(acked_packet)

OnPacketAcked(acked_packet):
  if (!acked_packet.in_flight):
    return;
  // Remove from bytes_in_flight.
  bytes_in_flight -= acked_packet.sent_bytes
  // Do not increase congestion_window if application
  // limited or flow control limited.
  if (IsAppOrFlowControlLimited())
    return
  // Do not increase congestion window in recovery period.
  if (InCongestionRecovery(acked_packet.time_sent)):
    return
  if (congestion_window < ssthresh):
    // Slow start.
    congestion_window += acked_packet.sent_bytes
  else:
    // Congestion avoidance.
    congestion_window +=
      max_datagram_size * acked_packet.sent_bytes
      / congestion_window

B.6. 出现新的拥塞 事件时

当检测到新的拥塞事件时，该函数从 ProcessECN 和 OnPacketsLost 调用。如果尚未处于恢复状态，这会启动恢复时期，并 立即降低慢启动阈值和拥塞窗口。¶

OnCongestionEvent(sent_time):
  // No reaction if already in a recovery period.
  if (InCongestionRecovery(sent_time)):
    return

  // Enter recovery period.
  congestion_recovery_start_time = now()
  ssthresh = congestion_window * kLossReductionFactor
  congestion_window = max(ssthresh, kMinimumWindow)
  // A packet can be sent to speed up loss recovery.
  MaybeSendOnePacket()

B.7. 处理 ECN 信息

当收到来自对端、带有 ECN 小节的 ACK 帧时调用此函数。¶

ProcessECN(ack, pn_space):
  // If the ECN-CE counter reported by the peer has increased,
  // this could be a new congestion event.
  if (ack.ce_counter > ecn_ce_counters[pn_space]):
    ecn_ce_counters[pn_space] = ack.ce_counter
    sent_time = sent_packets[ack.largest_acked].time_sent
    OnCongestionEvent(sent_time)

B.8. 包丢失时

当 DetectAndRemoveLostPackets 判定包丢失时调用此函数。¶

OnPacketsLost(lost_packets):
  sent_time_of_last_loss = 0
  // Remove lost packets from bytes_in_flight.
  for lost_packet in lost_packets:
    if lost_packet.in_flight:
      bytes_in_flight -= lost_packet.sent_bytes
      sent_time_of_last_loss =
        max(sent_time_of_last_loss, lost_packet.time_sent)
  // Congestion event if in-flight packets were lost
  if (sent_time_of_last_loss != 0):
    OnCongestionEvent(sent_time_of_last_loss)

  // Reset the congestion window if the loss of these
  // packets indicates persistent congestion.
  // Only consider packets sent after getting an RTT sample.
  if (first_rtt_sample == 0):
    return
  pc_lost = []
  for lost in lost_packets:
    if lost.time_sent > first_rtt_sample:
      pc_lost.insert(lost)
  if (InPersistentCongestion(pc_lost)):
    congestion_window = kMinimumWindow
    congestion_recovery_start_time = 0

B.9. 从传输中字节数中移除已丢弃 包

当 Initial 或 Handshake 密钥被丢弃时，该空间中发送的包 不再计入传输中字节数。¶

RemoveFromBytesInFlight 的伪代码如下：¶

RemoveFromBytesInFlight(discarded_packets):
  // Remove any unacknowledged packets from flight.
  foreach packet in discarded_packets:
    if packet.in_flight
      bytes_in_flight -= size