QUIC 的多路径扩展

2024-06-09 00:28
文章标签 扩展 多路径 quic

本文主要是介绍QUIC 的多路径扩展,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

QUIC 的多路径扩展

抽象

本文档指定了 QUIC 协议的多路径扩展,以支持同时使用单个连接的多个路径。

讨论场地

在作为 RFC 发布之前,应删除此注释。

对本文档的讨论在 QUIC 工作组邮件列表 (quic@ietf.org), 存档于quic.

此草案的来源和问题跟踪器可在以下位置找到https://github.com/mirjak/draft-lmbdhk-quic-multipath.

本备忘录的状态

本互联网草案的提交完全符合 BCP 78 和 BCP 79 的规定。

互联网草稿是互联网工程任务的工作文档 力 (IETF)。请注意,其他组也可能分发工作 作为互联网草稿的文档。当前的互联网草案列表是 在Active Internet-Drafts.

互联网草稿是有效期最长为六个月的草稿文件 并可能被其他文档更新、替换或过时 时间。使用互联网草稿作为参考是不合适的 材料或引用它们,而不是作为“正在进行的工作”。

本互联网草案将于 2022 年 4 月 28 日到期。

目录

  • 1. 引言

    • 1.1. 约定和定义

  • 2. 握手协商和传输参数

  • 3. 路径设置和删除

    • 3.1. 路径启动

    • 3.2. 路径关闭

      • 3.2.1. 使用PATH_ABANDON帧关闭路径

      • 3.2.2. RETIRE_CONNECTION_ID框架的影响

      • 3.2.3. 空闲超时

    • 3.3. 路径状态

  • 4. 拥堵控制

  • 5. 计算路径 RTT

  • 6. 数据包调度

  • 7. 数据包号空间和连接ID的使用

    • 7.1. 使用一个数据包号空间

      • 7.1.1. 发送确认和处理范围

    • 7.2. 使用多个数据包编号空间

      • 7.2.1. QUIC 多路径的数据包保护

      • 7.2.2. QUIC Multipath 的密钥更新

  • 8. 示例

    • 8.1. 路径建立

    • 8.2. 路径关闭

  • 9. 实施注意事项

  • 10. 新框架

    • 10.1. PATH_ABANDON框架

    • 10.2. ACK_MP框架

  • 11. 错误代码

  • 12. IANA 注意事项

  • 13. 安全注意事项

  • 14. 贡献者

  • 15. 致谢

  • 16. 参考资料

    • 16.1. 规范性参考文献

    • 16.2. 信息参考

  • 作者地址

1. 引言

本文档指定了对 QUIC v1 的扩展[QUIC-传输]允许同时使用单个连接的多个路径。

该提案基于几个基本设计点:

  • 尽可能多地重用 QUIC-v1 机制。具体而言,该提案使用为 QUIC v1 指定的路径验证,旨在尽可能多地重用 QUIC 的连接迁移。
  • 使用与 QUIC v1 相同的数据包标头格式,以避免数据包被中间盒丢弃的风险(可能仅支持 QUIC v1)
  • 拥塞控制、RTT 测量和 PMTU 发现应按路径进行(以下[QUIC-传输])
  • 路径由源和目标 IP 地址以及源和目标端口的 4 元组确定。因此,每个 4 元组最多可以有一个活动路径/连接 ID。

第 9 节中指定的路径管理[QUIC-传输]实现多个目标:它指示对等方通过新的首选路径切换发送,并允许对等方释放与旧路径关联的资源。多路径需要对该机制进行几项更改:

  • 允许在多个路径上同时传输非探测帧。
  • 继续使用现有路径,即使已在另一条路径上接收到非探测帧。
  • 管理已放弃的路径的删除。

因此,此扩展指定了与第 9 节中路径管理规范的背离[QUIC-传输]因此,需要使用新的传输参数在两个端点之间进行协商,如第 2 节中指定的那样。

此提案支持协商对所有路径使用一个数据包编号空间或对每个路径使用单独的数据包编号空间。虽然单独的数据包编号空间允许更高效的 ACK 编码,尤其是当路径具有高度不同的延迟时,但这种方法需要使用连接 ID。因此,在高度受限的网络中,使用单个数字空间可能是有益的,因为这些网络无法从标头中公开连接 ID 中受益。虽然此版本文档中的规范支持这两种方法,但最终发布 QUIC 多路径扩展的目的是选择一个选项以避免不兼容。在最终公布之前,需要更多的评估和实施经验来选择一种方法。关于优缺点的一些讨论可以在这里找到: https://github.com/mirjak/draft-lmbdhk-quic-multipath/blob/master/presentations/PacketNumberSpace_s.pdf

正如此版本草案中当前定义的那样,使用多个数据包编号空间需要使用连接 ID 是双向的。当今的部署通常只在将数据包从客户端发送到服务器时使用目标连接 ID,因为这解决了迁移的最重要用例,例如 NAT 重新绑定或移动事件。需要进一步的讨论和工作来评估当连接 ID 仅存在于一个方向时,是否也支持使用多个数据包编号空间。

此提案不包括地址发现和管理。假定设置或拆除路径的地址和实际决策过程由使用 QUIC 多路径扩展的应用程序处理。此外,该提案仅指定了一个简单的基本数据包调度算法,以便提供一些基本的实现指导。然而,更先进的算法以及增强当前路径状态信令的潜在扩展有望成为未来的工作。

1.1. 约定和定义

关键词“必须”、“不得”、“必需”、“应”、“不应”、“应该”、“不应”、 本文档中的“推荐”、“不推荐”、“可能”和“可选”均应解释为 如 BCP 14 中所述[RFC2119] [RFC8174]当且仅当它们出现在所有 大写字母,如下所示。

