6. 性能考量 (Performance Considerations)

突发流量通常会导致时间上相关的分组丢失; 进而可能使运行在 UDP 之上的协议中的拥塞控制器产生次优响应. 为避免这种情况, UDP 代理应当 (SHOULD) 尽力避免增加 UDP 流量的突发性; 它们不应 (SHOULD NOT) 为增加批处理而排队分组.

当被代理的、运行在 UDP 之上的协议使用拥塞控制 (例如 [QUIC]) 时, 被代理流量将至少经过两个嵌套的拥塞控制器. 底层 HTTP 连接禁止 (MUST NOT) 禁用拥塞控制, 除非它有带外方式可以绝对确定内部流量已经受到拥塞控制.

如果某个客户端或 UDP 代理在包含 UDP 代理请求流的连接上禁用了拥塞控制, 则它禁止 (MUST NOT) 在该连接上宣告支持显式拥塞通知 (Explicit Congestion Notification, ECN) [ECN]. 也就是说, 它必须 (MUST) 将所有 IP 头部标记为 Not-ECT codepoint. 它可以 (MAY) 继续通过 QUIC ACK_ECN 帧或 TCP ECE bit 报告 ECN 反馈, 因为对等方可能没有禁用拥塞控制.

当被代理的、运行在 UDP 之上的协议使用丢失恢复 (例如 [QUIC]) 且底层 HTTP 连接运行在 TCP 之上时, 被代理流量将至少经过两个嵌套的丢失恢复机制. 这可能降低性能, 因为两者有时会独立重传相同数据. 为避免这种情况, UDP 代理应当 (SHOULD) 在 HTTP/3 上执行, 以便利用 QUIC DATAGRAM 帧.

6.1. MTU 考量 (MTU Considerations)

将 HTTP/3 与 QUIC Datagram 扩展 [QUIC-DGRAM] 一起使用时, UDP 负载在 QUIC DATAGRAM 帧中传输. 由于这些帧不能分片, 它们只能承载一定长度以内的负载, 该长度由 QUIC 连接配置和路径 MTU (Path MTU, PMTU) 决定. 如果 UDP 代理正在使用 QUIC DATAGRAM 帧, 且从目标收到的 UDP 负载无法放入 QUIC DATAGRAM 帧, UDP 代理不应 (SHOULD NOT) 在 DATAGRAM capsule 中发送该 UDP 负载, 因为这会破坏 Datagram Packetization Layer PMTU Discovery (DPLPMTUD) 等方法所依赖的端到端不可靠性特征 [DPLPMTUD]. 在这种场景下, UDP 代理应当 (SHOULD) 丢弃该 UDP 负载, 并向目标发送 ICMP Packet Too Big 消息; 见 [ICMP6] Section 3.2.

6.2. ECN 标记隧道化 (Tunneling of ECN Marks)

UDP 代理不会创建 IP-in-IP 隧道, 因此 [ECN-TUNNEL] 中关于在内层和外层 IP 头部之间传递 ECN 标记的指导不适用. UDP 代理隧道中不存在内层 IP 头部.

在本规范中, 请注意 UDP 代理客户端无法控制 UDP 代理发送给目标的 UDP 分组上的 ECN codepoint, UDP 代理也无法把从目标到 UDP 代理的每个 UDP 分组的标记传达给客户端.

UDP 代理必须 (MUST) 忽略从目标接收的 UDP 分组 IP 头部中的 ECN bit, 并且必须 (MUST) 将其发送给目标的 UDP 分组上的 ECN bit 设置为 Not-ECT. 这些与客户端和 UDP 代理之间发送的分组的 ECN 标记没有任何关系.