锐客网

  1. 首页 > 睿知 > it技术 > >

【即构教程】如何实现70%丢包下音视频的高可用-信令篇

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


70%高丢包环境下，即构音视频流畅互动
以下为即构示例APP在上行丢包70%和下行丢包70%网络环境下的可用性展示：
上行丢包70%


下行丢包70%


从测试数据可以看到，在上下行70%的高丢包环境下，即构示例APP依然可保持每秒15帧的流畅音视频通话。
如何实现音视频云服务在弱网环境下高可用
音视频云服务，核心是对音频/视频数据的处理和传输。但在实际应用场景中，除了音视频数据，还有一些非音视频数据需要同步处理，比如设备初始化、登录通信房间、发起推/拉流消息等服务，这些非音视频数据的处理通常由信令服务来支持。
因此音视频云服务的弱网高可用需要从音视频数据和信令服务两方面入手。
音视频数据
在数据处理上，需要适应网络带宽的变化，动态调整音视频码率大小，通过牺牲一定的音视频质量来保证弱网环境下音视频服务的可用性和流畅度；
在数据传输上，传输信道要足够“智能”，能够视具体网络环境保证所需的音视频数据能够顺利传达。
信令服务
音视频信令服务需要在弱网环境下保证服务的高效稳定，实现信令的精准传达。


针对弱网处理的两个方面，我们的教程将分为上下两篇，本文为下篇，介绍如何提升信令服务在复杂网络的可用性。
↓↓↓戳下方查看上篇
【即构教程】如何实现70%丢包下音视频的高可用-数据篇
信令服务的弱网高可用，即构主要通过QUIC协议来实现。我们对使用QUIC协议和其他协议（TCP协议）在弱网的表现进行了统计，发现：
QUIC协议在登录成功、推拉流成功的耗时，大幅低于TCP协议，优化百分比在30%以上，极端场景甚至超过90%。
以下为详细数据：
iOS端
【即构教程】如何实现70%丢包下音视频的高可用-信令篇
文章图片
【即构教程】如何实现70%丢包下音视频的高可用-信令篇
文章图片


Android端：
【即构教程】如何实现70%丢包下音视频的高可用-信令篇
文章图片
【即构教程】如何实现70%丢包下音视频的高可用-信令篇
文章图片

选择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）服务端收到之后再返回一个实时生成的公钥给客户端，客户端收到之后重新生成主密钥，用新的主密钥加密数据。


【即构教程】如何实现70%丢包下音视频的高可用-信令篇
文章图片
上述过程中，客户端收到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，目的端口）。
【【即构教程】如何实现70%丢包下音视频的高可用-信令篇】连接迁移是指，其中任何一个元素发生变化（如WIFI和移动网络的切换，连接竞争导致重绑端口），这条连接依然维持，能够保持业务逻辑不中断。
而通过QUIC实现连接迁移时，任何一条QUIC连接不再以IP及端口四元组标识，而是以一个64位的随机数作为ID来标识。当IP或者端口发生变化时，只要ID不变，这条连接依然维持，上层业务逻辑感知不到变化，不会中断，也就不需要重连。
由于这个ID是客户端随机产生的，并且长度有64位，所以冲突概率非常低。


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

    推荐阅读


    上一篇：【读书清单】过好今天|【读书清单】过好今天 活在当下

    下一篇：提高云安全性的五个实用小技巧