我们假设读者熟悉[QUIC-传输]. 此外,我们还定义了以下术语:

  • 路径标识符(路径 ID):用于标识 QUIC 连接中的路径的标识符 在端点上。路径标识符用于多路径控制帧(等PATH_ABANDON帧) 确定路径。默认情况下,它被定义为目标连接 ID 的序列号 用于在该特定路径上发送数据包,但可以使用替代定义 如果该连接 ID 的长度为零。
  • 数据包编号空间标识符(PN Space ID):用于区分数据包的标识符 不同路径的数字空格。它用于 1-RTT 数据包和 ACK_MP 帧。每个节点 维护它提供给对等方的每个 CID 的“已接收数据包”列表, 用于确认使用该 CID 接收的数据包。

路径标识符和数据包号空间标识符之间的区别在于,路径标识符 在多路径控制帧中用于标识路径,并使用数据包编号空间标识符 在 1-RTT 数据包和 ACK_MP 帧中,以区分不同路径的数据包编号空间。 两个标识符具有相同的值,即连接 ID 的序列号,如果 使用非零连接 ID。如果连接 ID 长度为零,则数据包编号空间 标识符为 0,而路径标识符在路径建立时选择。

2. 握手协商和传输参数

此扩展定义了一个新的传输参数,用于协商多路径扩展的使用 在连接握手期间,如[QUIC-传输].新的传输参数为 定义如下:

  • 名称:enable_multipath(待定 - 实验使用0xbabf)
  • 值:0(默认值)表示禁用。终结点在值字段中使用 2 位来协商一个或多个 PN 空间,客户端和服务器的可用选项值列在表 1 中:
表 1:enable_multipath 的可用值
客户端选项定义允许的服务器响应
0x0不支持多路径0x0
0x1仅支持一个 PN 空间用于多路径0x0或0x1
0x2仅支持多路径的多个 PN 空间0x0或0x2
0x3支持一个PN空间和多个PN空间0x0、0x1或0x2

如果对等体不携带 enable_multipath 传输参数,则表示对等体不携带 支持多路径,端点必须回退到[QUIC-传输]使用单一路径,不得使用 本文档中定义的任何框架或机制。如果终结点收到传输参数的意外值 “enable_multipath”,它必须将其视为 MP_CONNECTION_ERROR 类型的连接错误 并关闭连接。

请注意,传输参数“active_connection_id_limit”[QUIC-传输]限制可用数量 连接 ID,并限制并发路径数。对于 QUIC 多路径扩展,当 QUIC 标头中未公开任何连接 ID 时,此限制甚至适用。

3. 路径设置和删除

完成握手后,终端节点已同意启用多路径功能,并可以开始使用多路径。本文档不讨论客户端何时决定启动新路径。我们将这种讨论委托给单独的文件。

该提案增加了一个用于路径管理的多路径控制框架:

  • PATH_ABANDON帧,供接收方放弃路径 第 10.1 节

所有新帧都以 1-RTT 数据包的形式发送[QUIC-传输].

3.1. 路径启动

协商多路径选项时,想要使用其他选项的客户端 path 必须首先使用 PATH_CHALLENGE 和 PATH_RESPONSE 启动地址验证过程 第 8 节中描述的框架[QUIC-传输].后 在新路径上接收来自客户端的数据包时,服务器可以 反过来,尝试使用相同的机制验证这些路径。

如果验证成功,客户端可以在新路径上发送非探测的 1-RTT 数据包。在 与第 9 节中的规范形成鲜明对比[QUIC-传输]这 服务器不得假设在新的 path 指示尝试迁移到该路径。取而代之的是服务器 应将已接收非探测数据包的新路径视为 可用于传输。

3.2. 路径关闭

每个终结点管理可用于传输的路径集。 在连接中的任何时间,每个端点都可以决定放弃以下路径之一, 例如,以下:本地连接的变化或 本地首选项。终结点放弃路径后,对等方将 该路径上不再接收任何非探测数据包。

想要关闭路径的端点不应依赖于隐式信号,如空闲时间或数据包丢失, 但应该使用显式请求通过发送PATH_ABANDON帧来终止路径(参见第 10.1 节)。

3.2.1. 使用 PATH_ABANDON 帧关闭路径

两个端点,即客户端和服务器,都可以通过发送PATH_ABANDON帧(参见第 10.1 节)来关闭路径,该帧 放弃具有相应路径标识符的路径。标记路径后 作为“放弃”,表示可以释放与路径相关的资源,例如使用的连接 ID。 但是,与通过该路径传递的数据相关的信息不应立即发布 因为仍然可以接收确认或其他帧,这些帧也可能触发另一条路径上的数据重新传输。

发送PATH_ABANDON帧的端点应将路径视为放弃,当 确认包含PATH_ABANDON帧的数据包。释放路径的资源时, 终结点应为路径上使用的连接 ID(如果有)发送RETIRE_CONNECTION_ID帧。

PATH_ABANDON帧的接收方不应立即释放其资源,而应释放其资源 等待收到已用连接 ID 或 3 个 RTO 的RETIRE_CONNECTION_ID帧。

通常,客户端应使用PATH_ABANDON帧向服务器指示 该路径条件已更改,使得该路径不再可用或将不再可用,例如,在万一 移动事件。因此,PATH_ABANDON帧向接收对等体指示发送方 不打算再在该路径上发送任何数据包,但也建议接收方不要 数据包应向任一方向发送。PATH_ABANDON帧的接收器也可以 发送一个PATH_ABANDON帧,以表明它自己愿意不再在此路径上发送任何数据包。

