本文是关于QUIC进行不可靠数据报文传输的网络规范文档译文，尚未完成翻译，欢迎指正。

本文定义了QUIC传输协议的一个扩展，用以支持在一条QUIC连接上发送和接收不可靠数据报文。

本文是互联网标准追踪文档。

本文产自互联网工程任务组（IETF），已接受公开审查，并由互联网互联网工程指导委员会（IESG）批准出版。更多互联网标准相关信息详见RFC 7841第2章。

关于本文当前状态、勘误及反馈方式等相关信息请移步https://www.rfc-editor.org/info/rfc9221。

版权所有（c）2022 IETF信托及确认为文档作者的个人。保留所有权利。

本文遵守BCP 78及在本文发布之日起生效的IETF信托涉及IETF文档的法律条文（https://trustee.ietf.org/license-info）。请仔细阅读相关条文，因为其描述了你对本文所有的权利及限制。从本文中摘录的代码组件必须包含信托法律条文第4.e章的简版BSD License文件，并且不附带任何该文件所描述的保证。

QUIC传输协议（详见《RFC9000》）为传输可靠应用数据的流提供了安全且可多路复用的连接。QUIC在数据包中使用各种不同的帧类型来传输数据，每种帧类型都定义了其中的数据是否需要被重传。可靠应用数据的流是使用流帧来发送的。

部分应用，尤其是那些需要传输实时数据的应用，倾向于传输无需可靠性的数据。在过去，这些应用都是直接基于UDP（详见《RFC0768》）建立传输连接，并通常使用DTLS（详见《RFC6347》）来增强安全性。扩展QUIC并使其支持不可靠应用数据的传输，则为安全传输数据报提供了另一种方案，而且还有着共享在可靠流中使用的加密和认证上下文的好处。

本文档定义了两种新的名为数据报帧的QUIC帧类型，它们能传递应用数据而无需重传。

本文中的关键字“必须（MUST）”、“必须不（MUST NOT）”、“需要（REQUIRED）”、“强烈要求（SHALL）”、“强烈要求不（SHALL NOT）”、“应该（SHOULD）”、“不应该（SHOULD NOT）”、“推荐（RECOMMENDED）”、“不推荐（NOT RECOMMENDED）”、“可以（MAY）”，以及“可选（OPTIONAL）”应理解为BCP 14 《RFC2119》《RFC8174》所描述的，当且仅当它们像本段一样以斜体加粗方式出现的时候。

通过QUIC传输不可靠数据，比起现有的方案，具有以下优势：

• 想要面向同一个对端同时使用可靠流和不可靠流的应用能够在可靠的QUIC流和不可靠的QUIC数据报流间共享相同的握手和认证上下文，从而从中受益。比起既要打开TLS连接又要打开DTLS连接的方案，这能够降低握手过程的延迟。

• QUIC使用的丢包重传机制比起DTLS握手更加敏感。这使得QUIC数据在遭遇丢包后能更快地开始重传。

• QUIC数据报受限于QUIC的拥塞控制。为可靠的和不可靠的数据共用拥塞控制是更加有效且高效的。

这项特性对于优化音频/视频流应用、游戏应用和其他实时网络应用会很有用。

不可靠的QUIC数据报还可以被用来实现一种基于QUIC的IP数据包隧道，例如虚拟专用网（VPN）。基于互联网的隧道协议在安全地传输不可靠的IP数据包前通常需要进行可靠且经认证的握手。这可能就需要用到，比如说，一条用于控制数据的TLS连接和用于隧道传输IP数据包的DTLS连接。只要使用不可靠的数据报和可靠的流，那么仅用单条QUIC连接就能够同时满足这两部分要求。

对数据报帧的支持是通过某个QUIC传输参数（名为max_datagram_frame_size，ID为0x20）来告知对端的。传输参数max_datagram_frame_size是一个整型值（用可变长度整型来表示），它表示着数据报帧的最大尺寸。

默认情况下，该参数的值为0，这表示终端不支持数据报帧。大于0的值则表示终端支持数据报帧并且愿意在此连接中接收数据报帧。

