QUIC作为WebRTC中的多路复用层-QUIC as Multiplexing Layer in WebRTC

本论文探讨了将QUIC协议用作 WebRTC统一传输层的潜力，以改善媒体流和数据流的共存方式。当前的 WebRTC 架构通常依赖相互独立且缺乏协调的协议栈来进行视频传输和文件共享，因此常常面临带宽竞争和高延迟问题。研究人员开发了一个原型系统，将实时媒体和数据通道复用到单一连接中，并采用专门的基于优先级的调度算法。实验结果表明，该方法能够有效消除传统数据通道造成的抖动，同时确保资源的公平分配。通过将这些流整合到同一个拥塞控制器之下，该系统即使在进行文件传输时也能保持高质量的视频性能。该研究表明，QUIC 是构建更稳定、更高效的实时通信系统的一种可行替代方案。

以下是FreeSWITCH中文社区和大家分享的中文翻译内容。如果读者想了解具体原文内容，请大家下载此论文原文版本（QUIC as Multiplexing Layer in WebRTC）做进一步学习，原文下载链接在文章底部。

00

摘要说明

WebRTC是一系列协议的集合，使应用程序能够在网页浏览器中实现实时点对点通信系统。它包括媒体流传输能力和数据通道协议，允许对等方交换任意数据。独立协议和拥塞控制器用于媒体流传输和数据消息传递可能导致带宽竞争和更高的延迟和抖动。之前的工作提出了一种耦合机制，以缓解协议之间不受控制的资源竞争。通过QUIC上的RTP，正在标准化实时媒体的替代传输。由于QUIC出色的多路复用能力，它为解决WebRTC中公平资源共享的问题提供了新机会，同时确保实时媒体流的低延迟。尽管QUIC上的RTP被认为是WebRTC中的替代传输协议，但QUIC目前并不计划用于WebRTC数据通道。在本文中，我们实现并评估了一个原型应用程序，使用QUIC作为同时流媒体和数据通道的替代协议，证明它可以有效减少媒体流中的延迟和抖动，同时与数据通道流公平共享带宽。

1

介绍

视频会议已成为全球许多人生活中不可或缺的一部分，从一对一会议到涉及数百名参与者的大型会议电话，以保持与朋友和家人的联系并支持远程工作。今天使用的许多视频会议工具依赖于Web实时通信（WebRTC）框架，该框架包括一系列协议和应用程序编程接口（API），允许在任何浏览器中直接进行实时通信。例如，IETF 定期召开会议，使用 WebRTC 将现场会议室与数百名远程参与者连接起来 [15]。

WebRTC 包括用于实时音频和视频流传输的协议，以及用于交换任意数据的协议，例如文本聊天消息或文件 [12]。媒体和数据传输的机制使用两个独立的协议栈，当它们并行运行时，使用独立的拥塞控制器竞争相同的带宽。

当多个流共享同一路径时，会出现一个问题：我们如何确保它们之间的公平资源共享？这个问题最早是在多个 TCP 连接并行使用时被识别出来的 [3]，导致了拥塞管理器 (CM) [4] 的发展。在 WebRTC 中，当实时媒体流与数据通道流共享同一链路时，这个问题对感知质量特别有害，因为 SCTP 使用的基于丢包的拥塞控制器会导致高抖动和延迟，从而显著降低视频会议的交互性。

IETF 的 RTP 媒体拥塞避免技术 (RMCAT) 工作组识别了这个问题。它发布了 RFC 8836 [19]，列出了交互式实时媒体的拥塞控制要求，包括对不同协议使用的拥塞控制器之间状态共享的建议。该工作组还发布了两个 RFC，分别针对 RTP 媒体的耦合拥塞控制 [17] 和 RTP 媒体的共享瓶颈检测 [11]。Islam 等人扩展了耦合拥塞控制机制，以解决媒体和数据通道之间共享瓶颈所产生的不公平和延迟问题 [16]。