如果使用连接 ID,则可以在任何路径上发送PATH_ABANDON帧,而不仅仅是 打算关闭。因此,即使该路径上的连接是 已经坏了。如果未使用连接 ID,并且必须在路径上发送PATH_ABANDON帧 也就是说,包含PATH_ABANDON帧的数据包或 无法再接收包含 PATH_ABANDON 帧的 ACK 的数据包,并且终端节点 可能需要依靠空闲超时来关闭路径,如第 3.2.3 节中所述。

可重新传输的帧,这些帧之前已在废弃路径上发送并被视为丢失, 应该在不同的路径上重新传输。

如果为 QUIC 连接的唯一活动路径接收到PATH_ABANDON帧,则接收 peer 应该发送一个CONNECTION_CLOSE帧并进入关闭状态。如果客户端 收到最后一个打开路径的PATH_ABANDON帧,如果出现以下情况,它可能会尝试打开新路径 可用,并且仅在路径验证失败或帧CONNECTION_CLOSE时启动连接关闭 从服务器接收。同样,服务器可以等待一个短暂的、有限的时间,例如一个 RTO 如果在发送CONNECTION_CLOSE帧之前在新路径上接收到路径探测数据包。

3.2.2. RETIRE_CONNECTION_ID帧的影响

接收RETIRE_CONNECTION_ID帧会导致端点丢弃与 该连接 ID。如果对等方使用连接 ID 来标识从对等方到 此终结点,资源包括用于发送确认的已接收数据包列表。 对等方可以决定继续使用以前的相同 IP 地址和 UDP 端口发送数据 与连接 ID 关联,但执行此操作时必须使用其他连接 ID。

3.2.3. 空闲超时

[QUIC-传输]如果连接保持空闲时间过长,则允许关闭连接。 多路径 QUIC 中的连接空闲超时定义为“在任何路径上均未收到数据包 空闲超时的持续时间“。当只有一个路径可用时,服务器必须遵循 中的规格[QUIC-传输].

当多条路径是 可用时,服务器应监视非探测数据包的到达 在可用路径上。服务器应停止在路径上发送流量 在最后 3 条路径中未收到非探测数据包 RTT,但如果该规则会取消所有可用的资格,则可以忽略该规则 路径。服务器可以释放与以下路径关联的资源 在足够长的时间内没有收到非探测数据包 路径空闲延迟,但应该只释放最后一个资源 在空闲期间未收到任何流量时的可用路径 超时,如第 10.1 节中所述[QUIC-传输]. 这意味着,如果所有路径在空闲超时期间保持空闲状态,则连接 隐式关闭。

服务器实现需要选择子路径空闲超时作为交易 在保持资源(如连接 ID)处于使用状态之间关闭 时间过长或必须立即重新建立路径 在客户端对路径放弃的虚假估计之后。

3.3. 路径状态

图 1 显示了端点路径可能具有的状态。

       o| PATH_CHALLENGE sent/received on new pathv+------------+    Path validation abandoned| Validating |----------------------------------++------------+                                  ||                                         || PATH_RESPONSE received                  ||                                         |v        Associated CID have been retired |+------------+        Path's idle timeout       ||   Active   |----------------------------------++------------+                                  ||                                         || PATH_ABANDONED sent/received            |v                                         |+------------+                                  ||   Closing  |                                  |+------------+                                  ||                                         || Associated CID have been retired        || Path's idle timeout                     |v                                         |+------------+                                  ||   Closed   |<---------------------------------++------------+

图 1:路径的状态

在非最终状态下,主机必须跟踪以下信息。

  • 关联的 4 元组:元组(源 IP、源端口、目标 IP、目标端口) endhost 用于通过路径发送数据包。
  • 关联的目标连接 ID:用于通过路径发送数据包的连接 ID。

如果在连接上使用多个数据包编号空间,则主机还必须跟踪以下信息。

  • 路径数据包编号空间:终端维护一个单独的数据包编号,用于通过此路径发送和接收数据包。 中所述的数据包号注意事项[QUIC-传输]在给定路径内应用。

在“活动”状态下,主机还必须跟踪以下信息。

  • 关联的源连接 ID:用于通过路径接收数据包的连接 ID。

处于“正在验证”状态的路径执行路径验证,如[QUIC-传输]. 终端主机不应在处于“正在验证”状态的路径上发送非探测帧,因为它无法保证数据包 实际上会到达对等方。

终端主机可以使用处于“活动”状态的所有路径,前提是拥塞控制和流量控制当前允许在路径上发送新数据。

在“关闭”状态下,终端主机不应再在此路径上发送数据包,因为无法保证 对等方仍然可以将数据包映射到连接。终端主机应等待确认PATH_ABANDONED 在将路径移动到“已关闭”状态之前进行帧,以确保路径的正常终止。

当路径达到“已关闭”状态时,endhost 将释放该路径的所有关联资源。 因此,终端主机无法再在此路径上发送或接收数据包。

4. 拥堵控制

发送方必须管理每条路径的拥塞状态,并且不得在给定路径上发送超过该路径上的拥塞控制所允许的数据。这已经是[QUIC-传输].

当多路径 QUIC 连接使用两条或多条路径时,无法保证这些路径是完全脱节的。当两条(或多条路径)共享同一瓶颈时,使用标准拥塞控制方案可能会导致带宽分配不公平,因为多路径连接比竞争的单路径连接获得更多的带宽。多路径 TCP 使用 LIA 拥塞控制方案[RFC6356]来解决这个问题。该方案可以立即适应多路径 QUIC。已经为多路径TCP提出了其他耦合拥塞控制方案,例如[奥利亚].

5. 计算路径 RTT

确认延迟是两个单向延迟的总和,即延迟 在数据包发送路径上以及所选返回路径上的延迟 致谢。当不同的路径有不同的 特征,这可能会导致确认延迟有所不同 广泛。例如,考虑使用两个 地面路径,每个方向的延迟为 50 毫秒,并且 地球静止卫星路径,两者的延迟均为 300 毫秒 方向。确认延迟将取决于组合 用于数据包传输和 ACK 传输的路径, 如表2所示。

