淘宝多路径 quic 服务

来源
：SIGCOMM 2021

内容整理
：尹文沛

论文标题
：XLINK: QoE-Driven Multi-Path QUIC Transport in Large-scale Video Services

论文链接
：https://dl.acm.org/doi/pdf/10.1145/3452296.3472893

摘要
介绍
贡献
主要结果
推动力
体验 vanilla 多路径 QUIC

快速变化的无线链路
异构网络中的路径延迟
vanilla-MP 的部署

XLINK 设计概述
QOE 驱动的调度和路径管理

基于优先级的再注入

QoE 反馈和再注入控制
QoE 感知路径管理
协议和实现
评估

缓冲区级别和成本开销与双阈值
大规模 A/B 测试

极端移动环境下的测试

能量消耗

相关工作
讨论和限制
总结

摘要

XLINK，是一种多路径 QUIC 视频传输解决方案，在淘宝短视频中进行了实验。XLINK 旨在同时应对两个运营挑战：(1) 在稳健性、流畅性、响应性和移动性方面优化用户感知体验质量 (QoE) 以及 (2) 最小化服务提供商（通常是 CDN）的成本开销）。XLINK的核心是利用QUIC作为用户空间协议的机会，直接捕捉用户感知到的视频QoE意图来控制多路径调度和管理。我们克服了诸如多路径队头阻塞、网络异构性和快速链路变化等主要障碍，并平衡了成本和性能。

据我们所知，XLINK 是第一个在生产环境中对多路径 QUIC 视频服务进行大规模实验研究。展示了使用 XLINK 升级到淘宝安卓应用的消费者的超过 300 万次电子商务产品短视频播放的结果。我们的研究表明，与单路径 QUIC 相比，XLINK 在第 99 个百分位视频块请求完成时间方面实现了 19% 到 50% 的改进，在第 99 个百分位的第一个视频帧延迟方面改进了 32%，重新缓冲率实现了 23% 到 67% 的改进，以 2.1% 的冗余流量为代价。

介绍

视频流（直播或视频点播）现在已成为当今电子商务的核心组成部分。96% 的消费者报告说产品视频对他们的购买决策非常有帮助 [1]。当前的 COVID-19 大流行进一步加速了消费者观看和购买习惯的转变，推动了更多卖家在阿里巴巴、亚马逊、YouTube 和 TikTok 等平台上创建视频内容的需求，并催生了一波网红经济。

淘宝作为全球主要的电子商务服务之一，我们有两个关键观察：首先，短片产品视频停顿和启动延迟显着影响用户满意度。其次，希望看到更多细节并感觉更投入的消费者的需求不断推动视频向更高的数据速率发展。这些观察结果迫切需要更多的无线带宽和更强大的数据传输到可能经历频繁切换的移动设备。使智能手机等多宿主设备能够聚合无线链路的多路径传输是满足上述需求的有前途的解决方案。

事实上，多路径传输的话题在过去的几十年中得到了广泛的关注[4-8]。今天，最广为人知的多路径协议是 RFC 6824 [4] 中的 MPTCP。不幸的是，MPTCP 需要智能手机中的操作系统级支持。对于不是手机制造商的移动应用程序提供商来说，部署成本异常高 2。最近，随着行业向 QUIC [10] 发展，QUIC [7、11、12] 上的多路径扩展已经被引入。与 TCP 相比，QUIC 作为用户空间协议，可以作为应用程序的一部分进行安装和升级，因此作为端到端解决方案的多路径 QUIC 可以快速部署并持续发展 [10]。然而，最近的提议 [7, 13] 旨在支持通用流量，例如网络和批量数据传输，并且没有针对视频进行优化。这些建议在实践中的有效性也尚不清楚。

在本文中，我们提出以下问题：将多路径 QUIC 引入大规模视频服务是否实用且值得？我们发现将过去的多路径解决方案直接应用到我们的大规模产品视频服务中远非简单。首先，为了证明激励措施的合理性，多路径的性能应该不会比单路径差 [6, 16]。然而，我们的部署表明，默认的多路径解决方案在中位数上可能比在更好路径上的单路径交付慢 16%，在 99% 处慢 28%。事实证明，聚合无线资源的有效使用比预期的要难得多。主要障碍之一是由快速变化和异构路径引起的多路径线头 (MP-HoL) 阻塞问题 [6]。阻塞发生在慢路径上较早发送的数据包到达快路径上的数据包之后，导致乱序到达；乱序的数据包没有资格提交给应用程序，因此快速路径必须等待。Wi-Fi、LTE 和 5G 的显着异质性，以及在我们的环境中移动终端的频繁切换，将进一步加剧这个问题 [17]。

多路径 HoL 阻塞的一种解决方案是使用更复杂的数据包调度算法 [18-20]。然而，这些解决方案依赖于对网络特性的预测，这往往是不准确的，特别是对于经历快速变化的链路速率和偶尔的多秒中断的无线链路[21]。其他提议试图传输重复数据包以解耦多路径以缓解问题 [6, 8]。不幸的是，它们会导致大量的流量冗余。例如，我们发现传统的重新注入策略 [6] 在实践中导致视频服务器的总出站流量增加了 15% 以上。当涉及到大规模视频服务时，成本开销尤为重要。过去发送重复数据副本的多路径解决方案可能适用于音频服务 [22]，但它们不适用于视频，因为流量要大得多。

令人惊讶的是，迄今为止，在大规模视频服务中使用多路径的可行性和好处仍不清楚因此，在本文中，我们介绍了我们对 XLINK 的大规模实验研究。XLINK 背后的关键思想是利用 QUIC 作为用户空间协议的机会，直接捕获视频 QoE 意图来控制多路径调度和管理。具体来说：

知道无线链路的不可预测性，我们不追求对网络特性的准确预测。相反，我们依靠客户端的 QoE 反馈来动态控制数据包重新注入在服务器调度程序中的攻击性。XLINK 的调度程序仅在多路径 HoL 阻塞会损害用户感知的 QoE 时才重新注入未确认的数据包，同时实现性能和成本效益。
XLINK 旨在处理多个并发 QUIC 流。由于可以通过并发流下载视频，每个流都请求它的一部分，因此当后期流数据包在重新注入早期流数据包的副本之前排队时，可能会发生流阻塞。通过基于流优先级的重注入，XLINK根据流的紧迫性仔细确定发送顺序，实现更流畅的流体验。
XLINK 针对短视频进行了优化。它引入了基于视频帧优先级的重新注入的第一视频帧加速，它允许视频应用程序在流粒度之外进一步区分视频帧的重要性，以避免视频启动时慢速路径上的飞行数据包的过度延迟.
XLINK 通过 QoE 感知路径管理处理异构网络中的大路径延迟差异。首先，它引入了无线感知的主路径选择，它在多路径初始化过程中处理不同无线技术的路径延迟，提供更快的连接设置。其次，与 MPTCP 不同，XLINK 中的多路径 ACK (ACK_MPs) 不限于同一子流，并且 XLINK 可以灵活地选择 ACK_MPs 的返回路径，从而进一步提高了性能。