在本文中，我们提出了一种替代方案，以实现公平的协作带宽共享，而不影响实时媒体流的延迟，使用 QUIC 作为 WebRTC 的传输协议。基于 QUIC 的 RTP (RoQ) 正在接近作为实验性 RFC 发布 [10]，正在进行必要的信令机制的工作，以使其适合在 WebRTC 中使用 [6]。然而，QUIC 作为 WebRTC 数据通道的传输方式尚未得到广泛探索，且在单个连接中复用媒体和数据流的使用是 RoQ 互联网草案 [10] 中列出的开放研究问题之一。

图1：RTP 媒体流和使用 SCTP 的并发数据通道的传输速率（上）和 RTP 单向延迟（下）。

我们通过实施和实验评估以下内容，来解决 RoQ Internet-Draft 中需要额外实验的开放问题：1）在 QUIC 之上的应用层协议，能够在单一连接中复用 RTP 和数据通道；2）适合通过 QUIC 传输实时媒体的拥塞控制算法；3）一个调度和优先级算法，允许根据应用程序的偏好动态分配带宽给各个流。

我们首先展示测量结果，突出 WebRTC 中上述问题（§2），然后回顾相关工作和替代解决方案。接着我们展示我们的设计（§3）、实验实现（§4）及其评估（§5）。

01

2

背景说明

为了说明 WebRTC 中并发数据通道和媒体传输的问题，我们重现了 Islam 等人发布的实验 [16]，其中使用 RTP 的媒体流与使用 SCTP 的数据通道竞争。这个实验类似于 RFC 7478 [12] 中列出的简单视频通信服务与文件交换用例，以及 WebRTC 扩展用例 [1] 中列出的文件共享用例。这些用例的一个重要要求是，文件共享流的拥塞控制器不会与媒体流进行激烈竞争，因为这会降低媒体流的延迟和质量。

我们使用 Pion WebRTC 库1 和其默认的基于丢失的 SCTP 拥塞控制器实现了该实验。RTP 流使用 Pion 中包含的带宽估计算法，该算法基于 GCC。§5 解释了我们在该实验中使用的测试环境和应用程序。

图1 显示了每个流的传输速率和 RTP 流的单向延迟。该图说明了两个问题：1）带宽估计算法的目标比特率，因此视频流的比特率，保持非常低，无法与数据通道竞争。2）媒体流经历了非常高的抖动，因 SCTP 的基于丢失的拥塞控制器而导致高低延迟之间的波动。

我们可以通过使用更激进的拥塞控制器或为媒体流配置最小目标速率来解决第一个问题。然而，第二个问题不能仅通过更改媒体流的拥塞控制算法来解决。基于丢包的拥塞控制器在网络中交替填充和排空任何队列，并且总会在共享瓶颈链路上导致高延迟和抖动。如果媒体流与一个无关的流（例如，具有基于丢包的拥塞控制器的TCP连接）共享一个瓶颈链路，而这个流超出了WebRTC应用程序的控制范围，那么就无法解决这个问题。然而，在WebRTC中，当一个视频会议应用程序还为会议参与者提供文件共享时，因此同时使用WebRTC媒体流和数据通道，这两个协议都在同一个应用程序的控制之下。

避免同一WebRTC应用程序的媒体流和数据流之间自我造成的延迟和不公平带宽共享的一个选项是Islam等人提出的RTP和SCTP的拥塞控制器的耦合机制[16]。或者，这两个协议可以使用新的低延迟、低丢失、可扩展吞吐量（L4S）架构[5, 27]，这可以为两个协议保证非常低的延迟和丢失。然而，L4S依赖于网络合作，目前尚不清楚如何动态分配带宽份额给不同的流。应用程序也可以通过限制发送速率更谨慎地使用数据通道。实现将会复杂，并且可能只会产生次优结果，因为API不支持媒体流和数据通道之间的细粒度调度和优先级，使得在不引起不公平或延迟问题的情况下充分利用可用带宽变得具有挑战性。