表 2:使用多路径的 ACK 延迟示例
ACK路径\数据路径地球的卫星
地球的100毫秒350毫秒
卫星350毫秒600毫秒

使用 中指定的默认算法[QUIC-恢复]将导致 在次优性能下,计算平均 RTT 和标准 不同时延测量的一系列偏差 组合路径。同时,早期的测试表明它是 希望通过最短的路径发送 ACK,因为较短的路径 ACK 延迟可实现更紧密的控制环路和更好的性能。 测试还表明,发送 ACK 的副本是可取的 在多条路径上,如果路径突然丢失,则保持鲁棒性。

早期的实现通过使用 时间戳,如[QUIC-时间戳].当时间戳 存在,实现可以估计传输延迟 在每条单向路径上,然后可以使用这些单向延迟来获得更多 高效实施恢复和拥塞控制 算法。

如果时间戳不可用,实现可以估计一个 使用统计技术的方式延迟。例如,在示例中 如表1所示,实现可以使用“同路径” 测量以估计地面路径的单向延迟 每个方向约50ms,卫星路径约50ms。 300毫秒然后可以使用进一步的测量来维持估计值 的单向延迟变化,使用类似于卡尔曼滤波的逻辑。 但统计处理容易出错,并且使用时间戳 提供更可靠的测量。

6. 数据包调度

常规 QUIC 连接上 QUIC 数据包的传输受以下因素的约束 来自应用程序和拥塞控制方案的数据到达。QUIC公司 只有当至少一个路径的拥塞窗口打开时,才能发送数据包。

多路径 QUIC 实现还需要包含一个数据包调度程序,该调度程序决定: 在拥塞窗口打开的路径中,下一个 QUIC 数据包所经过的路径 将被发送。许多因素会影响这些算法的定义,并且 它们的确切定义超出了本文档的范围。各种数据包调度程序已被 提出并实施,特别是针对多路径TCP。配套草稿[I-D.bonaventure-iccrg-调度器]提供多种通用 数据包调度程序,具体取决于应用程序目标。

7. 数据包号空间和连接ID的使用

如果数据包标头中存在连接 ID(非零长度),则连接 ID 用于标识路径。 如果不存在连接 ID,则 4 元组标识路径。 握手(和多路径协商)期间使用的初始路径的路径 ID 为 0,因此 所有 0-RTT 数据包也使用路径 ID 0 进行跟踪和处理。 对于 1-RTT 数据包,路径 ID 是 数据包标头中存在的目标连接 ID,如第 5.1.1 节中所定义 之[QUIC-传输],如果连接 ID 长度为零,则为 0。

如果使用非零长度的连接 ID,则终结点必须在不同的路径上使用不同的连接 ID。 尽管如此,接收方仍可能会观察到在不同的 4 元组上使用的相同连接 ID 例如,由于 NAT 重新绑定。在这种情况下,接收器将按照 第 9.3 节[QUIC-传输].

初始数据包和握手数据包的确认必须使用 ACK 帧进行传输,如[QUIC-传输]. ACK 帧,如[QUIC-传输],不携带路径标识符。如果出于任何原因 ACK 帧是 在 1-RTT 数据包中接收 当多路径协商的状态不明确时,它们必须解释为确认 在路径 0 上发送的数据包。

7.1. 使用一个数据包号空间

如果协商多路径选项以对所有路径使用一个数据包编号空间,则数据包序列号将从 公用号码空间,例如,可以在一条路径上发送数据包号 N,在另一条路径上发送数据包号 N+1。

ACK 帧报告到目前为止已接收的数据包数,而不考虑接收数据包的路径。 这意味着发送方需要在发送的数据包号和 发送这些数据包的路径。这对于实现每条路径的拥塞控制是必需的。

确认数据包时,必须更新路径的拥塞控制状态 最初发送确认数据包的位置。 RTT 是根据该数据包传输和 它的第一个确认(参见第 5 节),用于更新发送路径的 RTT 统计信息。

此外,损失检测必须进行调整,以允许不同的 RTT 不同的路径。例如,计时器计算应考虑 account 发送数据包的路径的 RTT。检测 基于数据包编号,应将给定的数据包编号与 该路径接收的最高数据包编号。

7.1.1. 发送确认和处理范围

如果发送方决定在具有不同 传输延迟,一些数据包很可能会被接收出去 的顺序。这将导致 ACK 帧承载多个范围 接收的数据包。大量的范围增加了 ACK 帧,导致传输和处理开销。

ACK 帧的大小和开销可以 由以下一项或多项组合控制:

  • 不再传输 ACK 中存在的 ACK 范围 对等方确认的帧。
  • 延迟确认以允许“填孔”到达 包。
  • 限制 ACK 帧中发送的范围总数。
  • 限制特定 ACK 范围的传输次数,开启 假设足够数量的传输几乎 当然可以确保同行的接收。
  • 在单个套接字中为给定路径发送多条消息 操作,以便从单个路径发送一系列数据包 使用一系列连续的序列号而不创建 孔。

7.2. 使用多个数据包编号空间

如果启用了值为 2 的多路径选项,则每个路径都有自己的数据包编号空间,用于传输 1-RTT 数据包,并使用第 10.2 节中指定的新 ACK 帧格式。 与 QUIC v1 ACK 帧相比,MP_ACK 帧还包含数据包编号空间标识符 (PN Space ID)。 PN 空间 ID 用于区分不同路径的数据包编号空间,仅派生自目标连接 ID 的序列号。 因此,可以根据每个数据包中的目标连接 ID 来识别 1-RTT 数据包的数据包编号空间。

