QUIC不可靠的数据报扩展

P.S. QUIC出了数据包扩展，允许QUIC数据包丢包而不重传，这样QUIC可以更好地适应低延迟媒体传输场景，例如RTC场景。个人认为这一步其实在向WebRTC靠拢，之前一直有传闻说考虑把WebRTC的底层协议换成QUIC，但是当时存在很多问题，其中一个大问题就是QUIC不允许丢包，会自动进行重传，这在RTC领域明显是不合适的。但是即使QUIC现在支持丢包，要把QUIC放进WebRTC还是要解决相当多的问题，加密的重复？QUIC拥塞控制与WebRTC的拥塞控制配合？另外，替换后的收益是什么呢？

Workgroup:Network Working GroupInternet-Draft:draft-ietf-quic-datagram-latestPublished:8 May Intended Status: Standards TrackExpires: 9 November Authors:T. Pauly E. KinnearD. SchinaziApple Inc.Apple Inc.Google LLC

摘要

本文档定义了QUIC传输协议的扩展，以增加对通过QUIC连接发送和接收不可靠数据报的支持。

鼓励在QUIC IETF邮件列表或包含草案的GitHub库上进行讨论。

备忘录状态

这个互联网草案完全遵守BCP 78和BCP 79的规定

Internet草案是Internet工程任务组（IETF）的工作文件。请注意，其他小组也可能以互联网草案的形式分发工作文件。当前的Internet草案列表位于/drafts/current/。

互联网草案是文档草案，有效期最长为六个月，并且可以随时被其他文档更新，替换或废弃。除了作为“进行中的工作”以外，将Internet草案用作参考资料或引用它们是不合适的。

该互联网草案将于11月9日到期

Copyright Notice