在下面，我们描述了一种新颖的替代解决方案，使用QUIC、RoQ规范以及将数据通道映射到同一连接的扩展。我们设计的优点在于只需要一个协议栈和拥塞控制器，使得更容易利用可用带宽，同时在不同流之间公平共享，而不会导致高延迟或抖动。

02

3

架构

在本节中，我们介绍了使用QUIC作为WebRTC多路复用层的解决方案架构。图2显示了今天WebRTC栈与我们提出的替代方案之间的高层比较。§3.1将RTP和数据通道映射到共享的QUIC连接。§3.2描述了QUIC中复用这些协议的拥塞控制机制，§3.3介绍了一种简单的基于优先级的调度算法，为各个流分配不同的带宽份额。

3.1

应用层协议

如图2所示，两个协议栈都使用IP和UDP。在此基础上，WebRTC使用DTLS生成SRTP加密密钥并保护SCTP关联，后者作为数据通道的传输协议。QUIC已经结合了DTLS和SCTP提供的许多特性。最重要的是，它默认包含TLS 1.3，支持复用的可靠流，并作为扩展，支持不可靠的报文。QUIC流是一个有序的字节流，可靠地传递且独立于其他流，以避免头部阻塞。不可靠的报文是由网络的最大传输单元（MTU）限制大小的消息，并以尽力而为的方式传递，即不对丢失的报文进行重传。

3.1.1 QUIC上的RTP。RoQ [10]允许通过QUIC报文和流发送RTP包。作为QUIC报文发送的RTP包必须适合相应的MTU，并且不会被QUIC重传。通过QUIC流发送的RTP包可以在单个QUIC流上发送，也可以分散在多个QUIC流上。后者避免了连续RTP包之间的头部阻塞。每个流形成一个一个或多个RTP包的序列，这些包将可靠地按发送顺序传递。这样的RTP包序列可以包括单个帧的所有RTP包，或一组图像的所有帧，一个I帧后跟几个只能在前面的帧解码后才能解码的P帧。为了在单个QUIC连接上复用多个RTP流，RoQ引入了流标识符。流标识符是一个整数，附加在每个QUIC流或报文前，标识所有在该流或报文上发送的RTP包所属的RTP流。

3.1.2如图2所示，两个协议栈都使用IP和UDP。在此基础上，WebRTC使用DTLS生成SRTP加密密钥并保护SCTP关联，后者作为数据通道的传输协议。QUIC已经结合了DTLS和SCTP提供的许多特性。最重要的是，它默认包含TLS 1.3，支持复用的可靠流，并作为扩展，支持不可靠的报文。QUIC流是一个有序的字节流，可靠地传递且独立于其他流，以避免头部阻塞。不可靠的报文是由网络的最大传输单元（MTU）限制大小的消息，并以尽力而为的方式传递，即不对丢失的报文进行重传。

3.1.3 复用RTP和数据通道。QUIC要求使用应用层协议协商（ALPN）来识别任何QUIC连接上使用的协议。在协商中使用的ALPN令牌所定义的协议必须指定应用程序如何利用QUIC连接。由于RoQ仅定义了RTP包到QUIC的映射，但不包括数据通道，因此必须定义一个新的ALPN令牌，以识别在QUIC连接中复用RTP和数据通道的协议。此外，新协议还必须解释如何复用RTP和数据通道。复用可以基于有效载荷头进行，类似于传统WebRTC复用多个协议的方式[2, 22, 23]，通过为不同协议保留不同的QUIC流类型，或者通过协调RoQ和数据通道使用的流标识符[8]。在这项工作中，我们使用最后一种方法，并为RoQ和数据通道硬编码流标识符。

3.2

拥塞控制和带宽估计