一旦完成值为 2 的多路径支持协商, 端点应使用 ACK_MP 帧而不是 ACK 帧来确认路径 0 上的 1-RTT 数据包, 以及握手结束后确认的 0-RTT 数据包。

以后[QUIC-传输],每个端点都使用 NEW_CONNECTION_ID 帧来颁发可用的连接 ID 到达它。在终结点通过启动路径验证添加新路径之前,它必须检查是否至少有一个未使用的路径 连接 ID 可用于每一端。

如果传输参数 “active_connection_id_limit” 协商为 N, 服务器提供了 N 个连接 ID,并且客户端已经在主动使用 N 个路径, 达到限制。如果客户端想要启动新路径,则必须停用 既定路径之一。

ACK_MP帧第 10.2 节可以通过不同的路径或识别的相同路径返回 通过路径标识符,基于发送ACK_MP帧的不同策略。

使用多个数据包编号空间需要更改 AEAD 应用于数据包的方式 保护,如第 7.2.1 节所述,以及更严格的密钥约束 更新,如第 7.2.2 节所述。

7.2.1. QUIC 多路径的数据包保护

QUIC v1 的数据包保护指定为 第 5 节[QUIC-红绿灯].一般原则 QUIC 多路径的数据包保护不会更改。无需更改即可进行设置 数据包保护密钥、初始密钥、标头保护、使用 0-RTT 密钥、接收 无序保护数据包、接收受保护数据包、 或重试数据包完整性。但是,使用多个 1-RTT 数据包的编号空间需要更改 AEAD 使用情况。

第 5.3 节[QUIC-红绿灯]指定 AEAD 的用法,特别是 nonce,N,由数据包保护 IV 与数据包编号组合而成。如果 使用多个数据包编号空间,仅数据包编号即可 不保证随机数的唯一性。

为了保证 None 的唯一性,随机数 N 的计算公式为 将数据包保护 IV 与数据包编号相结合 和路径标识符。

1-RTT 数据包的路径 ID 是 之[QUIC-传输],如果连接 ID 长度为零,则为零。 《公约》第19条[QUIC-传输]将连接 ID 序列号编码为可变长度整数, 允许值最大为 2^62-1;在此规范中,范围小于 2^32-1 在更新数据包保护密钥之前,必须使用值。

要计算随机数,则为 96 位 path-and-packet-number 由字节顺序排列的 32 位连接 ID 序列号组成, 两个零位,以及按网络字节顺序重建的 QUIC 数据包编号的 62 位。 如果 IV 大于 96 位,则路径和数据包编号将用零填充到 IV的大小。填充数据包编号和 IV 的独占 OR 构成 AEAD 随机数。

例如,假设 IV 值为 ,连接 ID 序列 number 为 ,数据包编号为 ,随机数将设置为 。6b26114b9cba2b63a9e8dd4f3aead6b2611489cba2b63a9e873e2

7.2.2. QUIC Multipath 的密钥更新

QUIC v1 的关键阶段位更新过程在[QUIC-红绿灯].密钥更新的一般原则在此没有改变 规范。在 QUIC v1 之后,关键相位用于指示哪个 数据包保护密钥用于保护数据包。关键阶段位为 切换以发出每个后续密钥更新的信号。由于网络延迟, 受旧密钥保护的数据包可能比数据包晚到达 使用新密钥进行保护。因此,终端节点需要保留旧数据包 键允许处理这些延迟的数据包,并且必须区分 在新密钥和旧密钥之间。在 QUIC V1 中,这是使用数据包完成的 数字,以便规则变得简单:如果数据包编号为 低于任何数据包编号的帧当前密钥阶段。

在不同路径上使用多个数据包编号空间时, 启动密钥更新过程时需要小心,因为路径不同 使用不同的数据包编号空间,但共享一个 钥匙。在一个路径上启动密钥更新时,数据包将发送到另一个路径 需要知道转换何时完成。否则,可能会 其他路径使用旧密钥发送数据包,但跳过发送 当前关键阶段,并直接跳转到下一个关键阶段发送数据包。 发生这种情况时,因为终端只能保留两组数据包 保护密钥与 1 位关键相位,其他路径不能 区分应该使用哪个密钥来解码接收到的数据包,从而产生什么结果 在密钥轮换同步问题中。

要解决此类同步问题,如果密钥更新是 在一条路径上初始化,发送方应发送至少一个带有新 键在所有活动路径上。此外,一个 终端节点不得启动后续密钥更新,直到具有 每条路径上都已确认当前密钥。

遵循第 5.4 节[QUIC-红绿灯],关键相位位受到保护,因此 同时发送多个具有关键相位翻转的数据包应该 不会导致可链接性问题。

8. 示例

8.1. 路径建立

图 2 说明了使用多个数据包编号空间建立新路径的示例。

   Client                                                  Server(Exchanges start on default path)1-RTT[]: NEW_CONNECTION_ID[C1, Seq=1] --><-- 1-RTT[]: NEW_CONNECTION_ID[S1, Seq=1]<-- 1-RTT[]: NEW_CONNECTION_ID[S2, Seq=2]...(starts new path)1-RTT[0]: DCID=S2, PATH_CHALLENGE[X] -->Checks AEAD using nonce(CID sequence 2, PN 0)<-- 1-RTT[0]: DCID=C1, PATH_RESPONSE[X], PATH_CHALLENGE[Y],ACK_MP[Seq=2,PN=0]Checks AEAD using nonce(CID sequence 1, PN 0)1-RTT[1]: DCID=S2, PATH_RESPONSE[Y],ACK_MP[Seq=1, PN=0], ... -->

图 2:新路径建立示例

在图 2 中,端点首先交换新的可用连接 ID 使用NEW_CONNECTION_ID框架。在此示例中,客户端提供一个连接 ID(序列号为 1 的 C1), 服务器提供两个连接 ID(S1 的序列号为 1,S2 的序列号为 2)。