Copyright © IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust’s Legal Provisions Relating to IETF Documents (/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

1. 简介

QUIC传输协议提供了安全的多路复用连接，用于传输可靠的应用程序数据流。QUIC内的可靠性是按流进行的，然而某些帧类型并不适合重传。

一些应用程序，尤其是那些需要传输实时数据的应用程序，更适合不可靠地传输数据。这些应用程序可以直接基于UDPRFC0768进行传输，并可以使用DTLSRFC6347添加安全性。扩展QUIC以支持传输不可靠的应用程序数据将为安全数据报提供另一种选择，并可以共用可靠流的加密和身份验证的附加好处。

本文档定义了两种新的DATAGRAM QUIC帧类型，它们承载应用程序数据而不请求重传。

鼓励在QUIC IETF邮件列表或包含草案的GitHub库上进行讨论。

1.1 术语和定义

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here.

2. 动机(Motivation)

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

在可靠的QUIC流和不可靠的QUIC数据报流之间共享单个握手和身份验证上下文，可以使向同一对等方打开可靠TLS流和不可靠DTLS流的应用程序受益。这样可以减少握手所需的等待时间。QUIC使用比DTLS握手更为精细(nuanced)的丢失恢复机制，具有基本的丢包重发计时器。这样可以使QUIC数据的丢失恢复更快地发生。QUIC数据报虽然不可靠，但可以支持确认，使应用程序可以知道是否已成功接收到数据报。QUIC数据报受QUIC拥塞控制，这样应用程序不需要自己再实现一遍。

连接等待时间的这些减少以及应用程序对数据报传输的深入了解，对于优化音频/视频流应用程序，游戏应用程序和其他实时网络应用程序很有用。

不可靠的QUIC数据报还可以用于在QUIC上实现IP数据包隧道，例如用于虚拟专用网（VPN）。Internet层隧道协议通常需要可靠且经过身份验证的握手，然后进行IP数据包的不可靠安全传输。例如，这可能需要用于控制数据的TLS连接和用于隧道IP数据包的DTLS。单个QUIC连接可以通过添加不可靠数据包支持，同时实现两个部分。

3. 传输参数

通过QUIC传输参数（name = max_datagram_frame_size，value = 0x0020）告知对接收 DATAGRAM 帧类型的支持。max_datagram_frame_size传输参数是一个整数值（以可变长度的整数表示），表示端点愿意接收的DATAGRAM帧（包括帧类型、长度和有效载荷）的最大大小，以字节为单位。包含此参数的端点支持DATAGRAM帧类型，并愿意在此连接上接收此类帧。端点在接收到max_datagram_frame_size传输参数之前，不得发送DATAGRAM帧。端点不得发送大小严格大于端点从其对等方收到的max_datagram_frame_size值的DATAGRAM帧。当端点没有发送max_datagram_frame_size传输参数时接收到DATAGRAM帧的端点必须以错误PROTOCOL_VIOLATION终止连接。接收到的DATAGRAM帧如果严格大于其在max_datagram_frame_size传输参数中发送的值的断点，必须以错误PROTOCOL_VIOLATION终止连接。希望使用DATAGRAM帧的端点需要确保它们发送的max_datagram_frame_size值足以允许其对等方使用它们。建议在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消息的连接中发送给客户端的值。如果客户端使用其0-RTT状态存储max_datagram_frame_size传输参数的值，则它们必须验证服务器在握手中发送的max_datagram_frame_size传输参数的新值是否大于或等于所存储的值；如果不是，则客户端必须以错误PROTOCOL_VIOLATION终止连接。

使用数据报的应用协议必须定义它们如何应对缺少的max_datagram_frame_size传输参数。如果数据报支持是应用程序不可或缺的，则如果不存在max_datagram_frame_size传输参数，应用程序协议可能会使握手失败。

4. 数据报帧类型

DATAGRAM帧用于以不可靠的方式传输应用数据。DATAGRAM帧类型的形式为0b0011000X（或值0x30和0x31）。DATAGRAM 帧类型的最小显著性位是 LEN 位(0x01)。它表示有一个Length字段存在。如果该位设为0，则Length字段不存在，数据报数据字段延伸到数据包的末端。如果该位被设置为1，则表示Length字段存在。

DATAGRAM 帧的结构如下

0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| [Length (i)]...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Datagram Data (*) ...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+图1 数据报帧格式

DATAGRAM帧包含以下字段：

Length（长度）：一个可变长度的整数，指定数据报的长度，单位为字节。该字段只有在LEN位被设置时才会出现。如果 LEN 位没有设置，则数据报数据延伸到 QUIC 数据包的末端。注意，允许使用空（即零长度）数据报。

数据报数据：要传送的数据报的字节。

5. 行为和使用方法（Behavior and Usage）

当应用程序通过QUIC连接发送一个不可靠的数据报时，QUIC将生成一个新的DATAGRAM帧，并在第一个可用的数据包中发送。该帧应该尽快发送，并可能与其他帧合并。

当 QUIC 端点收到一个有效的 DATAGRAM 帧时，只要它能够处理该帧并能将内容存储在内存中，就应该立即将数据传送给应用程序。

DATAGRAM帧必须用0-RTT或1-RTT密钥保护。

使用数据报的应用协议负责定义数据报数据字段的语义，以及如何解析它。如果应用协议支持在单个QUIC连接内使用数据报的多个实体共存，则可能需要一种机制来允许它们之间的解复用。例如，使用HTTP/3的数据包涉及到在所有的数据包中预置一个流标识符，参见I-D.schinazi-quic-h3-datagram。

注意，虽然max_datagram_frame_size传输参数对DATAGRAM帧的最大大小有一个限制，但是这个限制可以通过max_packet_size传输参数和端点之间的最大传输单位（MTU）来进一步减少。DATAGRAM帧不能被分割，因此应用协议需要处理最大数据报大小受其他因素限制的情况。

5.1. 确认处理

虽然DATAGRAM帧在检测到丢失后不会重传，但它们是ACK-eliciting（I-D.inetf-quic-recovery）。接收端应该支持延迟ACK帧(在max_ack_delay指定的范围内)来回复只包含DATAGRAM帧的数据包，因为这些确认的时间不是用来恢复丢包数据的。

如果发送方检测到包含特定的DATAGRAM帧的数据包可能已经丢失，则实现可以通知应用程序它认为数据报丢失了。同样地，如果一个包含DATAGRAM帧的数据包被确认，则实现可以通知应用程序该数据报已成功地传输和接收。注意，由于重新排序的原因，一个被认为丢失的DATAGRAM帧可以在稍后的时间点被接收到并确认。

5.2. 流量控制

DATAGRAM帧不提供任何显式的流量控制信号，也不会对每个流量或连接范围内的数据限制做出任何贡献。

不为DATAGRAM帧提供流量控制的相关风险是，接收端可能无法投入必要的资源来处理这些帧。例如，它可能无法将帧内容存储在内存中。但是，由于DATAGRAM帧本身是不可靠的，如果接收端不能处理这些帧，它们可能会被丢弃。

5.3. 拥塞控制

DATAGRAM帧采用QUIC连接的拥塞控制器。因此，连接可能无法发送由应用程序生成的DATAGRAM帧，直到拥塞控制器允许它I-D.ietf-quic-recovery。发送方实现必须延迟发送帧，直到控制器允许发送帧，或者不发送帧而丢弃帧(此时，它可以通知应用程序)。

实现可以有选择地支持允许应用程序指定一个发送到期时间，超过这个时间，拥塞控制的DATAGRAM帧应该被丢弃而不发送。

6. 安全方面的考虑

DATAGRAM 帧与 QUIC 连接中传输的其他数据共享相同的安全属性。所有使用 DATAGRAM 帧传输的应用数据，就像 STREAM 帧一样，必须由 0-RTT 或 1-RTT 密钥保护。

7. IANA(互联网号码分配)的考虑

本文档在 QUIC Transport Parameter Registry 中注册一个新值。

值: 0x0020（如果本文档获得批准）参数名称: max_datagram_frame_size说明: 表示连接应该启用对不可靠的DATAGRAM帧的支持。发布此传输参数的端点可以接收来自另一个端点的数据帧，长度不超过传输参数中提供的字节长度

本文档还在QUIC帧类型注册表中注册了一个新值。

值: 0x30和0x31（如果本文档获得批准）帧名称:DATAGRAM说明: 不可靠应用数据

8. Acknowledgments

Thanks to Ian Swett, who inspired this proposal.

9. References

9.1. Normative References

[I-D.ietf-quic-recovery]

Iyengar, J. and I. Swett, “QUIC Loss Detection and Congestion Control”, Work in Progress, Internet-Draft, draft-ietf-quic-recovery-27, 9 March , /internet-drafts/draft-ietf-quic-recovery-27.txt.

[I-D.ietf-quic-transport]

Iyengar, J. and M. Thomson, “QUIC: A UDP-Based Multiplexed and Secure Transport”, Work in Progress, Internet-Draft, draft-ietf-quic-transport-27, 21 February , /internet-drafts/draft-ietf-quic-transport-27.txt.

9.2. Informative References

[I-D.schinazi-quic-h3-datagram]

Schinazi, D., “Using QUIC Datagrams with HTTP/3”, Work in Progress, Internet-Draft, draft-schinazi-quic-h3-datagram-04, 16 April , /internet-drafts/draft-schinazi-quic-h3-datagram-04.txt.

[RFC0768]

Postel, J., “User Datagram Protocol”, STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, https://www.rfc-/info/rfc768.

[RFC2119]

Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, https://www.rfc-/info/rfc2119.

[RFC6347]

Rescorla, E. and N. Modadugu, “Datagram Transport Layer Security Version 1.2”, RFC 6347, DOI 10.17487/RFC6347, January , https://www.rfc-/info/rfc6347.

[RFC8174]

Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May , https://www.rfc-/info/rfc8174.

如果觉得《QUIC不可靠的数据报扩展(An Unreliable Datagram Extension to QUIC)》对你有帮助，请点赞、收藏，并留下你的观点哦！