为了保持实时媒体的低延迟，开发了GCC、SCReAM和NADA等专门的拥塞控制器[14, 20, 21, 28]。GCC在WebRTC中广泛用于RTP媒体。基于丢包的拥塞控制器，如NewReno或Cubic，不适合实时媒体，因为它们造成的排队延迟、数据包丢失和抖动。

QUIC RFC包括与NewReno类似的拥塞控制算法，但允许实现选择替代算法，只要满足某些条件[18]。在之前的工作中，我们显示使用RoQ的应用程序可以通过RTP控制协议（RTCP）反馈消息在应用层实现实时媒体的带宽估计[7]。然而，在应用层实现RTP带宽估计仅在连接专门用于RTP时有效。如果多个协议共享连接，则需要在QUIC层实现拥塞控制和带宽估计。

实时拥塞控制算法，如GCC、NADA和SCReAM，不能轻易在QUIC中实现，因为它们依赖于单向延迟测量，这需要在确认中包含接收时间戳。虽然RTCP提供了接收时间戳的特定反馈消息[13, 24]，但QUIC确认中没有。QUIC扩展以将接收时间戳添加到确认中，目前正在QUIC工作组开发中[26]。

3.3

带宽共享：调度和优先级

我们在同一QUIC连接上复用的两个协议具有不同的特性、带宽需求和延迟要求。实时流通常以可配置的速率生成数据，这可能由于编码器超调而波动，例如在编码关键帧时。另一方面，数据通道不一定受限于速率。比如，在视频会议的背景可以使用数据通道传输固定大小的文件。例如，考虑上传用于会议通话的幻灯片。

我们寻求将可用带宽的不同份额分配给各个RTP流或数据通道。然而，由于编码器输出可能会波动，我们不想严格执行实时流的限制，因为这会导致编码器暂时超出限制时的延迟。相反，当编码器超过分配的目标速率时，我们将暂时降低数据通道的速率。如果编码器持续超过分配的带宽，可能会导致数据通道的饥饿，应用程序可以通过调整编码器的配置目标速率来避免这种情况。

在我们的架构中，我们通过结合QUIC流的调度算法和限制QUIC连接传输速率的节奏器来满足这些要求，该速率由带宽估计算法提供的目标速率确定。

我们使用简单的优先级队列为RTP和数据通道流分配不同的优先级，以对QUIC流进行排序。我们使用两个优先级类别，一个用于RTP，一个用于数据通道。在每个类别中，流根据创建时间排序，这意味着较旧的RTP数据包或数据通道消息具有比较新的更高优先级。如果由于数据包丢失需要重新传输某些流数据，较旧的数据将优先传输。为了避免对旧RTP数据包进行无休止的重传，应用程序可以重置QUIC流，丢弃所有未完成的数据，例如，在超时到期时。

我们优先考虑实时媒体流而不是数据通道流，以确保我们始终在没有实时媒体流可用时才调度数据通道流。虽然我们将实时媒体流配置到低于整个连接的可用带宽的目标速率，但只要有数据可以发送且节奏器有预算可用，数据通道流就可以始终发送数据。因此，数据通道将自动消耗媒体流未使用的所有剩余带宽。

我们可以通过为数据通道添加人工速率限制来分配带宽，而不是优先考虑媒体流。然而，所有流使用目标速率会增加应用层的复杂性，因为应用程序必须在媒体编码器以低于或高于其配置目标速率的速率生成媒体时动态增加或减少数据通道的速率限制，以避免媒体流中延迟的增加。

032

4

实现方式

我们使用quic-go2、Pion和GStreamer3实现了架构的原型。该原型支持使用SRTP和SCTP的传统WebRTC，以及我们提议的架构作为一种替代传输协议，将RTP和数据通道复用在单个QUIC连接上。RoQ和数据通道协议作为quic-go的小包装器实现，用于写入、读取和复用RTP数据包和数据通道消息到QUIC流和数据报。

