RFC9221 QUIC不可靠数据报扩展

aashuii

已于 2022-11-03 17:18:17 修改

阅读量267

点赞数

分类专栏： quic 文章标签：网络 tcp/ip java

于 2022-11-03 14:42:38 首次发布

原文链接：www.ietf.org

版权

quic 专栏收录该内容

13 篇文章 5 订阅

订阅专栏

摘要

本文定义了QUIC传输协议的一个扩展，增加支持在QUIC连接上收发非可靠数据报。

1. 介绍

QUIC[RFC9000]提供了一种安全、多路复用的连接用来传输应用数据的可靠流。QUIC使用了多种帧类型封装在报文中来发送数据，每个帧类型定义了其中数据是否会被重传。可靠应用数据使用STREAM帧发送。

有些应用想要非可靠的传送数据，尤其是需要实时传送数据。这些应用过去可以直接使用UDP作为传输层，安全性使用DTLS保证。扩展QUIC来支持传输非可靠应用数据会提供安全传输的另一种选择，还能享受共享可靠流加密和认证的好处。

本文定义了两种携带不需要重传应用数据的新QUIC帧类型。

2. 动机

通过QUIC传输不可靠的数据比现有的解决方案更有优势：

想要在一个端点同时使用可靠流和不可靠流的应用，可靠QUIC流和不可靠QUIC数据报间可以共享握手和认证。这样相比使用TLS连接和DTLS连接能减少握手时延。
QUIC使用了比DTLS握手更细致的丢失恢复机制，可使QUIC数据的丢失回复更快。
QUIC有拥塞控制机制，为可靠和不可靠数据提供一个拥塞控制更有效和高效。

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

不可靠的QUIC数据报也可以用于在QUIC上实现IP隧道，例如用于虚拟专用网(VPN)。internet层隧道协议通常需要可靠的、经过身份验证的握手，然后是不可靠的安全IP数据包传输。例如，这可能需要用于控制数据的TLS连接，以及用于隧道化IP数据包的DTLS连接。一个QUIC连接通过支持可靠流和不可靠数据报可以支持两个部分。

3.传输参数

支持接收DATAGRAM帧的能力在QUIC传输参数中通告(name=max_datagram_frame_size, value=0x0020)。max_datagram_frame_size传输参数是一个整数值（表示为变长整数），表示终端愿意接收的DATAGRAM帧（包括帧类型，长度，和负载）最大大小，以字节计。

这个传输参数的默认值是0，表示不支持DATAGRAM帧。大于0的值表示支持DATAGRAM帧类型，并且愿意在此连接上接受这样的帧。

在接收握手期间非0值的max_datagram_frame_size参数前不能发送DATAGRAM帧（如果是0-RTT则是上次握手）。不能发送大于从对端接收的max_datagram_frame_size值的DATAGRAM帧。如果还没发送max_datagram_frame_size参数就收到了DATAGRAM帧，必须用PROTOCOL_VIOLATION错误终止链接。如果收到DATAGRAM帧比发送的max_datagram_frame_size大，必须用PROTOCOL_VIOLATION错误终止链接。

对于大多数DATAGRAM帧的使用，建议在max_datagram_frame_size参数中发送65536，来告诉对端本端将接收适合QUIC包的任意DATAGRAM帧。

max_datagram_frame_size传输参数是对DATAGRAM帧支持的单向限制和指示。使用DATAGRAM帧的应用协议可以选择只在单一方向上协商和使用它们。

客户端使用0-RTT时，可能会保存服务端max_datagram_frame_size参数。这样客户端可以在0-RTT包中发送DATAGRAM帧。服务端决定接收0-RTT数据时，必须发送max_datagram_frame_size参数，这个值必须大于等于之前这个链接上NewSessionTicket消息发送给客户端的值，如果客户端保存了max_datagram_frame_size参数的0-RTT状态，则必须确认服务端发送的max_datagram_frame_size新值不小于已保存的值。不然，客户端必须用PROTOCOL_VIOLATION错误终止链接。

应用协议必须规定缺失max_datagram_frame_size参数时的行为。如果DATAGRRAM支持在应用中是不可或缺的，应用协议在max_datagram_frame_size不存在时可以握手失败。

4. Datagram帧类型