除非终端在握手期间（或上一次握手期间，如果使用了0-RTT）接收到了非零的传输参数max_datagram_frame_size，否则它必须不发送数据报帧。终端发送的数据报帧尺寸必须不超过它从对端接收到的max_datagram_frame_size值。没有通过传输参数表明支持数据报帧就接收到数据报帧的终端必须使用类型为PROTOCOL_VIOLATION（协议违背）的错误终止连接。类似地，如果终端接收到的数据报帧尺寸超过了它发送的传输参数max_datagram_frame_size的值，那么它必须使用类型为PROTOCOL_VIOLATION的错误终止连接。

对于大多数数据报帧的使用场景，推荐用值为65535的传输参数max_datagram_frame_size来表明终端愿意接受所有能够放进QUIC数据包的数据报帧。

传输参数max_datagram_frame_size是一个单向的限制，并且表明着对数据报帧是否支持。使用数据报帧的应用协议可以选择仅在单一方向上协商与使用这种帧。

当客户端使用0-RTT时，它们可以存储来自服务器的传输参数max_datagram_frame_size的值。这么做使得客户端可以在0-RTT数据包中发送数据报帧。当服务器决定接收0-RTT数据时，它们发送的传输参数max_datagram_frame_size 的值必须大于等于它们曾在发送了NewSessionTicket消息的连接中发送给客户端的值。如果客户端存储了传输参数max_datagram_frame_size的值和它们的0-RTT状态数据，那么它们必须验证服务器在握手时新发送的传输参数max_datagram_frame_size的值，确保它大于等于客户端存储的旧值；如若不然，客户端必须使用类型为PROTOCOL_VIOLATION的错误终止连接。

使用数据报的应用协议必须定义在缺失传输参数max_datagram_frame_size时的行为。如果对数据报的支持对于应用至关重要，那么应用协议在传输参数max_datagram_frame_size缺失时可以使握手失败。

数据报帧被用来以不可靠的方式传输应用数据。数据报帧中的类型字段使用0b0011000X的形式（或者说值0x30和0x31）。数据报帧的类型字段的最低有效位被称为LEN比特位（掩码为0x01），它表示着后方是否存在长度字段；如果该比特位被置为0，那么就不存在长度字段，并且数据报数据字段一路延伸至数据包的末尾；如果该比特位被置为1，那么就表示后方存在长度字段。

数据报帧的结构如下：

数据报帧 {
  类型 (i) = 0x30..0x31,
  [长度 (i)],
  数据报数据 (..),
}

数据报帧包含着以下字段：

长度：

一个可变长度整型，标示着数据报数据字段以字节为单位的长度。只有当LEN比特位被置为1时，该字段才存在。当LEN比特位被置为0时，数据报数据字段一路延伸至QUIC数据包的末尾。注意，空数据报（也就是零长度）是被允许的。

数据报数据：

正在传递的数据报字节。

当应用通过QUIC连接发送数据报时，QUIC会创建一个新的数据报帧并将它放在首个可用的数据包中发送。这个帧应该被尽快发送（主要由拥塞控制等其他因素控制，如下文所述），并且可以和其他帧一起被合并。

当某个QUIC终端接收到一个合法的数据报帧时，只要它有能力处理这个帧并且能够将内容存储在内存中，它就应该将数据立即传递给应用。

就像流帧一样，数据报帧包含着应用数据并且必须收到0-RTT或1-RTT密钥的保护。

注意，传输参数max_datagram_frame_size限制了数据报帧的最大尺寸，该限制值可能被传输参数max_udp_payload_size和终端间路径的最大传输单元（MTU）进一步限制。数据报帧不能被分段；因此，应用协议需要处理最大数据报尺寸被其他因素限制的情况。

数据报帧直接归属于一条QUIC连接，并且没有与任何QUIC层的流ID关联。然而，应用可能希望通过标识符来区分特定的数据报帧，例如用于逻辑流的数据报，或区分不同类型的数据报。

定义用于将不同种类的数据报或不同的数据报流多路复用的标识符是运行于QUIC上的应用协议的责任。数据报数据字段的语义及其解析方法是由应用定义的。

如果应用需要支持多路数据报流的存在，一种推荐的方法是在数据报数据字段的起始位置使用一个可变长度整型。这是一个能够在最少空间内编码大量流的简单方法。

QUIC实现应该向应用提供一个可以指定数据报流之间及其相对QUIC流的优先级的API。