我们对quic-go实现进行了分叉，添加了在确认中接收时间戳反馈的支持，并实现了§3.3中描述的基于优先级的流调度。我们还禁用了默认的拥塞控制器，并用一个简单的基于速率的节奏器替换它，该节奏器可以由应用程序根据带宽估计算法配置为不同的速率。

我们使用在Pion中实现的带宽估计算法，基于GCC，估计单向延迟梯度和可用网络带宽。两个协议中使用相同的实现，唯一的区别是用于估计单向延迟梯度的包类型和包时间戳反馈。在QUIC中，时间戳基于QUIC数据包，反馈作为QUIC确认帧的一部分传输。相反，在传统的WebRTC中，我们使用RTP数据包时间戳，反馈通过RTCP传输。

我们使用估计的带宽配置媒体编码器的目标速率。当QUIC连接同时用于媒体和数据通道传输时，我们将编码器的目标速率配置为可用带宽的一个比例，留出剩余的带宽用于数据通道。当没有数据通道处于活动状态时，我们仍然将媒体目标比特率降低0.8，以考虑QUIC数据包头和控制帧的额外开销。

04

4

实现方式

图3：仿真测试平台设置。

我们在使用Linux网络命名空间和虚拟网络接口的网络仿真中评估我们的原型实现。图3显示了测试平台拓扑。我们创建了两个命名空间，作为发送方和接收方之间的路由器。两个路由器之间的链接模拟了一个具有固定带宽和延迟的瓶颈链接，我们使用tc-tbf和tc-netem进行了配置。

我们以1 Mbit/s、5 Mbit/s和10 Mbit/s的带宽限制以及10毫秒、25毫秒和50毫秒的对称单向传播延迟进行了实验。我们根据RFC 8867 [25]中描述的实时媒体拥塞控制测试用例选择了路径特性。然而，我们排除了动态带宽变化，以在实验中关注容量共享，而不是拥塞控制器如何快速适应变化的网络特性，这将留待未来的工作。

我们在三种不同的设置中评估应用程序。第一种设置仅使用RTP发送单个媒体流，第二种设置同时使用RTP发送媒体流和通过数据通道发送随机数据，第三种设置发送媒体使用RTP的流，在30秒后开始通过数据通道传输10 MB大小的文件。对于所有设置，我们比较使用标准WebRTC通过UDP与通过QUIC的复用协议的版本，如§3所述。我们进行了10次实验。

我们从应用程序和网络收集日志，以评估RTP流和数据通道的性能。我们对两个协议在同一连接上复用时的带宽共享行为感兴趣。对于实时媒体流，我们还测量了RTP数据包的网络延迟，以观察数据通道对实时流延迟的影响。对于数据通道，我们还检查了完成文件传输所需的时间。

5.1

RTP的拥塞控制

我们首先评估用于通过WebRTC和QUIC发送RTP的拥塞控制器。图4显示了RTP流的平均吞吐量和延迟。在没有并发数据通道传输的情况下比较WebRTC和QUIC时，我们发现WebRTC的吞吐量始终略高于QUIC。这个差异是由于在通过QUIC发送仅RTP流时使用了减少的媒体目标比特率，以考虑额外的QUIC头和控制帧开销。在某些情况下，RoQ的延迟也较高。仔细观察图5中的往返时间（RTT）和RTP延迟，额外的延迟并不是由网络延迟引起的，而是由于我们发送方和接收方应用程序的内部缓冲。额外的缓冲是因为RTP流必须与QUIC控制帧共享整体节奏预算。为了为QUIC开销留出足够的余地和尽可能接近估计带宽发送媒体之间存在一个权衡。如果我们将编码速率设置得接近节奏速率，缓冲延迟会增加。如果我们将其设置得低于节奏速率，连接将有效地受到应用程序的限制，拥塞控制器将不会进一步提高目标速率。虽然额外的延迟是不可取的，但我们将优化内部缓冲以减少这种延迟，特别是在低带宽场景中，留待未来的工作。总体而言，实验表明，如果QUIC为确认的数据包提供足够的时间戳反馈，我们可以在QUIC和WebRTC中使用相同的拥塞控制算法实现。

