网易云信 QUIC 加速服务架构与实践

导语：网易云信作为音视频服务提供商的领导者，一直致力于提供顶级的音视频通话服务体验，为用户在各种恶劣环境下提供可靠的音视频服务。如何在极端弱网条件下仍然能给用户提供可靠的音视频服务，是网易云信关注的重中之重。本文将阐述网易云信为了提高可靠数据在弱网环境及时性所采用的架构技术方案。

引言

市面上多数传统的音视频服务基于 TCP 协议做可靠数据的传输，但是因为 TCP 自身协议的特性，有着天生的一些缺陷，例如：

传输效率低

TCP 无私的传输特性，导致传输慢，效率较低，在弱网下更明显。

建联延迟大

三次握手的安全设计引起首次建联耗时高，会引起首屏出现较晚。

抗弱网特性差

TCP 的可靠传输特性决定了，较小的丢包就会引起链路断开。

队头阻塞严重

包文有序依次传输，小序列号包的丢失会引起后面包文阻塞，直到重传成功。

这些缺陷导致传统音视频服务在弱网环境下，可靠数据链路先于媒体链路断开，信令延迟到达，影响用户体验。如何提高可靠数据链路的可靠性和及时性是所有音视频服务提供商需要解决的问题。随着技术发展，当前热门协议 QUIC 应运而生。

QUIC 概述以及优势

QUIC 全称 Quick UDP Internet Connection，即快速 UDP 互联网连接，是由 Google 于2013年提出，使用 UDP 进行多路并发传输的协议。QUIC 使用 UDP 协议，在两个端点间创建连接，且支持多路复用连接。在设计之初，QUIC 希望能够提供等同于 SSL/TLS 层级的网络安全保护，减少数据传输及创建连接时的延迟时间，双向控制带宽，以避免网络拥塞。下面，我们一起来看看 QUIC 相对于 TCP 的优势。

简化 TLS 的握手流程，降低首次建连 RTT

QUIC 协议做的最大优化即简化握手流程到 0/1RTT。众所周知，HTTPS 的握手需要 3RTT 的耗时，然而 QUIC 建联最多只消耗 1RTT。如下图，说明了 TCP 的握手繁琐流程，然而 QUIC 将该繁琐流程降低到了 0-1 个 RTT。

采用多流策略，某个流的队头阻塞不会引起另外一个流的数据阻塞。

应用层的协议数据通过流交换信息，每个流内是有序序列的字节，而流之间没有顺序关系，流与流之间是相互隔离，相互独立的。如果某个流出现丢包或者传输不可达，不会影响连接中其他流的数据。这样设计可以避免 TCP 协议中的队头阻塞，我们需要做的是把不同优先级的数据进行隔离即可。

改进拥塞控制算法

TCP 的拥塞控制是针对一条连接的，所有的传输受控于一个拥塞控制模块。然而 QUIC 是可以做到对于每条流做流控。

支持动态连接迁移

连接迁移即当连接四元组中任何一个元素发生变化时，这条连接依然维持，能够保持业务逻辑不中断。QUIC 之所以能支持连接迁移，是因为 QUIC 不再用四元组标识连接，而是以一个 64 位的随机数作为 ConnctionID 来标识，这样就算 IP 或者端口发生变化，只要 ConnctionID 不变，这条连接依然维持着，上层业务逻辑不会感知到变化，就不会中断，也就不需要重连。

实现前向纠错，通过发送冗余包来减少重传

QUIC 会对一些优先级较高的包进行冗余发送，丢失的数据包可以通过冗余包计算，减少重传次数以提高传输效率。

以上这些 QUIC 优点在互联网行业都有着很大的吸引力，网易云信也参考了这些优点，在此基础上设计了自己的加速代理架构。

网易云信可靠链路的加速架构

网易云信参考 QUIC 的优势，自研了 QUIC 加速代理服务，为端到边缘服务器节点提供可靠数据传输的代理服务，提高可靠数据的及时性。下图为网易云信加速代理的架构图。

如上图，云信采用 QUIC 协议和 TCP 协议并行的设计，客户端同时支持 QUIC 链路和 TCP 链路建联。正常情况下，客户端会优先使用 QUIC 协议。客户端通过连接到 QUIC 加速服务来连接到后端，在 QUIC 连接失败的情况下，才会选择备用 TCP 链路建联直接连接后端。网易云信之所以保留原 TCP 协议接入，目的是用来做某些用户场景下 UDP 不可用的补充，保证程序的高可用性。

网易云信加速架构设计初衷

我们采用此架构设计的初衷是出于以下几点考虑：

对最后一公里加速

距离用户最后一公里为最容易出现弱网故障的链路，在该链路上对用户可靠数据进行加速，可以实现事半功倍的效果。

UDP/TCP 的双保险，提升高可用性

某些局域网防火墙中禁用了 UDP 协议，在该网络环境下，UDP 报文不可达。该网络环境下，基于 UDP 的 QUIC 协议包将会被全部丢弃。在该网络环境下只能寄希望于 TCP 传输，所以云信将 TCP 选取为数据链路的备份。

加速服务与业务相互隔离，加速服务不关心业务数据

网易云信加速服务，作为一个透明的协议，只负责接受 QUIC 包文，解开包文透传给后端。加速代理服务不关心 QUIC 承载的内容，所以扩展性较大，可以用来给很多需要加速业务做数据传输加速。

兼容原有架构

为老客户提供弹性升级策略是云信产品升级策略之一，所以该架构的部署不能影响老用户，老用户可以保留原先的链路，新用户则默认采用加速链路。