尽管数据报帧在遭遇丢包时不会被重传，但它们是会触发ACK的（详见《RFC9002》）。接收方应该支持在响应接收到的仅包含数据报帧的数据包时推迟发送ACK帧（但不超过由max_ack_delay指定的限制），因为即便这些数据包暂时没有得到确认，发送方也不会采取任何行动。在数据包可能遭遇了丢包或时，接收方将恢复发送ACK帧，因为数据包的载荷对于接收方是未知的，max_ack_delay或其他协议组件的限制也会使得ACK帧恢复发送。

就像对待其他ACK触发帧的行为一样，当发送方怀疑仅包含数据报帧的数据包遭遇了丢包时，它会发送探测数据包来引发更快的确认，详见《RFC9002》的第6.2.4章。

如果发送方检测到包含着某个特定数据报帧的数据包可能遭遇了丢包，那么实现可以通知应用有关它认为该数据报遭遇了丢包的消息。

类似地，如果包含着数据报帧的数据包得到了确认，那么实现可以通知作为发送方的应用有关该数据报传输与接收成功的消息。由于数据包乱序的存在，可能出现数据报帧起初被认为遭遇丢包但是后来被接收到且得到确认的情况。必须注意，对于某数据报帧的确认只能表明接收方的传输层处理了这个帧，并不保证接收方的应用成功处理了数据。因此，这个信号无法代替能够表明成功处理数据的应用层信号。

数据报帧不提供任何显式的流量控制信号机制，并且不会被计入任何单条流层面上的和整条连接层面上的数据量限制。

不为数据报帧提供流量控制，它所带来的风险在于接收方可能无法腾出足够的资源来处理这些帧。举个例子，接收方可能没有能力将帧的内容存储在内存中。然而，由于数据报帧天然具有不可靠的特性，如果接收方无法处理它们，那么它们可以被丢弃。

数据报帧采用了QUIC连接的拥塞控制器。于是，在拥塞控制器批准之前（详见《RFC9002》），某条连接可能无法发送数据报帧。发送方必须要么推迟发送该帧，直到拥塞控制器批准为止，或者丢弃该帧，干脆不发送它（这时发送方可以通知应用有关该事件的消息）。使用了数据包限速（详见《RFC9002》的第7.7章）的实现还可以推迟数据报帧的发送，来维持稳定的数据包发送速率。

实现可以选择性地支持由应用指定的发送超时时间，一旦超过了该时间，那么被拥塞控制机制限制的数据报帧就应该被丢弃，而不进行传输。

数据报帧与在同一QUIC连接中发送的其他数据共享相同的安全属性，并且都适用于《RFC9000》中描述的安全性上的考量。所有用数据报帧传输的应用数据都，像流帧一样，必须受到0-RTT或1-RTT密钥的保护。

允许在0-RTT中发送数据报帧的应用协议需要定义0-RTT的使用范围；详见《RFC9001》的第5.6章。

路径上的有能力丢弃数据包的中间设备可以检测到数据报帧的使用与否。由于数据报帧不需要使用传输层的重传，因此数据报帧对待数据包丢包的与众不同的响应行为可能令使用了该帧的连接被区分出来。

本文档在注册表“QUIC传输参数”中注册了一个新值，该注册表被维护于https://www.iana.org/assignments/quic。

值：

0x20

参数名称：

max_datagram_frame_size

状态：

永久

规范：

RFC 9221

本文档在注册表“QUIC帧类型”中注册了一个新值，该注册表被维护于https://www.iana.org/assignments/quic。

值：

0x30-0x31

帧类型名称：

DATAGRAM

状态：

永久

规范：

RFC 9221

本项工作的原始提案来自于Ian Swett。

本文档收到了来自IETF QUIC工作组中诸多贡献者的反馈和建议，尤其是Nick Banks、Lucas Pardue、Rui Paulo、Martin Thomson、Victor Vasiliev和Chris Wood。

Tommy Pauly

Apple Inc.

One Apple Park Way

Cupertino, CA 95014

United States of America

Email: tpauly@apple.com

Eric Kinnear

Apple Inc.

One Apple Park Way

Cupertino, CA 95014

United States of America

Email: ekinnear@apple.com

David Schinazi

Google LLC

1600 Amphitheatre Parkway

Mountain View, CA 94043

United States of America

Email: dschinazi.ietf@gmail.com

译

• Yunzhe

  • Email: yunzhe@zju.edu.cn

• 方秋航

  • Email: fangqiuhang@163.com