5.2

多路复用RTP和数据通道

接下来，我们将检查实验，包括数据通道。我们比较了使用WebRTC和QUIC的RTP流的吞吐量和延迟，同时与一个持续发送数据的数据通道共享连接。当数据通道使用基于丢包的拥塞控制器时，RTP流受到严重影响。在几乎所有场景中，使用标准WebRTC的RTP流要么实现较低的吞吐量，从而导致较低的媒体质量，要么面临更高的延迟。我们将媒体流的最小目标比特率配置为400 kbit/s，以确保足够的数据传输。在低带宽场景（1 Mbit/s）中，RTP流的平均吞吐量接近配置的最小值，因为拥塞控制器无法与SCTP的基于丢包的拥塞控制器竞争。在具有更高传播延迟的场景中，RTP吞吐量略有改善，但代价是更高的延迟变化。

RoQ达到的吞吐量也低于QUIC连接仅由RTP使用时的吞吐量，但接近配置的带宽估算的50%的限制。数据通道消耗了剩余的带宽。此外，RTP流的观察到的延迟平均值要低得多，并且比与SCTP流竞争时的变化性小。有趣的是，延迟和抖动通常也低于QUIC连接专门用于RTP时的情况。这是因为在与数据通道共享连接时，整体QUIC连接的速率远高于编码器的目标速率。由于优先级算法总是优先考虑RTP数据包，因此RTP数据包的内部缓冲较少，数据通道有效地帮助探测更高的带宽。

QUIC多路复用的另一个优点是，应用程序可以自由选择如何在流之间分配可用带宽，以改善媒体质量或加快通过数据通道的传输。

5.3

延迟文件传输

作为一个更现实的用例，我们进行了一次实验，传输一个10 MB的文件，在媒体流开始30秒后开始。这一次，媒体流可以在没有文件发送时使用全部带宽，但在文件传输时，50%的带宽分配给文件传输。

图6显示了在带宽为5 Mbit/s和传播延迟为10 ms的场景中，流之间的速率如何共享。在WebRTC版本中，由于拥塞控制器更激进的行为，数据通道消耗了更大份额的带宽。当使用QUIC时，媒体速率仅降低到约50%。由于QUIC中数据通道的份额较小，文件传输持续时间增加。在总共10次试验中，使用QUIC的文件传输平均需要38.77秒，而在WebRTC中则为25.03秒。为了加快文件传输，应用程序可以为数据通道分配更高的带宽份额，从而降低媒体质量。相比之下，在传统的WebRTC中，应用程序无法控制分配的份额，也不能动态调整它们。我们多路复用的另一个优点是，一旦文件传输完成，速率可以立即被媒体流使用，而无需另一个上升阶段。

04

6

结论

在这项工作中，我们实现并评估了QUIC实现中的实时媒体拥塞控制器，并证明它可以达到与传统的UDP WebRTC堆栈相当的性能。我们展示了RoQ结合新的数据通道映射到QUIC，可以消除当今WebRTC实现中在同一瓶颈上发送实时媒体和数据通道时的不公平问题。

我们发现了内部缓冲问题以及在QUIC上发送RTP时连接节奏与设置正确目标比特率之间的冲突。未来，我们计划改善我们应用中的内部缓冲行为。一个潜在的解决方案可能是改善QUIC控制帧调度、我们的流帧调度和我们的节奏器之间的互动。

此外，我们计划扩展我们的评估，包括对具有更动态带宽和延迟特性的实验，并评估替代拥塞控制机制（如L4S）是否以及如何支持WebRTC和QUIC在低延迟下的动态带宽共享。

参考文献

原文链接

https://dl.acm.org/doi/pdf/10.1145/3822163.3827919?download=true