这样一来，与过去的方法相比，XLINK 在视频启动延迟、视频重新缓冲率、移动性支持和 CDN 流量开销方面实现了卓越的性能。此外，由于安全和隐私是 QUIC 设计理念的核心，因此应该有一个基本前提，即多路径 QUIC 至少保持与 QUIC 相同的安全级别，并且不会引入额外的问题。我们将 XLINK 设计为 QUIC 的轻量级扩展，同时实现所需的功能和灵活性。

贡献

我们提出了生产环境中多路径 QUIC 视频传输的第一个大规模实验研究，以证明其可行性和可部署性。
我们指出，从根本上解决上述挑战的关键是利用 QUIC 作为用户空间协议，使其能够与应用程序密切交互并使用视频 QoE 进行调度和路径管理。
我们揭示了以前文献中较少讨论的有关性能、成本、移动性、兼容性和网络异构性的实际挑战，并分享了我们应对这些挑战的经验

主要结果

我们对 XLINK 与单路径 QUIC 进行了大规模的 A/B 测试，超过 10 万参与者自愿升级到运行 XLINK 客户端的淘宝 Android 应用程序的测试版，我们在 XLINK 的服务器上部署了淘宝短视频服务。我们的数据集包含超过 300 万次视频播放。我们观察到 XLINK 在第 99 个百分位的视频块请求完成时间方面实现了 19% 到 50% 的改进，第 99 个百分位的第一个视频帧延迟改进了 32%，重新缓冲率提高了 23% 到 67%以 2.1% 的冗余流量为代价。因此，我们认为 XLINK 是朝着在公共互联网上广泛采用多路径 QUIC 迈出的关键一步。

我们想指出，XLINK 利用远程反馈控制多路径数据包重新注入背后的创新超出了端到端视频传输的范围，可以作为通用的高性能多路径传输机制。另一方面，基于流和帧优先级的调度利用了 QUIC 表达视频感知的能力，因此具有更多的 QUIC 特性。

随着视频应用和无线技术的普及，在独立层优化视频和传输的传统一刀切方法将不再满足用户感知 QoE 不断增长的多样性。XLINK 利用 QUIC 的用户空间特性，开创了视频和无线之间更紧密协作的创新。XLINK 的多路径协同作用和应用程序的 QoE 感知的影响超越了短视频，并为其他令人兴奋的研究领域铺平了新的道路，例如直播、360 度视频、增强现实 (AR) 和虚拟现实 (VR) ）。

推动力

XLINK 的发展受到以下趋势的推动：短视频爆炸：近年来见证了由 TikTok、Reels 和 Twitter 等应用驱动的短视频爆炸 [24]。阿里巴巴、亚马逊、Ebay 和 Redfin [1, 25, 26] 等电子商务公司也在转向短视频，以在移动应用中展示在线产品。短视频施加了更严格的 QoE 要求，因为观众对短视频的 QoE 损伤的容忍度低于长视频 [27]。同时，消费者对视频内容的需求正在向 4K 及以上（例如 AR 和 VR）发展，它们可以要求超过 85Mbps 的比特率 [28]。这些变化促使移动设备克服无线连接中的频谱短缺和链路不稳定问题。XLINK 提供易于部署的解决方案，使当今的数十亿智能手机能够获得快速、流畅和强大的无线连接。

Road to Quic: QUIC 最初是在 Google 内部开发的，以取代 TCP [10]。与 TCP 相比，QUIC 更快、更安全，并提供防止协议僵化的保护。据悉，QUIC 现在占 Google [29] 的 40% 以上和 Facebook 互联网流量的 75% [30]。QUIC 的日益广泛采用推动了 XLINK。我们还从过去部署 MPTCP 的痛苦和收获中学习。我们表明，QUIC 的用户空间属性是克服主要障碍的关键，例如性能不理想、处理负载平衡器的困难、获得操作系统级别的支持以及遍历阻止使用 MPTCP 的中间盒

更好的移动支持：移动支持在无线通信中至关重要。不幸的是，今天，从 Wi-Fi 到蜂窝网络的漫游要么很慢，要么很容易出现故障 [33]。QUIC引入了连接迁移connection migration（CM）[34]，但CM需要在迁移后重置拥塞窗口，这可能不适合需要持续高带宽的视频流。Apple 已经展示了 MPTCP 在 Siri 中支持 Wi-Fi-LTE 漫游的好处，但迄今为止，尚不清楚多路径在部署的视频服务中是否仍然有效。我们开发 XLINK 来回答这些问题，并探索在高移动性场景中根据链路变化快速分发数据包的好处。

在 5G 中的多径：5G 的出现使多路径功能更加有趣。尽管 5G 提供了更高的带宽来满足数据速率的需求，但与 LTE [35, 36] 相比，由于更多的传播损耗和更弱的渗透导致更小的信号覆盖范围，这为 5G 满足其严格的可靠性和 QoS 保证带来了新的挑战。另一方面，Wi-Fi 6 可能仍然是最有效的室内通信方法 [37]。因此，3GPP 在 Release16 中引入了 ATSSS，其特点是同时使用 5G 和其他非 3GPP 接入（例如 WiFi）[38]。通过正式联络，3GPP 最近向 IETF 表达了对跨多路访问（其中 QUIC 是焦点 [39]）实现控制、切换和拆分流量（主要是 UDP）的协议的兴趣。XLINK 以同时支持 5G 和 Wi-Fi 的能力紧跟这一趋势。

体验 vanilla 多路径 QUIC

在本节中，我们将介绍我们使用 vanilla 多路径 QUIC (vanilla-MP) 的经验。多路径性能的两个重大挑战是移动性和路径延迟差异。我们首先研究移动环境中 vanilla-MP 的动态。然后我们讨论通过不同无线技术访问我们的视频服务器时测量的路径延迟差异。最后，我们展示了 vanilla-MP 如何在我们的生产环境中的大规模 A/B 测试中针对单路径 QUIC (SP) 执行。

