InfoQ|阿里淘系自研标准化协议库 XQUIC 首次公开:直播高峰期卡顿可降低 30%( 六 )


我们在 18 年曾与手机厂商合作(MPTCP 同样需要厂商支持) , 并尝试搭建 demo 服务器验证端到端的优化效果 , 实验环境下测试对「收藏夹商品展示耗时」与「直播间首帧播放耗时」降低 12-50% 不等 , 然而最终由于落地成本太高并未规模化使用 。 由于 XQUIC 的用户态协议栈能够大大降低规模化落地的成本 , 现在我们重新尝试在 QUIC 的传输层实现多路径技术 。
InfoQ|阿里淘系自研标准化协议库 XQUIC 首次公开:直播高峰期卡顿可降低 30%
本文插图

图 14. Multipath QUIC 协议栈模型Multipath QUIC 对于移动端用户最核心的提升在于 , 通过在协议栈层面实现多通道技术 , 能够在移动端同时复用 Wi-Fi 和蜂窝移动网络 , 来达到突破单条物理链路带宽上限的效果;在单边网络信号强度弱的情况下 , 可以通过另一条通道补偿 。 适用的业务场景包括上传、短视频点播和直播 , 可以提升网络传输速率、降低文件传输耗时、提升视频的秒开和卡顿率 。 在 3GPP Release 17 标准中也有可能将 MPQUIC 引入作为 5G 标准的一部分 [7]。
技术层面上 , 和 MPTCP 不同 , 我们自研的 MPQUIC 采取了全新的算法设计 , 这使得 MPQUIC 相比于 MPTCP 性能更加优化 , 解决了 slow path blocking 问题 。 在弱网中的性能比以往提升 30% 以上 。
图 15. 弱网下相对单路径的文件平均下载时间降低比例(实验数据)
图 16. 弱网下相对单路径的视频播放卡顿率降低比例(实验数据)在推进 MPQUIC 技术落地的过程中 , 我们将会尝试在 IETF 工作组推进我们的方案作为 MPQUIC 草案的部分内容 [8]。 期望能够为 MPQUIC 的 RFC 标准制定和落地贡献一份力量 。
未 来我们论证了 QUIC 的核心优势在于用户态的传输层实现(面向业务场景具备灵活调优的能力) , 而非单一针对弱网的优化 。 在业务场景的扩展方面 , 除了 RPC、短视频、直播等场景外 , XQUIC 还会对其他场景例如上传链路等进行优化 。
在 5G 逐步开始普及的时代背景下 , IETF QUIC 工作组预计也将在 2020 年底左右将 QUIC 草案发布为 RFC 标准 , 我们推测在 5G 大背景下 QUIC 的重要性将会进一步凸显 。
QUIC/MPQUIC 对于 5G对于 5G 下 eMBB(Enhanced Mobile Broadband)和 URLLC(Ultra Reliable Low Latency)带来的不同高带宽 / 低延迟业务场景 , QUIC 将能够更好地发挥优势 , 贴合场景需求调整传输策略(拥塞控制算法、ACK/ 重传策略) 。 对于 5G 运营商提供的切片能力 , QUIC 同样可以针对不同的切片适配合适的算法组合 , 使得基础设施提供的传输能力能够尽量达到最大化利用的效果 。 在 XQUIC 的传输层实现设计中 , 同样预留了所需的适配能力 。
在 5G 推广期间 , 在基站部署不够密集的情况下 , 保障稳定的有效带宽将会是音视频类的应用场景面临的巨大挑战 。 Multipath QUIC 技术能够在用户态协议栈提供有效的解决方案 , 然而这项新技术仍然有很多难点需要攻克 , 同时 3GPP 标准化组织也在关注这一技术的发展情况 。
XQUIC 开源计划阿里淘系技术架构团队计划在 2020 年底开源 XQUIC , 期望能够帮助加速 IETF 标准化 QUIC 的推广 , 并期待更多的开源社区开发者参与到这个项目中来 。
附录:参考文献
[1] SPDY - HTTP/2.0 原型 , 由 Google 主导的支持双工通信的应用层协议
[2] HTTP/2.0 - https://tools.ietf.org/html/rfc7540
[3] TLS/1.3 - https://tools.ietf.org/html/rfc8446
[4] GQUIC - 指 Google QUIC 版本 , 与 IETF QUIC 草案版本有一定差异
[5] IETF QUIC - 指 IETF QUIC 工作组正在推进的 QUIC 系列草案:https://datatracker.ietf.org/wg/quic/documents/ , 包括 QUIC-Transport、QUIC-TLS、QUIC-recovery、HTTP/3.0、QPACK 等一系列草案内容


推荐阅读