研究团队对比分析QUIC协议与WebRTC在XR远程渲染中的性能表现
团队对 MoQ、RoQ 和 WebRTC 协议进行了全面分析，重点研究了它们在集成到用于 Wi-Fi 和 5G 网络环境中专用 XR 应用的远程渲染服务时的延迟性能
（映维网Nweon 2025年09月23日）XR应用的激增推动了对高效远程渲染解决方案的需求。在一项研究中，西班牙巴斯克研究与技术联盟和巴斯克大学团队重点探索了虚拟环境中的全息会议及其所需的上行和下行媒体传输能力。
通过研究基于 QUIC 的媒体传输、基于 QUIC 的实时传输协议以及 WebRTC，研究人员评估了它们在 Wi-Fi 和 5G 网络上的延迟性能。与 WebRTC 相比，基于 QUIC 的协议预计在延迟方面有约 30% 的改进，在连接启动方面有约 60% 的改进。实验设置使用实时视频流协议传输远程渲染的虚拟体验，将内容提供给参与者。
研究结果有助于理解流传输协议的成熟度，特别是在开源框架内，并评估它们在支持对延迟敏感的 XR 应用方面的适用性。研究强调了不同远程渲染场景下特定协议的优势，为未来 XR 通信解决方案的设计提供了参考。
对远程渲染系统的需求正在增长。用于游戏和虚拟化环境的现代XR应用变得要求极高。然而，硬件需求同样显著增加。为辅助、教育和娱乐开发环境现在需要详细的场景并为任何地方的用户提供远程可访问性。这需要高硬件能力和低延迟流传输。因此，远程渲染系统至关重要，它使用户能够访问本地可能无法获得的高性能硬件。
诸如 WebRTC之类的协议目前用于 XR 中以实现低延迟、实时通信 。然而，随着新的HTTP/3的出现，UDP QUIC协议正在作为一种替代方案。基于 UDP，QUIC 简化了连接协商和数据传输，同时引入了新颖的功能，如跨网络连接迁移、集成的端到端加密、流多路复用和多路径传输。它同时具有更高效的拥塞管理特性，使其成为现代互联网应用的一个强大选择。
QUIC 相较于 TCP（和 UDP 等传统协议取得了显著进步，使其成为提升 XR 应用性能和灵活性的有前景的解决方案。其设计目标是在容量和影响力方面都超越 WebRTC。XR 应用尤其具有挑战性，因为它们在延迟、吞吐量使用和对字节丢失的容忍度方面有严格的性能要求。因此，研究最合适的协议和通信栈既是必要的，同时具有高度相关性。为了测试每种分析选项的影响，团队在实验性和私有的 5G 独立组网（SA）网络的边缘基础设施部署了一个渲染服务实现。所述服务使用所研究的通信技术，提供一个包含用户作为被动元素的个性化场景的视频流。
在一个有两个或更多参与者的全息会议系统中，实时通信至关重要。一个潜在用例是现场活动，如音乐会或表演，参与者作为观众或被动客户端。系统包括一个部署在分布式容器化环境中的远程渲染器和一个播放器。在此场景中，沉浸式 XR 体验要求尽可能低的通信延迟。图 1 说明了针对每种分析的协议，远程渲染器与播放器之间提议的通信方式。远程渲染器由两个主要软件组件组成：用 C# 开发的 Unity 应用程序，以及使用 Gstreamer 库开发并用 C++ 编写并动态链接到主应用程序的本机渲染插件。
主 Unity 应用程序作为骨干，协调不同组件之间的交互。它基于 Unity 渲染引擎，并利用 NVIDIA GPU 的能力来处理嵌入在 VR 场景中的异构内容（包括音频和体积视频），并生成渲染后的原始音频和 360度 视频流。本机渲染插件是一个自定义的 Unity 插件，充当主 Unity 应用程序与负责创建特定于协议的多媒体管线的多媒体框架之间的桥梁。在开发中，团队实现了 GStreamer 框架，而所述框架通过其库为多种协议提供编码和通信功能。
通过调用 GStreamer 的本机应用程序接口来构建和管理媒体处理管道以集成 GStreamer。GStreamer element appsrc 能够将渲染后的视频缓冲区注入 GStreamer 管道，随后使用 NVIDIA 硬件编码器进行编码。视频始终使用 H.264 编解码器进行编码。管道内的最终操作因协议而异。在这项研究中，团队探索了当前支持的协议及其相应的操作。
基于 RTP 的 WebRTC 首先通过信令服务器进行点对点通信的初始协商。信令服务器使用 RUST 开发，是 Gstreamer 中 WebRTC 元素的官方实现。一旦建立，它会创建一个通信通道，将编码后的流封装在 WebRTC 流中。播放器使用 RUST 开发，负责接收封装的 RTP 流并解码数据。使用 NVIDIA 硬件解码进行解码。
在 RoQ 中，通信协商以点对点模式建立，之后编码后的视频被封装到经过 QUIC 协议适配的 RTP 流中。GStreamer 官方支持此开发；然而，它仍处于早期阶段，缺乏完全稳定性。与 WebRTC 类似，播放器使用 RUST 开发，负责接收流、解封装 RTP 数据包并使用 NVIDIA 硬件解码来解码数据。
对于 MoQ，使用fMP4复用器来封装编码后的流。然后，一个非官方的 GStreamer element实现 MoQ 来传输 fMP4 流。在这种情况下，采用基于中继的通信模型，服务器推送数据，客户端请求数据。中继服务器使用 RUST 开发。由于相关element未包含在官方维护的版本中，它们不如其他替代方案成熟，并且目前不支持音频。与远程渲染器类似，播放器使用非官方的 GStreamer 元素来接收 fMP4 流，然后使用 GStreamer element和 NVIDIA 硬件解码进行解码。
测试台的配置包括用于远程渲染器和播放器之间通信的 5G 和 Wi-Fi。服务器包括远程渲染器、WebRTC 信令服务器和 MoQ 中继服务器。部署在 Kubernetes集群中进行，每个服务被分配到单独的 Pod 中。Kubernetes 部署使用 Helm chart 完成。Kubernetes 集群托管在一台配备 8 个中央处理单元核心、32 GB RAM和具有 8 GB 专用内存的 NVIDIA L4 虚拟图形处理单元的虚拟机上。
实验室网络是一个内部网络，部署了 OpenStack 服务器，专为测试和互联网访问而设计。使用一个在 5 GHz 频段上运行的 Wi-Fi 6 兼容路由器，以促进远程渲染服务器和视频播放设备之间的通信。或者，它可以将流量重定向到 5G 网络而不是 Wi-Fi。Wi-Fi 配置为接入点。
对于 5G 网络，使用了 AMARI Callbox Mini。它配置为使用 N78 频段、20 MHz 带宽、30 MHz 子载波间隔、最大调制为 256 正交幅度调制、下行链路 2 天线和上行链路 1 天线。作为 5G 调制解调器，使用 Quectel RM500Q，它实现了 3GPP 第 15 版，并通过 USB 连接到视频播放器。
为了同步，路由器授予互联网访问权限，允许远程渲染服务器和视频播放设备都充当 NTP 客户端并与公共网络时间协议服务器同步，确保准确的延迟测量。在测试期间，使用 tshark 工具捕获和分析网络流量，服务器作为发送方，播放器作为接收方。双方产生的流量存储在数据包捕获文件中，用于后续的比较和分析。
为了比较 WebRTC、MoQ 和 RoQ 协议，设计了两项测试，涉及网络数据包捕获和图像捕获以测量传输和接收时间。
第一项测试测量在 Wi-Fi 6 和 5G 网络上建立客户端与服务器通信所需的平均时间（启动时间）以及端到端延迟。渲染的视频使用 H.264 编解码器编码，比较三种配置：1080p 15 Mbps、720p 10 Mbps 和 480p 5 Mbps。在所有配置中，视频以 30 FPS 渲染，编码时使用图像组（GOP）大小为 5 和主配置文件。另外，测量远程渲染器中编码期间的 CPU 和 GPU 使用率的资源使用情况，而在播放器中，则分析了解码期间的 CPU 和 GPU 使用情况。
表 I 展示了这第一项测试的结果，突出了以下关键观察结果：
启动时间测量表明，基于 QUIC 的协议优于 WebRTC，主要是因为 WebRTC 需要协商过程来建立通信路径，而 QUIC 协议只需要执行 UDP 握手。类似地，MoQ 的启动性能优于 RoQ。这是因为在完成握手后，RoQ 必须等待传输开始，而 MoQ 已经向中继器生成流量，只需要请求重定向中继服务器的流量。最后，编码参数不影响启动时间，因为测量只考虑到第一帧接收完毕所经过的时间。
关于网络差异，Wi-Fi 网络表现出比 5G 更好的启动时间，大约有 200 毫秒的改进。这种差异可能源于 5G 需要经过核心网路由，而 Wi-Fi 作为直接接入点运行。
在延迟比较中，RoQ 在三种协议中实现了最佳性能，比 WebRTC 提高了 90 毫秒。然而，由于 MoQ 使用中继进行服务器和播放器之间的通信，其延迟值也最高，这使延迟增加了约 100%。在编码参数方面，观察到具有最低比特率和分辨率的配置导致最低延迟，而随着编码参数（比特率和分辨率）的增加，延迟也会增加。
关于网络差异，5G 网络的表现优于 Wi-Fi，延迟减少范围在 30 到 100 毫秒之间可变。在这种情况下，由于通信已经建立，路由不会影响延迟，从而改善了延迟值。此外，由于没有竞争流量，两种网络都表现出良好的性能。
关于远程渲染器和播放器的 CPU 和 GPU 使用情况，结果可见表 II。
编码期间的 CPU 消耗超过 100%，因为服务器使用多个核心进行处理。CPU 测量值代表了协议进行渲染、处理和传输的总使用百分比。最高的 CPU 消耗在渲染方面。另一个重要的观察是，CPU 使用率随着视频参数（比特率和分辨率）的增加而增加。这是因为更高的渲染和处理参数会产生更多数据，需要额外的计算资源进行处理。最后，在比较协议时，WebRTC 表现出最低的 CPU 消耗。这可以归因于它们的成熟度以及现有库对高效资源利用的优化，相比之下，MoQ 和 RoQ 仍处于开发的早期阶段。
编码期间的 GPU 消耗随着编码参数的提高而增加。这是由于随着比特率和分辨率的增加，处理的数据量更高。值得注意的是，在 480p/5Mbps 配置中，GPU 使用率报告为 0%。这是因为实际使用率低于 1%，并且测量系统缺乏显示更精确值的粒度。
关于协议之间的差异，所有协议都表现出相同的 GPU 消耗。由于编码参数在所有协议中保持相同，预期的 GPU 使用率保持一致。
关于播放器上解码期间的资源消耗，观察到更高的编码参数（比特率和分辨率）会导致资源使用增加。在 GPU 利用率方面，所有协议都表现出相似的消耗，因为视频流在它们之间保持不变。然而，在 CPU 使用方面，WebRTC 消耗的资源最多，这是因为其接收所需的 GStreamer element更复杂、更多。另一方面，RoQ 的资源密集度最低，因为其播放器实现更简单。然而，它也更容易出错，因为它缺乏处理传输错误的机制，表明其实现尚不成熟。
在第二项测试中，使用 tshark 工具获得的 PCAP 文件，分析每个协议，评估播放器的吞吐量使用、抖动和字节丢失。网络流量捕获两分钟，测试在 5G 和 Wi-Fi 网络上进行。在这种情况下，远程渲染器渲染的视频使用 H.264 编码，分辨率为 1080p，帧率为 30 FPS，比特率为 15 Mbps。
表 III 展示了第二项测试的结果。其中一些结果表明，QUIC 库和实现仍处于开发的早期阶段，成熟度有限。
吞吐量测量旨在评估协议的开销效率。结果表明，RoQ 实现了最低的数据传输值，其次是 WebRTC，表明这些协议的开销较低。相比之下，MoQ 表现出最高的数据传输值，可能是由于固有的协议开销。关于 5G 和 Wi-Fi 网络之间的差异，未观察到吞吐量的显著变化。
在抖动方面，WebRTC 在两种网络上都表现出最稳定的性能，表明它具有更稳健的数据包到达处理和更好的延迟抖动补偿。相比之下，RoQ 和 MoQ 在 Wi-Fi 上表现出更高的抖动，尽管它们在 5G 网络上的性能有所改善。这表明这些协议在数据包处理方面可能仍缺乏成熟度。
最后，关于字节丢失，WebRTC 表现出与 MoQ 和 RoQ 相当或更好的性能。在使用两种基于 QUIC 的协议进行的测试中，在 Wi-Fi 环境中观察到更高的字节丢失。相比之下，5G 网络显示出改进的性能，其值与 WebRTC 相似。
相关论文：Streaming Remote rendering services: Comparison of QUIC-based and WebRTC Protocols
总的来说，团队对 MoQ、RoQ 和 WebRTC 协议进行了全面分析，重点研究了它们在集成到用于 Wi-Fi 和 5G 网络环境中专用 XR 应用的远程渲染服务时的延迟性能。该分析强调了高质量、低延迟传输的重要性，特别是对于需要交互式视听内容和体积数据的应用。另外，所提出的解决方案部署在分布式 Kubernetes 环境中，便于未来基于云的基础设施的开发和实验。
结果表明，基于 QUIC 的协议（如 RoQ）有潜力在低延迟传输方面超越 WebRTC，RoQ 实现了最快的连接启动，但由于其通信机制，总体延迟较高。另外，他们对 QUIC 框架和库的开源框架成熟度进行了评估，强调尽管 WebRTC 高度优化，但 QUIC 仍处于发展和标准化的早期阶段。
对于未来的研究，团队建议扩展研究范围，探索 QUIC 多路径在处理多个并发流（包括视频、音频和数据）时的性能。同时，研究双向通信的可行性和影响，将为增强交互式远程渲染应用提供宝贵的见解。