快速变化的无线链路

为了了解 vanilla-MP 在移动环境中的行为方式，我们绘制了使用 Mahimahi 仿真在我们的校园中行走时收集的一对 Wi-Fi 和 LTE 轨迹重放的飞行中数据包的动态，如图 1a 和 1b 所示工具[40] 5. LTE轨迹相对稳定，但Wi-Fi轨迹变化较快，吞吐量从1.7s下降到2.2s几乎为零；拥塞窗口（CWND）无法跟随如此快速的变化。结果，调度程序仍然继续在该路径上发送数据包，导致传输中的数据包数量甚至上升到大约 1.8 秒。如此快速的变化可能会导致严重的 HoL 阻塞，因为，直到慢速路径 (Wi-Fi) 上的所有停滞数据包在很长一段时间后恢复后，才能将视频帧传递给应用程序。

异构网络中的路径延迟

了解路径延迟差异。我们测量了通过不同无线技术访问视频服务时的 RTT。我们还部署了自己的 5G SA 测试平台以了解 5G 超低延迟。我们发现无线技术对路径延迟有显着影响。LTE 的中位路径延迟分别是 Wi-Fi 和 5G SA 的 2.7 倍和 5.5 倍，而 LTE 的 90𝑡ℎ 百分位路径延迟是 Wi-Fi 的 3.3 倍。路径延迟差异随着多路径中的跨 ISP 延迟而进一步增加。路径延迟的较大差异可能会影响短视频服务中的视频启动延迟和请求完成时间。

vanilla-MP 的部署

最后，我们通过对短视频服务中的单路径 QUIC (SP) 进行大规模 A/B 测试来验证 vanilla-MP 的有效性。实验方法在 7.2 节中讨论。

在图 1c 中，我们绘制了一周内收集的中位数、90𝑡ℎ 百分位数和 99𝑡ℎ 百分位数视频块请求完成时间 (RCT)。该图揭示了以下发现：

Vanilla-MP 有时仅在中位数和 90𝑡ℎ 百分位 RCT 上有效，并且可能导致更差的性能（第 1、3、4 和 5 天）。最大的中位 RCT 退化为 16%
Vanilla-MP 总是导致 99𝑡ℎ 百分位 RCT 下降，甚至可能比 SP（第 4 天和第 7 天）差 28%。

在表 1 中，我们报告了在一周内观察到的客户端视频重新缓冲率的降低（测量为视频重新缓冲时间总量由视频播放时间总量标准化）。负数表示 vanilla-MP 的再缓冲率比 SP 差。vanilla-MP 的缓冲率恶化。非但没有下降，反而增长了34%以上，增幅最大的达到了96%。由于上面讨论的问题，这样的结果并不令人惊讶，因此，vanilla-MP 未能满足实现不比单路径传输更差的性能的标准。

XLINK 设计概述

在本节中，我们将介绍 XLINK 的设计概述。目标是以尽可能低的开销成本实现最佳的用户感知 QoE（例如，低延迟和小重新缓冲）。如图 2 所示，XLINK 被设计为部署在移动应用程序和边缘服务器中的轻量级端到端多路径 QUIC 扩展。它使多宿主移动客户端能够通过多个无线接口（例如，Wi-Fi 和蜂窝）同时传输与远程服务器通信。与过去的 MPQUIC 和 MPTCP 等无需应用程序辅助运行的解决方案不同，XLINK 受到跨层网络设计 [41] 的最新趋势的驱动，并将传输与视频应用程序紧密集成，以同时实现高性能和成本效益。XLINK的核心是利用QUIC作为用户空间协议的机会，利用用户感知的视频QoE进行多路径调度和管理。

在架构上，XLINK 的 QoE 驱动调度建立在客户端-服务器反馈机制之上。XLINK 客户端捕获用户感知的 QoE 信号（例如，视频播放器缓存帧和视频播放器帧率）并使用 ACK_MP 扩展帧（第 6 节和图 16）将这些信号传送到远程视频服务器以控制其调度. QoE_control_signal 字段的使用控制多条路径的耦合和解耦。它允许 XLINK 克服多路径 HoL 阻塞而不会产生不必要的成本开销，这对于大规模部署至关重要（第 5.2 节）。

XLINK 通过提供第一视频帧加速 (5.1)、无线感知主路径选择 (5.3) 和最快路径 ACK_MP 来进一步处理较大的路径延迟差异，以避免来自慢速路径的过度延迟并改善视频启动。

在算法上，XLINK 利用数据包重新注入来解耦多条路径。与过去的重新注入 [6] 不同，XLINK 在两个级别实现基于优先级的重新注入：传输（QUIC 流）级别和应用程序（视频帧）级别（第 5.1 节）。基于流优先级的重新注入考虑了 QUIC 请求视频不同部分的并发流。它确保重新注入的早期流的数据包在后续流的数据包之前发送，从而防止传输时的流阻塞。基于视频帧优先级的重新注入区分流内的视频帧紧急度。它以最高优先级处理视频的第一帧以加速视频启动。在 QoE 反馈控制方面，XLINK 引入了双阈值控制（5.2.2），实现了响应性和成本效率，并提供了平衡性能和成本的灵活性。

在协议级别，XLINK 建立在草案 [11] 中提出的多路径扩展之上，其中包含 PATH_STATUS 和 ACK_MP 扩展帧来管理路径状态并确认从不同路径接收到的数据包。唯一的区别是当前的 XLINK 实现（在本实验中使用）将 QoE 反馈作为 ACK_MP 帧中的附加字段发送，而不是在草案中指定的独立 QOE_CONTROL_SIGNALS 帧中发送 QoE 反馈。

QOE 驱动的调度和路径管理

本节讨论 QoE 驱动的多路径调度和路径管理的细节，这使 XLINK 能够以最小的成本开销实现卓越的用户感知 QoE。它由三个主要部分组成：基于流和视频帧优先级的数据包重新注入、QoE 反馈控制和 QoE 感知路径管理。我们通过基于流和视频帧优先级的重新注入克服了多路径 HoL 阻塞、流阻塞和视频启动时的过度延迟。为了降低成本，QoE 反馈用于控制与重新注入相关的冗余。我们进一步通过 QoE 感知路径管理处理异构网络中的路径延迟差异，该路径管理结合了无线感知主路径选择和最快路径多路径 ACK。