在客户端通过在该路径上发送具有PATH_CHALLENGE帧的数据包来打开新路径之前, 它必须检查。每端是否有未使用的连接 ID。 在此示例中,客户端选择连接 ID S2 作为新路径中的目标连接 ID。

如果客户端已使用所有分配的 CID,则应该停用那些 不再使用,并且服务器应该提供替换,如[QUIC-传输]. 通常,需要再提供一个当前正在使用的连接 ID,以允许新路径 或迁移。

8.2. 路径关闭

在此示例中,客户端检测到网络环境变化(客户端的 4G/Wi-Fi 已关闭, Wi-Fi 信号衰减到阈值,或者 RTT 质量或丢失率 变得更糟)并希望关闭初始路径。

在图 3 中,服务器的 1-RTT 数据包使用序列号为 1 的 DCID C1 作为第一条路径;客户端的 1-RTT 数据包使用 DCID S2,其序列号为 2。对于第二条路径, 服务器的 1-RTT 数据包使用 DCID C2,其序列号为 2;这 客户端的 1-RTT 数据包使用 CID S3,其序列号为 3。请注意, 两条路径使用不同的数据包编号空间。

客户端通过发送 ID 为 1 的路径启动路径闭包 具有PATH_ABANDON帧的数据包。当服务器收到PATH_ABANDON 帧,它还会在下一个数据包中发送PATH_ABANDON帧。之后 可以使用RETIRE_CONNECTION_ID停用两个方向的连接 ID 框架。

Client                                                      Server(client tells server to abandon a path)
1-RTT[X]: DCID=S2 PATH_ABANDON[path_id=1]->(server tells client to abandon a path)<-1-RTT[Y]: DCID=C1 PATH_ABANDON[path_id=2], ACK_MP[Seq=2, PN=X]
(client abandons the path that it is using)
1-RTT[U]: DCID=S3 RETIRE_CONNECTION_ID[2], ACK_MP[Seq=1, PN=Y] ->(server abandons the path that it is using)<- 1-RTT[V]: DCID=C2 RETIRE_CONNECTION_ID[1], ACK_MP[Seq=3, PN=U]

图 3:关闭路径的示例(路径 ID type=0x00)

9. 实施注意事项

TDB公司

10. 新框架

所有新帧只能以 1-RTT 数据包的形式发送,并且不得使用其他加密级别。

如果终端节点从其他加密级别的数据包接收特定于多路径的帧,则必须返回 MP_PROTOCOL_VIOLATION为连接错误并关闭连接。

10.1. PATH_ABANDON框架

PATH_ABANDON 帧通知对等方放弃 路径。更复杂的路径管理可以 通过额外的扩展(例如,PATH_STATUS帧[I-D.liu-多路径-quic]).

PATH_ABANDON帧的格式如图 4 所示。

  PATH_ABANDON Frame {Type (i) = TBD-03 (experiments use 0xbaba05),Path Identifier (..),Error Code (i),Reason Phrase Length (i),Reason Phrase (..),}

图 4:PATH_ABANDON帧格式

PATH_ABANDON帧包含以下字段:

Path Identifier:路径的标识符,其格式如图 5 所示。

  • 标识符类型:将“标识符类型”字段设置为指示路径标识符的类型。

    • 类型 0:在以下情况下,请参阅控制帧的发送方使用的连接标识符 通过指定路径发送数据。如果此连接,则应使用此方法 标识符的长度为非零。如果此连接标识符,则不得使用此方法 长度为零。
    • 类型 1:参考控制帧的接收器在以下情况下使用的连接标识符 通过指定路径发送数据。如果此连接,则不得使用此方法 标识符长度为零。
    • 类型 2:引用发送或接收控制帧的路径。
  • 路径标识符内容:指定路径标识符的可变长度整数。如果标识符类型为 2, 路径标识符内容必须为空。
  Path Identifier {Identifier Type (i) = 0x00..0x02,[Path Identifier Content (i)],}

图 5:路径标识符格式

注意:如果PATH_ABANDON帧的接收方在该路径上使用非零长度的连接ID, 端点应将类型 0x00 用于控制帧中的路径标识符。如果接收机的PATH_ABANDON帧 使用长度为零的连接 ID,但对等方在该路径(端点)上使用非长度为零的连接 ID 应将 type 0x01 用作路径标识符。如果两个终结点都在该路径上使用 0 长度连接 ID, 端点应仅使用 0x02 类型作为路径标识符。

错误代码:

一个可变长度整数,指示放弃此路径的原因。

原因短语长度:

一个可变长度整数,指定原因短语的长度(以字节为单位)。 由于 PATH_ABANDON 帧不能在数据包之间拆分,因此任何限制 on 数据包大小也会因原因短语而限制可用空间。

原因短语:

闭合的其他诊断信息。如果出现以下情况,则长度可以为零 发件人选择不提供超出“错误代码”值的详细信息。 这应该是 UTF-8 编码的字符串[RFC3629],虽然框架 不携带有助于理解的信息,例如语言标签 由创建文本的实体以外的任何实体提供。

应确认PATH_ABANDON帧。如果数据包包含 PATH_ABANDON 帧被认为是丢失的,对等体应该重复它。

如果标识符类型为 0x00 或 0x01,则可以在任何路径上发送PATH_ABANDON帧, 而不仅仅是由“路径标识符内容”字段标识的路径。如果 标识符类型 如果0x02,则PATH_ABANDON帧只能在路径上发送 这是打算放弃的。

10.2. ACK_MP框架