DATAGRAM帧用来以不可靠的方式传送应用数据。DATAGRAM帧类型格式为0b0011000X（或者0x30和0x31）。DATAGRAM帧类型中最低位是LEN位(0x01)，它表示是否有长度字段存在。如果这个位被设置成0，则没有长度字段并且Datagram Data字段一直到包结束。如果此位被设置成1，则存在长度字段。

图1 DATAGRAM帧格式

DATAGRAM帧包括下列字段：

Length: 一个变长整数，表示以字节为单位的Datagram Data长度。这个字段仅在LEN位设置为1时出现。如果LEN位设置为0，Datagram Data字段延伸到QUIC包结束。注意空数据是允许的（如0长度）。

Datagram Data: 用来传送的数据。

5. 行为和使用

当应用在QUIC连接上发送数据报时，QUIC将产生一个新的DATAGRAM帧，然后在第一个可用包中发送。这个帧应该尽快（由拥堵等因素决定）发送，并可能与别的帧组合在一起。

当QUIC终端接收到一个有效DATAGRAM帧，只要能处理这个帧并且保存内容，就应该立即把数据送给应用。

同STREAM帧一样，包含应用数据的DATAGRAM帧必须用0-RTT或1-RTT秘钥加密。

注意max_datagram_frame_size限制了DATAGRAM帧的最大长度，这个限制还可以通过max_packet_size传输参数和MTU进一步降低， DATAGRAM帧不能分片，所以应用程序需要处理最大datagram长度被其他因素限制的场景。

5.1. Datagram复用

DATAGRAM帧属于整个QUIC连接，不与任何QUIC流ID相关。然而，应用可能希望通过使用标识符来区分特定的DATAGRAM帧，例如数据报的逻辑流或区分不同种类的数据报。

定义用于复用不同种类的数据报或数据报流的标识符是应用的责任。应用定义Datagram Data字段的语义以及如何解析它。

如果应用需要支持多个数据报流共存，一个推荐的模式是在Datagram Data字段的开头使用一个变长整数。这是一种允许使用最小的空间对大量的流量进行编码的简单方法。

QUIC实现应向应用提供一个API，以便为DATAGRAM帧分配相对于彼此和QUIC流的优先级。

5.2. 确认处理

虽然DATAGRAM帧不会在检测到丢包时重传，但会被回应（ack-eliciting）。接收者应该支持延迟ACK帧（在max_ack_delay指定限制内）回应收到的仅包含DATAGRAM帧的包，因为如果这些报文暂时未确认发送方也不会采取什么行动。当发送方认为报文丢失，接收方也会继续发送确认，因为接收方不知道发送方的情况（max_ack_delay超时或者其他情况）。（Receivers will continue to send ACK frames when conditions indicate a packet might be lost, since the packet's payload is unknown to the receiver, and when dictated by max_ack_delay or other protocol components.）

与任何 ack-eliciting 帧一样，当发送方怀疑仅包含 DATAGRAM 帧的报文已经丢失时，它将发送探测报文以获得更快的确认，如 [RFC9002] 6.2.4所述。

如果发送方检测到包含特定DATAGRAM帧的报文可能已经丢失，那么实现可能会通知应用它认为数据报已经丢失。

同样，如果包含 DATAGRAM 帧的报文被确认，实现可能会通知发送方应用数据报被成功传输和接收。由于重新排序，这可能包括一个被认为是丢失的 DATAGRAM 帧，但在后来被接收和确认。需要注意的是，对DATAGRAM帧的确认只表明接收方的传输层处理了该帧，并不保证接收方的应用成功处理了数据。因此，这个信号不能取代表明成功处理的应用层信号。

5.3. 流控

DATAGRAM帧不提供任何显式流控信号，并且不会造成任何每流或者链接范围的数据限制。

不为DATAGRAM帧提供流控的风险在于接收者可能不能提供处理帧的必要资源。比如，可能不能保存帧内容。然而，由于DATAGRAM帧本质上是不可靠的，如果接收者不能处理它们可以丢掉。

5.4. 拥塞控制

DATAGRAM帧使用QUIC连接的拥塞控制器。所以，连接在拥塞控制器允许之前可能不能发送应用产生的DATAGRAM帧[RFC9002]。发送者实现必须在控制器允许时延迟发送这些帧，或者丢掉这些帧不发送（可能会通知应用）。使用数据包节奏的实现（[RFC9002]7.7）也可以延迟DATAGRAM帧的发送，以保持一致的数据包节奏。

实现可以可选地支持允许应用指定一个发送超时时间，据此丢弃未发送的DATAGRAM帧。