基于优先级的再注入

为什么要重新注入？重注入用于解耦多条路径。如前所述，多路径 HoL 阻塞的根本原因是当调度程序在它们之间拆分数据包时多路径的耦合。为了解释多路径 HoL 阻塞是如何通过这种耦合发生的，图 3（a）显示了调度程序将数据包从其发送队列（pkt_send_q）拆分为快速路径（紫色）和慢速路径（蓝色）的典型过程。

快速路径和慢速路径发送的数据包相互补充，客户端在两条路径上等待成功交付以获取整个视频块。如果慢速路径上的 pkt 6 和 pkt 7 丢失（可能是由于突然的链路中断），则会发生阻塞，因为客户端在慢速路径上的丢失恢复之前无法继续，这可能需要重传超时 retransmission timeout (RTO)。重新注入是一种允许我们使用冗余重复数据包解耦多条路径的技术，如图 3(b) 所示。在重新注入中，发送方跟踪未确认数据包的队列（unacked_q）。回到同一个例子，当 pkt_send_q 中没有更多数据包要发送时，发送方可以发送未确认数据包 6 和 7 的副本并重新注入快速路径，而无需等待慢速路径上的丢失恢复，允许接收方继续消费数据而不会受到阻塞效应的影响。

基于优先级的重新注入。然而，传统的数据包重新注入不足以实现良好的视频 QoE。我们需要解决的第一件事是流阻塞效应。与 TCP 不同，QUIC 传输层有 QUIC Stream 的概念。一个连接可以承载多个流，每个流单独控制并恢复丢失。在短视频传输中，视频播放器可能同时请求多个流，每个流下载一小部分视频。

如图4(a)和4(b)所示，现在包含两个流，Stream1 和 Stream2。

传统的重注入流如图4(a)所示。如果 pkt 4 在这种模式下在慢速路径上丢失了，调度器只能在 pkt_send_q 的末尾重新注入它，在 Stream 2 后面，这不是最优的。由于流的内容是按顺序播放的，因此流 2 现在阻塞了流 1 的传递。确实，早期流应该享有高优先级重新注入，以便在流 1 之后立即重新注入 pkt 4。在 XLINK 中，我们采用基于流优先级的重新注入（图 4（b））来处理并发的 QUIC 流。在这种模式下，当发送方发出 Stream 1 中的最后一个数据包时，它会立即检查 unacked_q 以查找具有相同流优先级的数据包。如果有的话，它会将这些数据包插入到未发送的较低优先级流的数据包之前，如图 4(b) 所示，从而防止数据流阻塞。

第一视频帧加速。XLINK 进一步引入了基于视频帧优先级的重注入，以加速第一视频帧的传递，这对于短视频至关重要。没有它，在存在较大路径延迟差异的情况下使用多路径可能会受到视频帧阻塞效应导致的视频启动缓慢的影响。原因是如果条件良好的路径的拥塞窗口已满（例如，图 4（c）中蓝色的 pkt 3），多路径调度器可能会将第一个视频帧数据包放在条件不佳的路径上。

在这种情况下，基于流优先级的重新注入提供的流级粒度是不够的，因为重新注入的数据包仍然必须等待同一流中的其他视频帧被传递（参见图4(b)）

XLINK 通过图 4(c) 所示的基于视频帧优先级的重新注入解决了这个问题。在这种模式下，XLINK 向应用程序提供 stream_send API，以更精细地表达视频 QoE 感知。具体来说，为了加速第一个视频帧，应用程序可以将包含第一个视频帧的流数据设置为最高优先级，并使用指示视频帧相对位置的位置和大小参数。启用后，XLINK 在发出最后一个第一帧数据包 (pkt 4) 后检查第一个视频帧 (pkt 3) 中的未确认数据包。如果有，调度程序会在同一流中其他视频帧的任何未发送数据包之前重新注入它（pkt 3）。重新注入的副本这次可以通过快速路径，它可能比原始数据包更早到达。因此，基于视频帧优先级的重注入避免了慢速路径的过度延迟，显着提高了视频启动速度。

QoE 反馈和再注入控制

不幸的是，数据包重新注入的问题在于它引入了很多冗余数据包。在我们的案例中，我们发现直接应用重新注入使总流量增加了 15%。巨大的成本开销对于大规模部署来说是不可接受的。除了成本问题，冗余也可能影响整体吞吐量。为了应对这一挑战，XLINK 利用客户端的 QoE 反馈来控制与数据包重新注入相关的成本开销，同时确保用户感知的 QoE。

实际上，并不总是需要冗余数据包，因为视频播放器会缓存视频块。如果缓冲区占用率高，则距离下一次可能的重新缓冲的播放时间很长，因此使用重新注入的紧迫性很低。相反，如果缓冲区占用率低，则距离下一次可能的重新缓冲的时间很短，因此使用重新注入的紧迫性很高。知道客户端视频播放器的缓冲区占用率是用户感知 QoE 的一个重要指标，XLINK 捕获缓冲区占用率信息并将其发送回服务器以控制其重新注入使用情况。这些信号在图 16 中 ACK_MP 帧的 QoE_Control_Signal 字段中传送。QoE 信号的定义可以是灵活的。在我们的情况下，我们从客户端的视频播放器中捕获了四种类型的信号：（1）缓存字节（𝑐𝑎𝑐ℎ𝑒𝑑_𝑏𝑦𝑡𝑒𝑠）的数量，（2）缓存的视频帧数（𝑐𝑎𝑐ℎ𝑒𝑑_𝑓rames），（3）比特率(bps) (4) 帧率 (𝑓𝑝𝑠)。

捕获 QoE 信号

XLINK 如何捕获 QoE 反馈信号的过程如图 5 所示。这里我们关注视频管道，它由 Media Source、Source Pipe、Decoder、Decoder Pipe 和 Renderer 组成。MediaCacheService 响应来自媒体播放器的视频播放请求，并向服务器发送 HTTP 范围请求以获取视频块。TNET是淘宝客户端使用的Android网络SDK，将QoE信号传递给XLINK。传入的媒体数据首先由媒体源处理，其中音频和视频帧被拆分并缓存在源管道中，随后将帧发送到各自的解码器进行实际解码。源管道跟踪缓存的帧数和缓存的字节数。