ACK_MP框架(TBD-00 和 TBD-01 型;实验使用 0xbaba00..0xbaba01) 是 ACK 框架的扩展,由[QUIC-传输].它用于 使用多个时确认在不同路径上发送的数据包 数据包编号空间。如果帧类型为 TBD-01,则ACK_MP帧还包含 在连接上接收的具有关联 ECN 标记的 QUIC 数据包的总和 到这一点。

ACK_MP帧的格式如图 6 所示。

  ACK_MP Frame {Type (i) = TBD-00..TBD-01 (experiments use 0xbaba00..0xbaba01),Packet Number Space Identifier (i),Largest Acknowledged (i),ACK Delay (i),ACK Range Count (i),First ACK Range (i),ACK Range (..) ...,[ECN Counts (..)],}

图 6:ACK_MP帧格式

与 中指定的 ACK 帧相比[QUIC-传输],则添加以下字段。

Packet Number Space Identifier:路径包号空间的标识符,即 ACK_MP帧确认的 1-RTT 数据包的目标连接 ID。如果端点收到 长度为零的连接 ID 的 1-RTT 数据包,它应在ACK_MP帧中使用数据包编号空间标识符 0。 如果终端收到具有不存在的数据包编号空间 ID 的ACK_MP帧,则必须处理此帧 作为 MP_PROTOCOL_VIOLATION 类型的连接错误,然后关闭连接。

使用单个数据包编号空间时,终端主机不得发送ACK_MP帧。 如果终端主机在协商单个数据包编号空间时接收到ACK_MP帧,则必须处理 这是 MP_PROTOCOL_VIOLATION 类型的连接错误,并关闭连接。

11. 错误代码

多路径 QUIC 传输错误代码是 62 位无符号整数,其后列[QUIC-传输].

本节列出了定义的多路径 QUIC 传输错误代码,这些错误代码可以是 用于具有0x1c类型的CONNECTION_CLOSE框架。这些错误适用于整个连接。

MP_PROTOCOL_VIOLATION(实验使用0xba01):端点检测到协议符合性错误 这没有被更具体的错误代码所涵盖。

12. IANA 注意事项

本文档定义了一个新的传输参数,用于协商为 QUIC 启用多个路径, 以及两种新的框架类型。该草案定义了实验的临时值,但我们希望 IANA 能够 如果草稿获得批准,则分配短值。

表 3 中的以下条目应添加到“QUIC 传输参数”注册表中 在“QUIC协议”标题下。

表 3:QUIC 传输参数条目的附加内容
价值参数名称。规范
待定(实验使用0xbabf)enable_multipath第2节

表 4 中定义的以下帧类型应添加到“QUIC 帧类型”注册表中 在“QUIC协议”标题下。

表 4:QUIC 帧类型条目的附加内容
价值框架名称规范
TBD-00 - TBD-01(实验使用0xbaba00-0xbaba01)ACK_MP第 10.2 节
TBD-02 (实验使用0xbaba05)PATH_ABANDON第 10.1 节

表 5 中定义的以下传输错误代码应添加到“QUIC 传输错误代码”中 注册表在“QUIC协议”标题下。

表 5:多路径 QUIC 的错误代码
价值法典描述规范
待定(实验使用0xba01)MP_PROTOCOL_VIOLATION多路径协议冲突第11节

13. 安全注意事项

待定

14. 贡献者

本文档是作者的合作,结合了三个提案的工作。 参与原始提案之一的其他贡献者是:

  • 清安
  • 李振宇

15. 致谢

待定

16. 参考资料

16.1. 规范性参考文献

[QUIC-TLS]

汤姆森,M.,编辑。和S.特纳,编辑。,“使用 TLS 保护 QUIC”,RFC 9001的,DOI: 10.17487/RFC9001, 五月 2021,<Information on RFC 9001 » RFC Editor>.

[QUIC-运输]

艾扬格,J.,编辑。和M.汤姆森,编辑。,“QUIC:基于UDP的多路复用安全传输”,RFC 9000的,DOI: 10.17487/RFC9000, 五月 2021,<Information on RFC 9000 » RFC Editor>.

[RFC2119]

布拉德纳,S.,“RFC中用于指示需求级别的关键字”,BCP 14 (英语),RFC 2119的,DOI: 10.17487/RFC2119, 三月 1997,<Information on RFC 2119 » RFC Editor>.

[RFC3629]

耶尔格,F.,“UTF-8,ISO 10646 的转换格式”,性病 63,RFC 3629的,DOI: 10.17487/RFC3629, 十一月 2003,<Information on RFC 3629 » RFC Editor>.

[RFC8174]

莱巴,B.,“RFC 2119 关键字中大写与小写的歧义”,BCP 14 (英语),RFC 8174 中,DOI: 10.17487/RFC8174, 五月 2017,<Information on RFC 8174 » RFC Editor>.

16.2. 信息参考

[I-D.bonaventure-iccrg-调度程序]

博纳文图尔,O.,皮罗,M.,康宁克,Q.D.,贝尔茨,M.,帕施,C.和M. 修正,“多路径调度程序”,工作进行中,互联网草稿,draft-bonaventure-iccrg-schedulers-02, 25 10月 2021,<https://www.ietf.org/archive/id/draft-bonaventure-iccrg-schedulers-02.txt>.

[I-D.liu-多路径-quic]

刘彦,马,Y.,惠特玛,C.,安,Q。和李志强,“QUIC 的多路径扩展”,工作进行中,互联网草稿,draft-liu-multipath-quic-04, 5 九月 2021,<https://www.ietf.org/archive/id/draft-liu-multipath-quic-04.txt>.

[奥利娅]

哈利利,R.,加斯特,N.,波波维奇,M.,Upadhyay,美国和J.-Y.勒布德克,“MPTCP 不是帕累托最优的:性能问题和可能的解决方案”,第八届新兴网络实验与技术国际会议论文集,ACM,2012 年。

[QUIC-不变量]

