如何实现 70% 丢包下音视频的高可用之信令篇

基于卓越的自研音视频引擎，即构科技实现了超低时延的多路音视频通信和优异的音频体验。通过深度优化音视频数据处理、传输策略和音视频信令服务，让音视频服务在各种环境下都有着优良的体验和超高的可用性。

以下为即构示例 APP 在上行丢包 70%和下行丢包 70%网络环境下的可用性展示：

上行丢包 70%

下行丢包 70%

从测试数据可以看到，在上下行 70%的高丢包环境下，即构示例 APP 依然可保持每秒 15 帧的流畅音视频通话。

如何实现音视频云服务在弱网环境下高可用

音视频云服务，核心是对音频/视频数据的处理和传输。但在实际应用场景中，除了音视频数据，还有一些非音视频数据需要同步处理，比如设备初始化、登录通信房间、发起推/拉流消息等服务，这些非音视频数据的处理通常由信令服务来支持。

因此音视频云服务的弱网高可用需要从音视频数据和信令服务两方面入手。

音视频数据

在数据处理上，需要适应网络带宽的变化，动态调整音视频码率大小，通过牺牲一定的音视频质量来保证弱网环境下音视频服务的可用性和流畅度；

在数据传输上，传输信道要足够“智能”，能够视具体网络环境保证所需的音视频数据能够顺利传达。

信令服务

音视频信令服务需要在弱网环境下保证服务的高效稳定，实现信令的精准传达。

针对弱网处理的两个方面，我们的教程将分为上下两篇，本文为下篇，介绍如何提升信令服务在复杂网络的可用性。

信令服务的弱网高可用，即构主要通过 QUIC 协议来实现。我们对使用 QUIC 协议和其他协议（TCP 协议）在弱网的表现进行了统计，发现：

QUIC 协议在登录成功、推拉流成功的耗时，大幅低于 TCP 协议，优化百分比在 30%以上，极端场景甚至超过 90%。

以下为详细数据：

iOS 端

Android 端：

选择 QUIC 协议的原因

互联网数据传输协议有 TCP 和 UDP：

TCP 可靠、稳定，但是建连需要经过 3 次握手，相对繁琐、效率低且占用系统资源高；

UDP 效率高、快、轻量，占用系统资源较少，但是存在不可靠、无序等缺点。

而 QUIC（Quick UDP Internet Connection）协议，是谷歌制定的一种基于 UDP 的低时延的互联网传输层协议。

QUIC 协议既吸收 TCP 和 UDP 的优点，又对当前网络环境有优良的适应性，尤其是在弱网环境下能保证数据传输的可靠、稳定和高效。

基于 QUIC 协议实现信令服务的优势

与当前广泛应用的 TCP+TLS+HTTP/2 相比，QUIC 有以下优势：

连接建立延时低，减少往返次数

QUIC 实现了 0RTT 建连，相比 TCP+TLS+HTTP/2 的 3RTT 建连，具有相当的优势，同时通过加密传输保证数据安全。

以下为 QUIC 的建连过程：

1）客户端向服务端发送 CHLO；

2）服务器收到并返回 Rejection，包括密钥交换算法的公钥信息，算法信息，证书信息等被放到 Server Config 中传给客户端；

3）客户端发送完整的 CHLO，包括客户端公钥信息；

4）服务端收到之后再返回一个实时生成的公钥给客户端，客户端收到之后重新生成主密钥，用新的主密钥加密数据。

上述过程中，客户端收到 Rejection 后，就可以加密和发送数据，实现 1RTT 的建连。后续的连接中，一旦客户端缓存或持久化 Server Config，就可以复用并结合本地生成的私钥进行加密数据传输，不需要再次握手，从而实现 0RTT 建连。

改善拥塞控制，使用新的 ACK 确认机制

QUIC 协议当前默认使用 TCP 的拥塞控制算法，并在其基础上进行了相应的优化与改进，同时也支持 CubicBytes, Reno,RenoBytes, BBR, PCC 等拥塞控制算法。

主要的优化点有:

1）可插拔设计，应用层实现算法，无需操作系统，并且支持单个应用程序的不同链接；

2）单调递增的 Packet Number，并且引入 Stream Offset，保证数据的顺序性和可靠性；

3）不允许 Reneging，避免数据重传的干扰；

4）更多的 Ack 块，在丢包率高的网络下减少重传量，提升网络的恢复速度；

5）考虑到 Ack Delay，减少 RTT 时间的计算误差。

多路复用，解决 HTTP/2 队头阻塞问题

QUIC 的多路复用和 HTTP2 类似，在一条 QUIC 连接上可并行发送多个 HTTP 请求 (stream)。但 QUIC 的多路复用优势在于：QUIC 一个连接上的多个 stream 之间没有依赖。

当 stream2 丢了一个 udp packet，也只会影响 stream2 的处理，不会影响 stream2 之前及之后的 stream 的处理，这在很大程度上缓解甚至消除了队头阻塞的影响。

实现前向纠错，减少超时重传

前向纠错（FEC，Forward ErrorCorrection）是通过多发冗余的包，当有的包丢失时，可以通过冗余的包恢复出来，而不需重传。

QUIC 的 FEC 使用 XOR 的方式，即发 N + 1 个包，多发一个冗余的包，在正常数据的 N 个包里面任意一个包丢了，可以通过这个冗余的包恢复出来。

连接平滑迁移，网络状态变更不影响连接

一条连接是由四元组标识的（源 IP，源端口，目的 IP，目的端口）。

连接迁移是指，其中任何一个元素发生变化（如 WIFI 和移动网络的切换，连接竞争导致重绑端口），这条连接依然维持，能够保持业务逻辑不中断。

而通过 QUIC 实现连接迁移时，任何一条 QUIC 连接不再以 IP 及端口四元组标识，而是以一个 64 位的随机数作为 ID 来标识。当 IP 或者端口发生变化时，只要 ID 不变，这条连接依然维持，上层业务逻辑感知不到变化，不会中断，也就不需要重连。

由于这个 ID 是客户端随机产生的，并且长度有 64 位，所以冲突概率非常低。

基于自研基础引擎卓越的性能和优秀的网络抗性，即构科技实现对音视频数据高效处理和稳定传输。结合 QUIC 协议深度优化信令服务，即构打通音视频云服务整个链路，让用户在任何地方，任何时候都可以看见、听见。