解码器知道帧率和比特率。为了获得 QoE 信息，Source Pipe 和 Decoder 会定期将这些更新的指标发送到 TNET。当 XLINK 想要发送 QoE 反馈时，它会查询 TNET。如果在 TNET 中更新了 QoE 信息，则 TNET 响应 XLINK 的查询，然后 XLINK 将 QoE 反馈信息封装到 ACK_MP 帧中的 QoE 控制信号字段中，如附录 C 所示。

双阈值控制

控制再注入使用的算法需要满足三个属性：响应性、成本效率和灵活性。（1）当急需重新注入时，必须有足够的反应能力。(2)准确防止不必要的重复注射。(3) 它需要提供灵活性来调整性能和成本之间的平衡。我们引入双阈值控制来满足上述需求。算法的基本形式如 Algorithm 1 所示。该算法的输入是上述四种 QoE 信号，算法的输出是决定是否应该重新注入。在高层次上，该算法可以分为三个步骤：

step1: 计算剩余时间。我们首先使用 QoE 反馈估计客户端缓冲区中剩余的视频播放时间 Δ𝑡。可以使用 𝑐𝑎𝑐ℎ𝑒𝑑_𝑓𝑟𝑎𝑚𝑒𝑠 除以 𝑓𝑝𝑠 的商或 𝑐𝑎𝑐ℎ𝑒𝑑_𝑏𝑦𝑡s 除以 bps 的商。当视频未以恒定比特率编码且帧率较高时，我们建议使用𝑐𝑎𝑐ℎ𝑒𝑑_𝑓𝑟𝑎𝑚𝑒𝑠 和𝑓𝑝𝑠 计算Δ𝑡，因为 𝑏𝑝𝑠 可能表现出很大的变化。但是，如果帧率非常低，则需要基于𝑐𝑎𝑐ℎ𝑒𝑑_𝑏𝑦𝑡𝑒𝑠 和𝑏𝑝𝑠 的计算。基本上，应该同时查看比特率和帧率。这使我们能够得到更保守的估计。

step2: 双阈值。第二步是双阈值，其中我们将剩余播放时间Δ𝑡与两个阈值𝑇𝑡ℎ1和𝑇𝑡ℎ2进行比较，我们设置𝑇𝑡ℎ1 <𝑇𝑡ℎ2。这两个阈值用于不同的目的。第一个阈值𝑇𝑡ℎ1 用于确保响应性。如果 Δ𝑡 < 𝑇𝑡ℎ1，则表示剩余的播放时间太少，我们需要立即开启重新注入，所以 Algorightm 1 返回真

应用第二个阈值𝑇𝑡ℎ2 以获得成本效益。如果Δ𝑡 > 𝑇𝑡ℎ2，说明客户端缓存的数据是足够的，我们可以放心的关闭重注入来降低成本，所以Algorithm 1 返回假。两个阈值的组合提供了灵活性，因为人们可以轻松地调整这些阈值以权衡性能与成本。

step3: 比较交付时间。当 Δ𝑡 在 [𝑇𝑡ℎ1,𝑇𝑡ℎ2] 的范围内时，缓冲区占用率处于中等水平，因此飞行中(in-flight) 数据包的传递时间在决策中起作用。我们进一步将 Δ𝑡 与飞行中数据包的估计最大交付时间 𝑑𝑒𝑙𝑖𝑣𝑒𝑟𝑇𝑖𝑚𝑒𝑚𝑎𝑥 进行比较。如果 Δ𝑡 < 𝑑𝑒𝑙𝑖𝑣𝑒𝑟𝑇𝑖𝑚𝑒𝑚𝑎𝑥，则其中一条路径可能太慢，因此应打开重新注入以使用另一条路径加速数据包传递。如果Δ𝑡 > 𝑑𝑒𝑙𝑖𝑣𝑒𝑟𝑇𝑖𝑚𝑒𝑚𝑎𝑥，飞行中的数据包将及时到达，因此应关闭重新注入以节省成本。𝑑𝑒𝑙𝑖𝑣𝑒𝑟𝑇𝑖𝑚𝑒𝑚𝑎𝑥 被计算为最大𝑅𝑇𝑇加上所有拥有未确认包路径的标准差，如下所示：

example

为了说明 Algorithm 1 在快速变化的无线环境中以降低成本克服了 HoL 阻塞，我们绘制了客户端缓冲区级别的动态以及重新注入的数据包数量与时间的关系，如图 6 所示。我们测试 vanillaMP（如图 6b），没有 QoE 控制的再注入（图 6c）和使用 QoE 控制的再注入（图 6d）以图 6a 中所示的相同网络轨迹回放。我们可以看到，随着路径 1 的恶化，vanilla-MP 的缓冲水平数次降至零，遭受严重的多路径 HoL 阻塞，并导致图 6b 中频繁的视频重新缓冲。重新注入在克服多路径 HoL 阻塞方面是有效的，因此当路径 1 恶化时，图 6c 和图 6d 可以在其缓冲区中保持足够的缓存字节。然而，在没有 QoE 控制的情况下，图 6c 会鲁莽地使用重新注入，因为即使缓冲区级别很高，它也会重新注入数据包，从而导致不必要的冗余流量。在 QoE 控制的帮助下，图 6d 仅在缓冲水平低时使用重新注入，因此它避免了在缓冲水平高时任何不必要的重新注入使用。因此，图 6d 能够以最少的流量开销确保视频播放的流畅性。

性能和成本的权衡。两个阈值𝑇𝑡ℎ2和𝑇𝑡ℎ2在性能和成本之间的权衡提供了灵活性。例如，较大的 𝑇𝑡ℎ1 以增加流量开销的下限 𝐶𝑚𝑖𝑛 为代价，提供更好的尾部性能。而 𝑇𝑡ℎ2 允许我们控制流量开销的上限 𝐶𝑚𝑎𝑥，我们有：

其中 𝛽 是启用重新注入的成本开销，在我们的例子中可以粗略估计为 15%。在实际部署中，我们建议根据客户端视频缓冲区占用率的分布设置𝑇𝑡ℎ1 和𝑇𝑡ℎ2。

QoE 感知路径管理

本节介绍 XLINK 的 QoE 感知路径管理如何处理异构网络中的路径延迟差异。我们首先介绍了多路径初始化中的无线感知主路径选择，然后讨论了多路径ACK路径选择策略。