汤姆森,M.,“QUIC 的版本无关属性”,RFC 8999的,DOI: 10.17487/RFC8999, 五月 2021,<Information on RFC 8999 » RFC Editor>.

[QUIC-恢复]

艾扬格,J.,编辑。和I.斯威特,编辑。,“QUIC 丢失检测和拥塞控制”,RFC 9002的,DOI: 10.17487/RFC9002, 五月 2021,<Information on RFC 9002 » RFC Editor>.

[QUIC-时间戳]

惠特玛,C.,“用于测量单向延迟的 Quic 时间戳”,工作进行中,互联网草稿,draft-huitema-quic-ts-06, 12 九月 2021,<https://www.ietf.org/archive/id/draft-huitema-quic-ts-06.txt>.

[RFC6356]

雷丘,C.,汉德利,M.和D.维希克,“多路径传输协议的耦合拥塞控制”,RFC 6356的,DOI: 10.17487/RFC6356, 十月 2011,<Information on RFC 6356 » RFC Editor>.

作者地址

Yanmei Liu
Alibaba Inc.
Email: miaoji.lym@alibaba-inc.com
Yunfei Ma
Alibaba Inc.
Email: yunfei.ma@alibaba-inc.com
Quentin De Coninck
UCLouvain
Email: quentin.deconinck@uclouvain.be
Olivier Bonaventure
UCLouvain
Email: olivier.bonaventure@uclouvain.be
Christian Huitema
Private Octopus Inc.
Email: huitema@huitema.net
Mirja Kuehlewind (editor)
Ericsson
Email: mirja.kuehlewind@ericsson.com

这篇关于QUIC 的多路径扩展的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1043736

相关文章

csu 1446 Problem J Modified LCS (扩展欧几里得算法的简单应用)

这是一道扩展欧几里得算法的简单应用题,这题是在湖南多校训练赛中队友ac的一道题,在比赛之后请教了队友,然后自己把它a掉 这也是自己独自做扩展欧几里得算法的题目 题意:把题意转变下就变成了:求d1*x - d2*y = f2 - f1的解,很明显用exgcd来解 下面介绍一下exgcd的一些知识点:求ax + by = c的解 一、首先求ax + by = gcd(a,b)的解 这个

科研绘图系列:R语言扩展物种堆积图(Extended Stacked Barplot)

介绍 R语言的扩展物种堆积图是一种数据可视化工具,它不仅展示了物种的堆积结果,还整合了不同样本分组之间的差异性分析结果。这种图形表示方法能够直观地比较不同物种在各个分组中的显著性差异,为研究者提供了一种有效的数据解读方式。 加载R包 knitr::opts_chunk$set(warning = F, message = F)library(tidyverse)library(phyl

Spring框架5 - 容器的扩展功能 (ApplicationContext)

private static ApplicationContext applicationContext;static {applicationContext = new ClassPathXmlApplicationContext("bean.xml");} BeanFactory的功能扩展类ApplicationContext进行深度的分析。ApplicationConext与 BeanF

PHP7扩展开发之数组处理

前言 这次,我们将演示如何在PHP扩展中如何对数组进行处理。要实现的PHP代码如下: <?phpfunction array_concat ($arr, $prefix) {foreach($arr as $key => $val) {if (isset($prefix[$key]) && is_string($val) && is_string($prefix[$key])) {$arr[

PHP7扩展开发之字符串处理

前言 这次,我们来看看字符串在PHP扩展里面如何处理。 示例代码如下: <?phpfunction str_concat($prefix, $string) {$len = strlen($prefix);$substr = substr($string, 0, $len);if ($substr != $prefix) {return $prefix." ".$string;} else

PHP7扩展开发之类型处理

前言 这次,我们将演示如何在PHP扩展中如何对类型进行一些操作。如,判断变量类型。要实现的PHP代码如下: <?phpfunction get_size ($value) {if (is_string($value)) {return "string size is ". strlen($value);} else if (is_array($value)) {return "array si

PHP7扩展开发之依赖其他扩展

前言 有的时候,我们的扩展要依赖其他扩展。比如,我们PHP的mysqli扩展就依赖mysqlnd扩展。这中情况下,我们怎么使用其他扩展呢?这个就是本文讲述的内容。 我们新建立一个扩展,名字叫 demo_dep , 依赖之前的say扩展。 在demo_dep扩展中,我们实现demo_say方法。这个方法调用say扩展的say方法。 代码 基础代码 确保say扩展的头文件正确安装到了php

PHP7扩展开发之函数方式使用lib库

前言 首先说下什么是lib库。lib库就是一个提供特定功能的一个文件。可以把它看成是PHP的一个文件,这个文件提供一些函数方法。只是这个lib库是用c或者c++写的。 使用lib库的场景。一些软件已经提供了lib库,我们就没必要再重复实现一次。如,原先的mysql扩展,就是使用mysql官方的lib库进行的封装。 在本文,我们将建立一个简单的lib库,并在扩展中进行封装调用。 代码 基础

PHP7扩展开发之对象方式使用lib库

前言 上一篇文章,我们使用的是函数方式调用lib库。这篇文章我们将使用对象的方式调用lib库。调用代码如下: <?php $hello = new hello(); $result = $hello->get(); var_dump($result); ?> 我们将在扩展中实现hello类。hello类中将依赖lib库。 代码 基础代码 这个扩展,我们将在say扩展上增加相关代码。sa

PHP7扩展开发之流操作

前言 啥是流操作?简单来讲就是对一些文件,网络的IO操作。PHP已经把这些IO操作,封装成流操作。这节,我们将使用PHP扩展实现一个目录遍历的功能。PHP示例代码如下: <?phpfunction list_dir($dir) {if (is_dir($dir) === false) {return;} $dh = opendir($dir);if ($dh == false) {ret