下面，我们来详细看一下网易云信加速服务器的架构设计。

数据加速服务器的架构设计

数据加速代理服务器分为两大模块，QUIC 前代理模块和后代理模块。

QUIC 前代理模块

QUIC 前代理模块，启动一个 UDP 监听，监听客户端用户 QUIC 报文，前代理模块主要负责以下工作：

接收客户端 QUIC 协议的 UDP 包文
对收到的包进行 QUIC 解包和冗余度过滤
对于将要发送的包文进行 QUIC 协议打包
按照网络情况计算带宽和冗余度，发送冗余包
对收到的包文进行完整性校验

QUIC 后代理模块

QUIC 后代理模块负责与后端建立 TCP 连接或者跟后端发起 http 请求，后代理模块主要工作内容为：

按照前端的请求，向后端发起连接请求
对前端代理的业务数据包进行打包，透传给后端服务器
接受后端服务器的业务包，并且进行压缩和正校验在送给前端代理模块，由前代理模块进行 QUIC 协议转发

前端代理与后端的服务器一般会进行就近部署或者同机部署，所以几乎可以忽略代理到后端服务器的延迟。主要延迟产生为端与前端代理之间的延迟，优化的重点转为增加端到前端代理的 QUIC 传输优化。

基于 QUIC 加速服务实现的音视频服务优化

在 QUIC 加速服务的基础上，网易云信主要做了以下几方面优化：

首屏打开速度优化

云信客户端与服务器实现耗费至 0-1RTT 来建连，相比 TCP+TLS+HTTP/2 的 3RTT 建连，具有很大的优势。在成功连接之后，一旦客户端缓存或持久化客户端配置，就可以复用并结合本地生成的私钥进行加密数据传输，不需要再次握手，从而实现 0RTT 建立连接。这样给用户首屏打开速度至少带来了 2RTT 的延迟降低。特别在一些网络差的偏远地区，可以降低 100-300ms 的首屏延迟，提高了用户体验。

多 Streams 设计

QUIC 链路下创建多个 Streams，分别用于不同应用层协议数据的传输，各个 Stream 传输相互隔离，不会因为优先级低的数据队头阻塞会影响另外优先级高的数据接受和发送。

信令优先级分级设计

优先级高的数据采用较高的冗余度发送，优先级较低冗余度也较低，从而保证优先级高的数据优先到达，并且优先层级低的数据不会阻塞优先级高的信令传输。

可选配置的传输数据压缩

数据代理支持 zlib 压缩，针对一些信令字符 Json 数据，zlib 压缩对于字符压缩，压缩率可以达到 20%。通过压缩，可以降低传输带宽，缓解带宽受限的拥塞。

引入 CRC 对传技术数据进行校验

QUIC 是流式数据，新增对于传输的每条数据进行 CRC 校验，一旦校验失败，随即断开连接，保证数据传输的可靠性和准确性，以免影响业务。

根据网络状况，动态调整冗余度

通过 nacked 包的情况，来评估全链路网络情况，发生了 unnacked 则正向调整冗余度，反之待稳定后降低冗余度。最大限度节省带宽占用，节省用户带宽，避免队列拥塞。

网易云信加速服务的弱网性能表现

我们在进行数据加速之后与未加速的情况做了一系列的对比，特别做了在弱网环境下的对比。

首屏耗时和登录耗时

上图是云信音视频业务 QUIC 和 TCP 的首屏打开耗时和登录流程耗时。可以看到首屏打开有20%的提升，登录有将近30%的提升，效果较明显。原因主要因为 QUIC 实现了0-1次 RTT 的握手流程，特别对于一些偏远省份，可以省下 100ms 的延迟，效果较为明显。

抗丢包能力

上图是云信信令数据在 QUIC 和 TCP 链路下能够抗住的最大丢包率。QUIC 在上行丢包率达到70%的条件下仍然可以提供服务，下行边界甚至可以抗住75%的丢包。TCP链路在45%的丢包情况下就会出现断开重连。相对于 TCP 的信令链路 QUIC 链路有50%的提升。主要原因：

云信实现了动态冗余，会检测到丢包之后增加冗余度，这样就用冗余包弥补了高丢包，带来了抗丢包性能。
QUIC 改进的流量控制和拥塞控制算法让QUIC在弱网络下可能取得更大的传输优势。

带宽受限

我们还做了在带宽受限的情况下，QUIC 对于带宽的使用率，基本上 QUIC 对于带宽的使用率都能达到90%以上，然而 TCP 就要差很多。

测试结论

在丢包方面，云信得到了50%的抗丢包性能提升，在首屏打开速度上云信也有20%的提升，并且在带宽受限制的情况下，也能够达到90%的带宽使用率，是音视频服务业内领先的水准。

展望&总结

网易云信在可靠数据加速上可靠数据传输上已经得到很大的提升，但是仍然还有一些需要优化的地方：

一旦单向发生丢包，会引起服务器和端都增加双向的冗余度，带来不必要的冗余增加。后续会检测到单向丢包，只针对丢包的链路进行冗余度增加。
对于高 RTT 和高丢包场景，QUIC 拥塞控制算法需要持续优化。

网易云信将持续在音视频领域，在各种极端情况下为用户提供优质的服务。

作者简介

纪松，网易云信资深音视频服务端开发工程师，负责云信云信直播业务和音视频数据链路加速业务，曾负责并发 70 万人的 TFboys 直播业务。在音视频数据传输和网络数据转发方面有着丰富的经验。