无线感知主路径选择。XLINK 根据无线接口的类型仔细确定初始化连接的主要路径。过去的研究表明，由于路径延迟差异，主路径选择会影响 MPTCP [43] 的性能。随着5G SA的出现，路径延迟差异进一步扩大，因为：（1）与5G NSA与LTE共享同一核心网络不同，5G SA采用新的独立核心网络。(2) 5G SA原生支持边缘计算，让内容交付服务更接近接入网边缘。为了适应即将到来的 5G SA，我们使 XLINK 的主要路径选择具有无线感知能力。例如，我们可以设置以下顺序：5G SA > 5G NSA > WiFi > LTE。我们在图 7 中测量了从不同无线接口启动多路径连接时的首帧传送时间与不同帧大小。测量是使用我们的 5G SA 测试台和企业 Wi-Fi 进行的。主路径选择对第一视频帧传送时间的影响是显着的。简单地从正确的主路径开始可以提供更快的视频启动。

最快路径多路径 ACK。最后，但重要的是，XLINK 使用了最快路径多路径 ACK。与 MPTCP 不同，它的 ACK 应该在相同的子流（原始路径）上返回 [4]。XLINK 允许从任何路径返回 ACK_MP，这提供了更大的灵活性。有两种基本策略：最快路径（min-RTT 路径）上的 ACK_MP 和原始路径上的 ACK_MP。在 XLINK 中，我们使用最快的路径来传输 ACK_MP。我们在图 8 中展示了使用 Cubic 拥塞控制的两种 ACK 路径选择策略的效果。

我们通过使用 Mahimahi 更改两条带宽相等的路径之间的路径 RTT 比率来测量 4MB 负载的请求完成时间。随着延迟比变大，最快路径上的ACK_MP开始显示优势。原因是对于 Cubic，更快的 ACK 返回有助于拥塞窗口更快地增长，从而产生更好的吞吐量。

协议和实现

我们将在本节中描述 XLINK 的协议和实现。我们从 XLINK 如何将 QUIC 扩展到多路径开始，然后将 XLINK 集成到 Android 应用程序和视频服务中。XLINK 是基于我们的多路径 QUIC 草案 [11] 实现的，它将 IETF QUIC 扩展到多路径，并进行了尽可能小的修改。与过去严重依赖“单流”概念的提议 [7] 不同，我们在双向路径的概念之上扩展了多路径，这很容易适应覆盖大多数的蜂窝和 wifi 链路的性质QUIC 中的多路径应用程序，同时保持设计简单且易于实现。通过这样做，我们能够重新使用当前的大部分 QUIC 传输设计，只需添加三个新框架。更重要的是，我们的设计支持启用 XLINK 基于反馈的动态调度所需的 QoE 反馈。

关键设计点是：（1）不同的路径由连接ID（CID）的序号标识。为了方便丢包检测和恢复，我们为每条路径使用单独的包号空间。(2) 我们保持QUIC数据包头格式不变，以避免数据包被中间盒阻塞的风险。(3) 属于一个连接的所有路径共享相同的加密密钥，但我们结合了一种机制，使每条路径能够在 AEAD 中获得唯一的随机数。(4) 我们合并了 PATH_STATUS 和 ACK_MP 扩展帧以支持多路径功能和 QoE 反馈机制。

多路径初始化。多路径路径初始化过程如图9所示。XLINK首先以与单路径QUIC相同的方式初始化主路径，除了在第一次握手期间，客户端包含𝑒𝑛𝑎𝑏𝑙𝑒_𝑚𝑢𝑙𝑡𝑖𝑝𝑎𝑡ℎ传输参数。如果服务器以 𝑒𝑛𝑎𝑏𝑙𝑒_𝑚𝑢𝑙𝑡𝑖𝑝𝑎𝑡ℎ 参数回复，则两个终端主机都知道支持多路径。如果不是，他们会退回到单路径 QUIC。在初始化新路径之前，客户端需要提供至少一个未使用的可用 CID（例如序号为 1) 的 C1，并且服务器需要提供至少一个未使用的可用 CID。为了设置新路径，客户端选择一个可用的连接 ID S2 作为新路径中的目标连接 ID。CID 的交换是通过 QUIC [34] 中定义的 𝑁𝐸𝑊 _𝐶𝑂𝑁𝑁𝐸𝐶𝑇𝐼𝑂𝑁_𝐼𝐷 框架完成的。为了避免路径欺骗攻击，XLINK 使用 [34] 中定义的 𝑃𝐴𝑇𝐻_𝐶𝐻𝐴𝐿𝐿𝐸𝑁𝐺𝐸 和 𝑃𝐴𝑇𝐻_𝑅𝐸𝑆𝑃𝑂𝑁𝑆𝐸帧。一旦多路径被初始化，XLINK 使用 ACK_MP 帧而不是 ACK 帧来发送确认。

帧扩展。我们使用 PATH_STATUS 帧和 ACK_MP 帧来支持多路径功能和 QoE 反馈。PATH_STATUS 帧用于帮助管理多路径，它将路径的当前状态告知对等方，对等方应根据这些帧中表达的偏好发送数据包。PATH_STATUS 的可用值为 Abandon(0)、Standby(1) 和 Available(2)。端点使用对等方用于 PATH_STATUS 帧的 CID 的序列号（描述发送者的路径标识符）。

ACK_MP 帧通过合并路径索引字段（CID 序列号），可以方便地在每条路径上进行丢失检测和恢复。在我们的实验中，它还通过合并 𝑄𝑜𝐸_𝐶𝑜𝑛𝑡𝑟𝑜𝑙_𝑆𝑖𝑔𝑛𝑎𝑙 字段来支持客户端和服务器之间的 QoE 反馈。ACK_MP 的结构如 Appx C 所示. 在我们的草案 [11] 中，我们进一步引入了 QOE_CONTROL_SIGNAL 帧扩展，它允许我们独立发送 QoE 反馈，而不受 ACK 频率的限制。

路径关闭。客户端和服务器都可以通过发送 PATH_STATUS 帧来关闭路径，该帧使用相应的路径标识符放弃路径。一旦路径被标记为“放弃”，就意味着与该路径相关的资源可以被释放。在客户端检测到网络环境变化（客户端4G/Wi-Fi关闭，Wi-Fi信号衰减到某个阈值），或者终端检测到RTT质量或丢包率变差等场景，客户端或服务器可以立即终止路径。

