跳到主要内容

RFC 9221 - QUIC 的不可靠数据报扩展

  • 状态: Proposed Standard
  • 发布日期: 2022 年 3 月
  • Stream: IETF
  • 勘误: 无勘误

摘要​

本文档定义 QUIC 传输协议的一项扩展, 以支持在 QUIC 连接上发送和接收不可靠数据报 (datagram).

本备忘录状态​

这是一份 Internet Standards Track 文档.

本文档是 Internet Engineering Task Force (IETF) 的产物. 它代表 IETF 社区的共识. 它已经过公开审查, 并已由 Internet Engineering Steering Group (IESG) 批准发布. 关于 Internet 标准的更多信息, 见 RFC 7841 第 2 节.

关于本文档当前状态, 任何勘误以及如何提供反馈的信息, 可从 https://www.rfc-editor.org/info/rfc9221 获取.

版权声明​

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.

本文档受 BCP 78 以及 IETF Trust 在本文档发布之日有效的 Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) 约束. 请仔细阅读这些文件, 因为它们说明了您对本文件的权利和限制. 从本文档提取的代码组件必须包含 Trust Legal Provisions 第 4.e 节所述的 Revised BSD License 文本, 并按 Revised BSD License 所述在无保证的情况下提供.

目录​

    1. 引言
    1. 动机
    1. 传输参数
    1. 数据报帧类型
    1. 行为与用法
    1. 安全考虑
    1. IANA 考虑
    1. 参考文献
  • 致谢
  • 作者地址

1. 引言​

QUIC 传输协议 [RFC9000] 提供安全的多路复用连接, 用于传输可靠的应用数据流. QUIC 使用多种帧类型在分组内传输数据, 每种帧类型定义其包含的数据是否会被重传. 可靠的应用数据流使用 STREAM 帧发送.

某些应用, 尤其是需要传输实时数据的应用, 更倾向于以不可靠方式传输数据. 过去, 这些应用直接构建在 UDP [RFC0768] 之上作为传输, 并通常使用 DTLS [RFC6347] 增加安全性. 将 QUIC 扩展为支持传输不可靠应用数据, 为安全数据报提供了另一种选择, 并额外带来与可靠流共享密码学与认证上下文的好处.

本文档定义两种新的 DATAGRAM QUIC 帧类型, 用于携带应用数据且不要求重传.

1.1. 需求规范​

本文档中的关键词 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" 和 "OPTIONAL" 应按照 BCP 14 [RFC2119] [RFC8174] 解释, 且仅当它们以全大写形式出现时适用, 如本文所示.

2. 动机​

在 QUIC 上传输不可靠数据相对于现有方案具有以下优势:

  • 希望同时使用可靠流和不可靠流与同一对端通信的应用, 可通过在可靠 QUIC 流与不可靠 QUIC 数据报流之间共享单次握手和认证上下文而受益. 与分别打开 TLS 连接和 DTLS 连接相比, 这可以降低握手所需的延迟.
  • 与 DTLS 握手相比, QUIC 使用更精细的丢包恢复机制. 这可使 QUIC 数据的丢包恢复更快发生.
  • QUIC 数据报受 QUIC 拥塞控制约束. 对可靠与不可靠数据使用单一拥塞控制可以更有效且高效.

这些特性可用于优化音视频流媒体应用, 游戏应用以及其他实时网络应用.

不可靠 QUIC 数据报也可用于在 QUIC 之上实现 IP 分组隧道, 例如用于虚拟专用网络 (VPN). 网络层隧道协议通常需要一次可靠且经过认证的握手, 随后进行不可靠的安全通信.

3. 传输参数​

本文档定义一个新的传输参数 max_datagram_frame_size (值为 0x20). 该参数表示端点愿意接收的 DATAGRAM 帧的最大大小 (包括帧类型, 长度和载荷), 单位为字节.

4. 数据报帧类型​

本文档定义两种新的帧类型:

  • DATAGRAM (0x30): 包含应用数据的 DATAGRAM 帧. 该帧不包含长度字段; 数据延伸至分组末尾.
  • DATAGRAM_WITH_LEN (0x31): 包含应用数据的 DATAGRAM 帧. 该帧包含长度字段.

5. 行为与用法​

5.1. 多路复用数据报​

DATAGRAM 帧在 QUIC 分组内与其他 QUIC 帧多路复用.

5.2. 确认处理​

尽管 DATAGRAM 帧在丢失时不会被重传, 它们仍会被确认. 这使发送方可维护拥塞控制状态, 并可能收集关于交付的统计信息.

5.3. 流量控制​

DATAGRAM 帧不受流量控制约束. max_datagram_frame_size 传输参数限制单个帧的大小, 但对字节或帧的总数没有限制.

5.4. 拥塞控制​

DATAGRAM 帧受拥塞控制. 发送 DATAGRAM 帧时, 发送方 MUST 遵守拥塞控制器的限制.

6. 安全考虑​

本文档的安全考虑与 QUIC [RFC9000] 的安全考虑类似. 使用不可靠数据报会引入一些额外考虑, 例如若数据报被用于反射流量, 则存在放大攻击的可能.

7. IANA 考虑​

7.1. QUIC 传输参数​

本文档在 "QUIC Transport Parameters" 注册表中注册一个新值:

  • Value: 0x20
  • Parameter Name: max_datagram_frame_size
  • Status: permanent
  • Specification: RFC 9221

7.2. QUIC 帧类型​

本文档在 "QUIC Frame Types" 注册表中注册两个新值:

  • Value: 0x30-0x31
  • Frame Name: DATAGRAM
  • Status: permanent
  • Specification: RFC 9221

8. 参考文献​

8.1. 规范性参考文献​

[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-editor.org/info/rfc2119.

[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, https://www.rfc-editor.org/info/rfc9000.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, https://www.rfc-editor.org/info/rfc8174.

8.2. 资料性参考文献​

[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, https://www.rfc-editor.org/info/rfc0768.

[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, https://www.rfc-editor.org/info/rfc6347.

致谢​

作者感谢相关贡献者.

作者地址​

Tommy Pauly Apple Inc. Email: [email protected]

Eric Kinnear Apple Inc. Email: [email protected]

David Schinazi Google LLC Email: [email protected]

最后于 更新