目录
1 QUIC极其抽象的描述
QUIC是两个端点间的一种面向连接的协议。这些端点交换UDP数据报。这些UDP数据报包含QUIC数据包。QUIC端点使用QUIC数据包建立QUIC连接，是这些端点间共享的协议状态。
2 所有QUIC版本的固定属性
除了提供安全、多路复用的传输之外，QUIC[QUIC-TRANSPORT]还允许选择协商版本。这允许协议随着时间的推移而改变以响应新的需求。这允许协议随着时间的推移而改变以响应新的需求。
本文档描述了QUIC的子集，该子集旨在当新的版本被开发和部署时仍能保持稳定。所有的不变属性都独立于IP版本。
本文档的主要目的是确保可以部署新版本的QUIC。通过记录不能改变的属性，本文档旨在保留QUIC端点协商协议其他任何方面的改变的能力。因此，这也保证了向端点以外的实体提供最少的信息量。除非在本文档中明确禁止，否则不同版本之间协议的任何方面都可以更改。
附件A包含了一些基于QUIC版本1的知识做出的可能错误的假设的非详尽列表；这些不适用于QUIC的每个版本。
3 约定和定义
关键词"MUST"， “MUST NOT”， “REQUIRED”， “SHALL”， “SHALL NOT”， “SHOULD”， “SHOULD NOT”， “RECOMMENDED”， “NOT RECOMMENDED”， “MAY”，和 “OPTIONAL” 当且仅当它们以所有大写字母出现时，本文档中的内容将按照 BCP 14 [RFC2119] [RFC8174] 中的描述进行解释，如此处所示。
本文档定义了对未来 QUIC 版本的要求，即使在不使用规范语言的情况下也是如此。
本文档使用 [QUIC-TRANSPORT] 中的术语和符号约定
4 符号约定
使用本节中定义的符号描述数据包的格式。此符号与 [QUIC-TRANSPORT] 中使用的符号相同。
复杂字段被命名，然后是由一对匹配的大括号包围的字段列表。此列表中的每个字段都用逗号分隔。
单个字段包括长度信息，以及关于固定值、可选性或重复的指示。各个字段使用以下符号约定，所有长度均以位为单位：
x (A)：表示 x 是 A 位长
x (A…B)：表示 x 可以是从 A 到 B 的任意长度；可以省略A表示最小是0位，省略B表示没有设置上限；这种格式的值总是以字节边界结束
x (L) = C：表示x具有固定值C； x 的长度由 L 描述，它可以使用上述任何长度形式
x (L) …：表示 x 重复零次或多次，并且每个实例的长度为 L
本文档使用网络字节顺序（即大端）值。字段从每个字节的高位开始放置。
图 1 显示了一个示例结构：
图1：示例格式
5 QUIC数据包
QUIC 端点交换包含一个或多个 QUIC 数据包的 UDP 数据报。本节描述 QUIC 数据包的不变特性。 QUIC 的一个版本可以允许在单个 UDP 数据报中包含多个 QUIC 数据包，但不变属性仅描述数据报中的第一个数据包。
QUIC 定义了两种类型的首部：长首部和短首部。 具有长首部的数据包由设置的第一个字节的最高有效位标识； 具有短首部的数据包清除了该位。
QUIC 数据包可能受到完整性保护，包括首部。 然而，QUIC 版本协商数据包没有完整性保护； 见第 6 节。
除了此处描述的值之外，QUIC 数据包的有效负载是特定于版本的并且具有任意长度。
5.1 长首部
长首部采用图 2 中描述的形式。
图2：QUIC长首部
带有长首部的 QUIC 数据包的第一个字节的最高位设置为 1。该字节中的所有其他位都是特定于版本的。
接下来的四个字节包括一个 32 位版本字段。 版本在第 5.4 节中描述。
下一个字节是目的连接 ID 字段的字节长度。 此长度编码为8 位无符号整数。 目的连接 ID 字段跟在目的连接 ID 长度字段之后，长度在 0 到 255 个字节之间。 连接 ID 在第 5.3 节中描述。
下一个字节是源连接 ID 字段的字节长度。 此长度编码为 8 位无符号整数。 源连接 ID 字段跟在源连接 ID 长度字段之后，长度在 0 到 255 个字节之间。
数据包的其余部分包含特定于版本的内容。
5.2 短首部
短首部采用图 3 中描述的形式。
图3：QUIC短首部
带有短首部的 QUIC 数据包的第一个字节的高位设置为 0。
带有短首部的 QUIC 数据包包括紧跟在第一个字节之后的目标连接 ID。 短包头不包括目标连接 ID 长度、源连接 ID 长度、源连接 ID 或版本字段。 目标连接 ID 的长度没有编码在具有短首部的数据包中，并且不受本规范的限制。
数据包的其余部分具有特定于版本的语义。
5.3 连接ID
连接 ID 是一个任意长度的不透明字段。
连接 ID 的主要功能是确保较低协议层（UDP、IP 及以下）的寻址更改不会导致 QUIC 连接的数据包被传送到错误的 QUIC 端点。端点和支持它们的中介使用连接 ID 来确保每个 QUIC 数据包都可以传递到端点的正确实例。在端点，连接 ID 用于标识数据包所针对的 QUIC 连接。
每个端点使用特定于版本的方法选择连接 ID。同一 QUIC 连接的数据包可能使用不同的连接 ID 值。
5.4 版本
版本字段包含一个 4 字节的标识符。端点可以使用此值来标识 QUIC 版本。值为 0x00000000 的 Version 字段保留用于版本协商；见第 6 节。所有其他值都可能有效。
本文档中描述的属性适用于 QUIC 的所有版本。不符合本文档中描述的属性的协议不是 QUIC。未来的文档可能会描述适用于特定 QUIC 版本或一系列 QUIC 版本的附加属性。
6 版本协商
一个 QUIC 端点接收到一个带有长首部和一个它不理解或不支持的版本的数据包可能会发送一个版本协商数据包作为响应。 具有短首部的数据包不会触发版本协商。
版本协商数据包设置第一个字节的最高位为1，因此它符合第 5.1 节中定义的具有长首部的数据包格式。 版本协商数据包可通过版本字段识别，该字段设置为 0x00000000。
图4：版本协商数据包
只有版本协商数据包的第一个字节的最高有效位具有任何定义的值。剩余的 7 位标记为“未使用”，在发送时可以设置为任何值，并且在接收时必须忽略。
在源连接 ID 字段之后，版本协商数据包包含支持版本字段的列表，每个字段标识发送数据包的端点支持的版本。版本协商数据包不包含其他字段。端点必须忽略没有 Supported Version 字段或包含截断的 Supported Version 值的数据包。
版本协商数据包不使用完整性或机密性保护。特定的 QUIC 版本可能包括协议元素，允许端点检测支持版本集中的修改或损坏。
端点必须在目的连接 ID 字段中包含它接收到的数据包的源连接 ID 字段中的值。 源连接 ID 字段的值必须从接收到的数据包的目的连接 ID 字段中复制，最初由客户端随机选择。回显两个连接 ID 为客户端提供了一些保证，即服务器收到了数据包，并且版本协商数据包不是由无法观察数据包的攻击者生成的。
接收版本协商数据包的端点可能会更改它决定用于后续数据包的版本。端点更改其 QUIC 版本的条件将取决于它选择的 QUIC 版本。
有关支持 QUIC 版本 1 的端点如何生成和使用版本协商数据包的更详细描述，请参见 [QUIC-TRANSPORT]。
7 安全和隐私考虑
中间盒可能会观察特定版本的 QUIC 的特征，并假设当其他版本的 QUIC 表现出相似的特征时，正在表达相同的底层语义。可能有很多这样的特征；参见附录 A。 已经做出了一些努力来消除或掩盖 QUIC 版本 1 中的一些可观察特征，但其中许多仍然存在。其他 QUIC 版本可能会做出不同的设计决策，因此表现出不同的特征。
QUIC 版本号并未出现在所有 QUIC 数据包中，这意味着根据特定于版本的特征从流中可靠地提取信息需要中间盒为它们看到的每个连接 ID 保留状态。
本文档中描述的版本协商数据包不受完整性保护；它只有适度的保护以防止攻击者插入。如果结果尝试不同的 QUIC 版本，端点必须验证版本协商数据包的语义内容。
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.。
- [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 参考资料
- [QUIC-TLS] 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.
- [QUIC-TRANSPORT] 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.
- [RFC5116] McGrew, D., “An Interface and Algorithms for Authenticated Encryption”, RFC 5116, DOI 10.17487/RFC5116, January 2008, https://www.rfc-editor.org/info/rfc5116.
附录A 错误的假设
QUIC 版本 1 [QUIC-TRANSPORT] 有几个特性不受观察保护，但在部署新版本时仍被认为是可变的。
本节列出了基于 QUIC 版本 1 的知识可能对 QUIC 做出的错误假设的示例。其中一些陈述甚至不适用于 QUIC 版本 1。这不是一个详尽的列表；它仅用于说明。
对于给定的 QUIC 版本，以下任何和所有陈述都可能是错误的：
- QUIC 使用 TLS [QUIC-TLS]，一些 TLS 消息在线路上可见。
- QUIC 长首部仅在连接建立期间交换。
- 给定 5 元组上的每个流都将包括一个连接建立阶段。
- 流上交换的第一个数据包使用长首部。
- 可能会假设长时间静止之前的最后一个数据包仅包含一个确认。
- QUIC 使用带有关联数据的身份验证加密 (AEAD) 功能 (AEAD_AES_128_GCM；参见 [RFC5116]) 来保护它在连接建立期间交换的数据包。
- QUIC 数据包编号被加密并显示为第一个加密字节。
- 每发送一个数据包，QUIC 数据包编号增加 1。
- 对于客户端发送的第一个握手数据包，QUIC 具有最小大小。
- QUIC 规定客户先发言。
- QUIC 数据包始终设置第一个字节 (0x40) 的第二位。
- QUIC 版本协商包仅由服务器发送。
- QUIC 连接 ID 很少更改。
- 如果 QUIC 端点收到版本协商数据包，它们会更改它们所说的版本。
- QUIC 长头中的 Version 字段在两个方向上都是相同的。
- Version 字段中具有特定值的 QUIC 数据包表示正在使用相应版本的 QUIC。
- 任何一对 QUIC 端点之间一次只能建立一个连接。
725
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