数据包保护。QUIC Multipath 的数据包保护的一般原则没有改变。无需更改设置数据包保护密钥、初始机密、标头保护、使用 0-RTT 密钥 [11]。但是，为 1RTT 数据包使用多个数字空间，需要更改 AEAD 的使用。对于 QUIC 多路径，nonce 的构建从构建 96 位路径和数据包号开始，由 32 位字节顺序的连接 ID 序列号、两个零位和重构的 QUIC 的 62 位组成网络字节顺序中的数据包编号。如果 IV 大于 96 位，则 path-and-packet-number 用零填充到 IV 的大小。填充数据包编号和 IV 的异或形成 AEAD 随机数

使用负载均衡器。XLINK 与实现 QUIC-LB 草案 [44] 中指定的路由算法的负载平衡器一起使用。我们在负载均衡器中对连接 ID 使用一致的散列，以确保将多个路径路由到相同的真实服务器。为了做到这一点，一个真实的服务器在发给客户端的 CID 中编码一个服务器 ID。

与安卓应用程序集成。一个用 C 语言编写的 XLINK 客户端在 XQUIC [45] 中实现，这是阿里巴巴对 IETF QUIC 的实现，并集成到淘宝 Android 应用程序中。

XLINK 为视频播放器等应用程序提供 API，以将信息（例如，缓存字节、缓存帧、当前比特率和帧率）传递给 QUIC。测试包可以每周在客户端发布。

在 CDN 服务器中部署。XLINK 服务器也是用 C 编写的（也在 XQUIC [45] 中实现），并部署在多进程架构 CDN 服务器中。为了将接收到的数据包传递到包含 QUIC 连接上下文的正确进程，我们对进程 ID 使用一致的散列，该进程 ID 编码在 CID 中的保留字节中。XLINK的算法参数作为配置项添加，可以在小时内更新。

评估

在本节中，我们介绍 XLINK 的评估，它由两部分组成：在线评估和受控评估。

在线评估：在这部分，我们报告了使用 XLINK 升级到淘宝安卓应用的真实用户的数据。我们首先检查客户端视频播放器缓冲区级别分布的变化以及相应的冗余流量成本与双阈值的选择。然后，我们报告了大规模 A/B 测试的结果，我们在并行运行的两个对比组（单路径 QUIC 和 XLINK）之间进行了日常比较。参与者总数超过 10 万，我们的测量包括超过 300 万次视频播放。通过与移动运营商合作，在实验中使用多路径的参与者享受了零评级的蜂窝数据。我们的 A/B 测试结果包括视频请求完成时间和 QoE 指标。在 QoE 指标部分，我们专注于重新缓冲率的改进和首帧传送时间的改进。

受控评估：在这一部分中，我们在受控环境中进行测量，这使我们能够将不同的方法与可重复的网络条件进行比较。我们首先进行了高移动性评估，将 XLINK 和其他多路径解决方案的性能与在极端移动性场景中收集的网络跟踪进行了比较。然后，我们测量了在手机上使用 XLINK 下载各种大小的视频文件时的能耗。

除非另有说明，否则实验中使用的拥塞控制算法是 Cubic。对于 vanilla-MP、MPTCP 和 XLINK，我们使用“解耦”拥塞控制，这是移动多路径传输的典型配置 [46, 47]。我们还在 Sec 9 中讨论了拥塞控制问题。

缓冲区级别和成本开销与双阈值

我们首先通过更改 Alg 1 中的上限和下限来研究 QoE 控制算法中双阈值的选择。

为了确定阈值，我们首先测量了控制关闭时 QoE 反馈的剩余播放时间分布。然后我们选择阈值（𝑡ℎ（𝑋），𝑡ℎ（𝑌）），其中𝑡ℎ（𝑋）和𝑡ℎ（𝑌）表示分布中的𝑋-th和𝑌-th百分位值()

图 10 展示了客户端对 SP 与阈值设置的缓冲区级别改进，其中 (𝑡ℎ(𝑋),𝑡ℎ(𝑌)) 简化为 (𝑋,𝑌)。我们还在图 10 中绘制了与这些阈值设置相关的成本。我们观察到以下情况：

需要重新注射。当重新注入关闭时，缓冲区水平显着下降。
QoE 控制是必要的。在设置 (1, 1) 中关闭时，流量开销达到 15%。
间接成本以 𝛽(1 - 𝑋) 为界降低，以 𝛽(1-𝑌) 为上限，其中 𝛽 可以近似为 15%，这是预期的（参见第 5.2.2 节）。
适中的阈值以较小的成本实现了良好的性能（例如，（95, 80））。进一步提高门槛会导致收益减少。
当上限较大时，比较 delivery 时间有助于排除不必要的重新注入案例以控制成本，如 (90, 80) 与 (90, 60) 以及 (60, 50) 与 (60, 1)。

我们进一步计算了剩余播放时间小于 50 毫秒的样本的百分比，这被认为是可能导致视频重新缓冲的危险级别。这种百分比的降低如表 2 所示，其中阈值设置与图 10 相同。小于 50 毫秒的缓冲水平的百分比降低与 99𝑡ℎ 百分位缓冲水平的提高和 𝑡ℎ(95) 处的较低阈值相关，足以覆盖糟糕的网络条件。因此，最具成本效益的组合是 (95, 80)，它以 2.1% 的开销成本实现了 66% 的重新缓冲概率提高（见图 10）。尽管由于实验规模仍然有限，每天都会发生变化，但进一步增加成本看到了相同水平的改进。这些结果证明了 Alg1 的有效性。并表明我们可以用所提出的算法平衡性能和成本效益。

大规模 A/B 测试

视频请求完成时间。我们报告两周内视频请求完成时间的 A/B 测试结果。图 11 显示了视频块的中位数、95𝑡ℎ 和 99𝑡ℎ 百分位请求完成时间 (RCT)。正如前面第 2 节中所讨论的那样。3、vanillaMP 有时表现不如 SP。相比之下，XLINK 在中值和尾部 RCT 中始终优于 SP，因为它能够通过 QoE 驱动的多路径调度和管理来克服多路径 HoL 阻塞。我们观察到随机对照试验中位数、95% 和 99% 的日常改善分别为 2.3% 到 8.9%、9.4% 到 34% 和 19% 到 50%。高百分位数的巨大改进是由于尾部分布的多路径的更高可靠性和多样性增益。

