跳到主要内容

13. 分包与可靠性

13. 分包与可靠性​

发送方在一个 QUIC packet 中发送一个或多个 frame (第 12.4 节). 发送方可以通过在每个 QUIC packet 中尽可能包含更多 frame, 来最小化每个 packet 的带宽和计算成本. 对于未被最大程度填充的 packet, 发送方 MAY 等待一小段时间以收集多个 frame 后再发送, 从而避免发出大量小 packet.

13.1 Packet 处理​

在成功移除 packet protection 且处理完 packet 中包含的所有 frame 之前, 该 packet MUST NOT 被确认. 对于 STREAM frame, 这意味着数据已经入队, 准备由应用协议接收, 但并不要求数据已经被交付和消费.

13.2 生成确认​

endpoint 会确认其接收并处理的所有 packet. 不过, 只有 ack-eliciting packet 会导致在最大 ACK 延迟内发送 ACK frame. 非 ack-eliciting 的 packet 只有在因其他原因发送 ACK frame 时才会被确认.

13.2.1 发送 ACK Frame​

每个 packet SHOULD 至少被确认一次, 并且 ack-eliciting packet MUST 在 endpoint 使用 max_ack_delay transport parameter 通告的最大延迟内至少被确认一次; 见第 18.2 节.

13.2.2 确认频率​

接收方决定响应 ack-eliciting packet 时发送确认的频率. 该决定取决于具体实现.

13.2.3 管理 ACK 范围​

发送 ACK frame 时, 会包含一个或多个已确认 packet 的范围. 包含较旧的范围可以降低因先前发送的 ACK frame 丢失而导致伪重传的可能性.

13.2.4 通过跟踪 ACK Frame 限制范围​

当发送方收到对某个包含 ACK frame 的 packet 的确认时, 发送方可以停止确认小于或等于该 ACK frame 中最大已确认值的 packet.

13.2.5 测量并报告主机延迟​

endpoint 会测量从收到 ack-eliciting packet 到发送相应 ACK 之间的延迟.

13.2.6 ACK Frame 与 Packet Protection​

ACK frame MUST 只承载于与被确认 packet 相同 packet number space 的 packet 中.

13.2.7 PADDING Frame 消耗拥塞窗口​

就拥塞控制而言, 包含 PADDING frame 的 packet 被视为在途 packet [QUIC-RECOVERY].

13.3 信息重传​

QUIC 使用否定确认 (NACK) 与肯定确认 (ACK) 的组合来触发重传. QUIC packet 不会作为整体被重传; 当 packet 被判定为丢失时, 其中可能承载的信息会按需在新的 packet 中再次发送.

新的 frame 和 packet 用于承载被判定为已丢失的信息. 通常, 当包含某项信息的 packet 被判定为丢失时, 会再次发送该信息; 当包含该信息的 packet 被确认后, 则停止发送.

13.4 显式拥塞通知​

QUIC endpoint 使用 Explicit Congestion Notification (ECN) [RFC3168] 来检测并响应网络拥塞. ECN 允许 endpoint 标记 packet, 以请求网络元素添加 congestion experienced (CE) 标记, 而不是丢弃该 packet.

13.4.1 报告 ECN 计数​

使用 ECN 要求两个 endpoint 都在 IP packet 中启用 ECN, 并在 QUIC ACK frame 中报告 CE 标记的接收情况.

13.4.2 ECN 验证​

有故障的网络设备可能会损坏或错误丢弃携带非零 ECN codepoint 的 packet. 为了在存在此类设备时确保连接性, endpoint 会验证从对端收到的 ECN 计数, 并在计数看起来不可靠时禁用 ECN.