QoE 指标 #1：视频重新缓冲率。在一周的过程中观察到的客户端视频缓冲率的降低（改善）如表 3 所示。衡量视频播放流畅度的视频缓冲率定义为总视频缓冲时间归一化的总量视频播放时间。换句话说，视频重新缓冲率计算为 sum(rebuffer time)/sum(play time)。与 SP QUIC 相比，XLINK 在视频重新缓冲率方面始终优于 SP。观察到的再缓冲率降低显着，范围从 23.8% 到 67.6%。这样的结果与图 11 所示的视频请求完成时间一致。评估结果表明，XLINK 在视频播放流畅度方面有效地提高了用户感知体验的质量。

QoE 指标#2：第一视频帧延迟。我们通过在实验期间启用和禁用此功能来测量第一视频帧加速的效果。图 12 绘制了在不同百分位数上第一视频帧延迟相对于 SP 的改进。如果没有第一视频帧加速，视频延迟变得比 SP 差得多，其中 99% 延迟甚至慢了 14% .这种降级是由慢速路径引入的过度延迟引起的。相比之下，第一视频帧加速避免了这种过度延迟，并提供了更快的视频启动速度，因为它的性能受到快速路径的限制。99%的提升比SP提升了32%以上。请注意，尾部的改进变得更大，这是预期的，因为快路径和慢路径之间的差异也在尾部变得更大。

极端移动环境下的测试

接下来，我们研究 XLINK 在极端移动场景中的表现。我们在地铁中收集了 LTE 和车载 Wi-Fi 轨迹和高速铁路，并使用 Mahimahi 仿真工具进行跟踪驱动评估 [40]。Appx B 中列出了有关我们的跟踪驱动评估和示例跟踪的更多详细信息。与 XLINK 相比，我们还评估了 SP、vanilla-MP、MPTCP 和 QUIC 连接迁移 (CM)。

图 13 显示了具有中值和最大值的视频块请求完成时间，我们进行了以下观察：(1) 由于缺乏移动性支持，没有 CM 的 SP 在任何这些跟踪中表现不佳。(2) 与 SP 相比，CM 显示出改进，因为当旧路径降级时，它可以迁移到新路径。然而，在极端流动性下，新路径也可能立即退化，因此迁移可能无效，在某些情况下甚至会导致比 SP 更差的结果。此外，在 CM 中，迁移后需要重置𝑐𝑤𝑛𝑑，这会触发拥塞控制的慢启动，并且客户端负责探测路径以检测路径退化，这可能需要多次往返。结果，当切换频率变高时，CM 响应不够。(3) MPTCP 和 vanilla-MP 在某些情况下比 SP 有所改善，但与此同时，它们在高速链路变化下也遭受严重的 HoL 阻塞，这在许多情况下导致性能下降。

相比之下，XLINK 在中值和最大值方面始终优于其他 RCT 小得多的方法。由于 XLINK 不仅有效地聚合了无线带宽，而且通过实时 QoE 反馈控制快速调整了其在快速变化的链路上的数据包分配，它克服了快速的链路变化和频繁的切换，从而为极端移动性提供更好的支持。

能量消耗

了解能源消耗至关重要，因为电池寿命会影响用户使用多路径的意愿。我们评估了标准化的每比特通信能量与安装在三种流行的支持 5G-NSA 的 Android 智能手机型号上并下载不同大小的负载 (10MB-50MB) 的 XLINK 吞吐量。

我们使用开源 Android API [48] 构建了一个内部能源监控工具，该工具从手机操作系统内核记录通信模块（Wi-Fi 和蜂窝）的以下信息：时间戳、瞬时电流、电压、WiFi RSSI和蜂窝RSSI。为了使通信模块的能量测量与其他背景噪声隔离，我们首先打开“飞行”模式以杀死所有后台进程，同时保持相同的屏幕亮度。然后我们开始使用 XLINK 下载文件，同时运行 APP 来记录能源信息。我们测试的安卓手机使用了骁龙 765G 和麒麟 990 芯片组。至于 5G 新无线电 (NR) 用例，我们想了解 5G 吞吐量何时无法达到其峰值速率以启用多路径，因此我们将每个链路的速度限制为 30Mbps。

结果如图 14 所示（左上角更好）。我们注意到使用双链路可以增加瞬时功率，但每比特的能量不一定很高，因为能量等于功率×时间，其中通信时间随着吞吐量的增加而减少。我们提出以下意见：

在吞吐量方面，Wi-Fi-LTE 和 Wi-Fi-NR 都比其单路径对应物有显着改进。

在每比特能量方面，Wi-Fi-LTE 和 Wi-Fi-NR 分别优于 LTE 和 NR。Wi-Fi 更节能，但其吞吐量远低于 XLINK，因此需要权衡取舍，XLINK 更适合需要高带宽和低延迟的应用程序（例如，视频应用程序）。

讨论和限制

蜂窝成本：客户的蜂窝成本是可能影响采用多路径传输的另一个重要因素。由于 XLINK 被集成为手机应用程序的一部分，我们提供了两种解决方案。(1) 第一个是我们应用程序中的零费率服务，为此我们与移动运营商合作，以便注册特殊数据计划的客户可以免费使用我们的应用程序。(2) 第二个是应用程序中的开关按钮，因此用户可以在需要时决定打开 XLINK。

拥塞控制公平性：我们当前的 XLINK 实现使用“解耦”立方拥塞控制，就像在其他移动多路径传输中一样 [46, 47]。这背后的原因是 WiFi 和蜂窝网络不太可能共享通常是无线网络“最后一英里”的瓶颈链路；这甚至适用于 [36] 中报道的 5G NSA。然而，随着 5G SA 的部署, 瓶颈有可能从“最后一英里”移动到网络的其他部分（例如，靠近 CDN 服务器），并且两条路径共享瓶颈。在这种情况下，为了公平起见，耦合变体是首选 [62] .虽然本文的重点不是拥塞控制，但XLINK的拥塞控制公平性值得进一步研究。

总结

尽管研究引起了广泛的兴趣，但过去十年在公共互联网中多路径传输的大规模部署一直很缓慢。我们相信 QUIC 作为端到端解决方案的出现为改变格局带来了关键机遇。我们展示了 XLINK，一种 QoE 驱动的多路径传输，作为 QUIC 的轻量级扩展实现，并在我们的电子商务短视频服务中进行了大规模的实验研究。通过 XLINK，我们证明了多路径 QUIC 的可行性、可部署性和优势。我们相信，这种由 QoE 驱动的方法的影响不仅限于短视频，还为探索多路径传输的激动人心的新途径铺平了道路，例如长视频点播、直播、AR 和 VR。

继续阅读

阅读原文