万人连麦的幕后技术详解

音视频开发进阶

共 5790字,需浏览 12分钟

 ·

2021-11-13 16:38

7月29日-7月30日,由青云科技举办的 CIC2021 云计算峰会在北京成功举办,拍乐云服务端专家沈伟锋受邀出席峰会,并在音视频技术论坛上以《大规模实时音视频技术架构的实践和演进》为演讲主题,分享了实时音视频通讯的几种常见架构和网络拓扑,构建实时音视频实际场景的复杂性和多样性,以及拍乐云在超大规模实时音视频系统的一些实践。
全球疫情持续反复,线上互动依然是后疫情时代人们工作、生活、娱乐的常态,实时音视频的需求还在增加。经过不断的演进,拍乐云可以支持单房间万人在线、千人视频连麦、万人音频连麦,并做到99.95%的高可用,服务于全球用户。本篇演讲实录将由浅入深,一步一步带大家了解实时音视频通讯系统背后的技术细节

#01

实时音视频常见架构

01

直连


直连,也叫对等网络(P2P)。这种结构中,每个客户端在启动的时候,都需要注册到注册服务器,便于其他人能找到自己,正常情况下,在建立音视频通讯的时候不需要媒体服务器的介入,每个客户端相互连接,直接进行音视频通讯。但当一个或多个客户端在 NAT 之后(甚至多层NAT之后)时,直连会变得比较困难,有时候甚至无法联通。这个时候需要通过 STUN 进行“打洞”来穿越 NAT 进行通讯,如果“打洞”失败,还需要引入服务器中继才能通讯。具体的NAT打洞,或服务中继的细节可以参考拍乐云的系列文章《穿越防火墙的奥秘:ICE协议详解》

02

MCU

MCU(Multipoint Conferencing Unit)方案出现得比较早,相应的技术也非常成熟,该方案由一个服务器和多个客户端组成一个星形结构,各个端都将音视频数据发送给服务端,服务端会把所有客户端的音视频数据经过解码,同步,重采样,布局,混流,编码等,最后把媒体数据推送给所有的客户端。实际上服务器端就是一个音视频混合器,这种方案服务器的计算压力会非常大。一般情况下,在音频数据混流之前,服务端会把目标用户自己的音频数据移除,避免客户端听到自己的回声。在视频数据混流前,服务端可能检测每个目标用户是否有自定义的布局,否则就按系统默认的布局混流编码。在一些网络比较复杂的环境下,MCU 也可以按目标用户的带宽对视频数据的编码码率做一些自适应的调整。


03

SFU

SFU(Selective Forwarding Unit)是最近几年流行的新架构,SFU 的方案跟 MCU 类似,每个客户端都把音视频数据发给服务端,然后由服务端转发给不同的客户端。跟 MCU 不同的地方,SFU 不对音视频进行混流,收到某个客户端的音视频数据后,按需(目标客户端是否订阅)将音视频数据原封不动的转发给目标客户端。它实际上就是一个音视频路由转发器。在这种方案里,所有的混流都是在客户端做的,对服务端的计算要求大大降低。在一些复杂的网络环境,视频的数据源端会使用 Simulcast 或 SVC 发送多层不同分辨率的视频流数据,服务端根据目标客户端的不同网络带宽和网络状况转发最合适的分辨率给目标客户端,使每个客户端的体验达到最佳。


04

对比和总结



直连
MCU
SFU
复杂度
非常低
灵活性
受NAT,防火墙的影响
影响大
网络带宽消耗
延迟
非常低
网络的自适应
可以做,但随着人数增加会变得非常困难
可以做,对服务端要求高
技术比较成熟
对客户端的计算能力要求
适中
对服务端的计算能力要求
基本无
系统能力,单会并发数
非常低
非常高
内容审核
没法做
可以
可以

从上面的对比,我们可以看到,直连方案基本不大适合大会场景,而且无法对网络内容进行审核,直连方案目前市场上基本只有在免费场景中看到。而随着计算成本和带宽成本的大幅度下降,及超大并发的需求,SFU方案的优势变得非常明显,而MCU方案在一些企业内基于音视频终端的通讯等传统应用场景目前还是比较常见的。

上面的音视频通讯架构,是最基础的音视频服务架构,还没有办法做到高可用和高并发,假设服务器宕机,服务就变的不可用了。

#02

构建实时通信的网络拓扑

01

环状网络结构


环型结构由网络中若干节点通过点到点的链路首尾相连形成一个闭合的环,这种结构通过公共传输链路组成环型连接,数据在环路中沿着一个方向在各个节点间传输,信息从一个节点传到另一个节点。

这种网络实现,构建和路由选路都很简单,没有中心依赖。但环状网络结构增加删除节点比较困难,环中任何一个节点失效,环路传输就会中断,导致整个网络瘫痪。
环状网络结构开始主要用于令牌网,目前已经很少被采用。

02

星型/树型网络结构


星型拓扑结构是一个中心,多个分节点。它结构简单,连接方便,管理和维护都相对容易,而且扩展性强,网络延迟小。中心节点是瓶颈,一旦失效,整个网络就瘫痪,单叶子结点互相独立,互不影响。

树形拓扑结构形状像一棵倒置的树,顶端是树根,树根向下分支,每个分支还可再向下分支,树根接收各站点发送的数据,然后再广播发送到全网。好扩展,容易诊断错误,根节点是瓶颈。
在音视频服务架构中,当需要大规模扩展并发用户的时候,一般都会采取部署多个边缘计算控制节点,并通过树型方式连接到中心DC。通过这样方式接入的用户,延迟会略有增加。

03

网状网络结构


在网状拓扑结构中,网络的每台设备之间均有点到点的链路连接,网状拓扑结构是应用最广泛的。它的优点是没有中心节点,可靠性高,容错能力强,延迟低,但结构复杂,因有多条传输路径,选路和流量控制比较复杂,消息的时序一致性无法保证。

在音视频服务架构中,我们的设计目标是:极低的延迟,传输高效,吞吐量大,但对不同用户来的媒体数据的时序性一致性并没有要求。因此网状结构一般是音视频服务架构中主DC服务控制节点间组网的首选拓扑结构。

#03

实际场景的多样性

01

网络接入的多样性


移动网络:3G/4G/5G的接入带宽各不相同(3G:<2Mbps;4G:10~ 100Mbps;5G:~10Gbps),并且信号强弱,接入基站随移动变化。

有线宽带LAN接入,共享出口带宽,容易出现用户间带宽竞争;ADSL接入,上下行带宽不对称,上行带宽低;PON & FTTH 直接光纤接入 ,带宽稳定。

无线接入主流路由器 < 150Mbps (2.4G频段最大300Mbps,5G频段最大867Mbps)。

02

传输路径上设备的多样性


传输路径上路由器、交换机吞吐量各不相同,出现性能瓶颈时,丢包策略和资源预留策略会有差异。

03

终端设备的多样性


我们需要面对的设备有桌面设备、移动设备、穿戴设备、物联网设备等,这些设备上的关键模块的质量,性能参差不齐。这些关键模块包括:网络模块、媒体采集模块(Camera/Mic)、计算模块(CPU)、渲染模块(GPU)等。

04

服务端接入的多样性


BGP(Border Gateway Protocol)机房实现单IP多线接入,具备智能路由选择,线路备份,故障后自动切换到可用线路等。多运营商专线接入,需要从应用层处理选路,故障时线路切换等。单运营商专线接入,无法解决不同运营商之间的互联互通的问题。

正是由于实际场景的复杂性,多样性导致了:
网络的动态变化:带宽,丢包,抖动,延迟等;
采集数据的动态变化:噪音(噪点),畸变,输出数据抖动等。

#04

架构演进和拍乐云实践


01

服务的高并发,高可用


要做到服务高并发,高可用,主要涉及到下面几项技术:

高并发服务集群
我们在音视频服务基础架构中讲到,单机服务并发量受限于服务器的计算资源,当需要非常高并发的时候,我们必须扩展服务端计算资源,组成服务集群,并通过前面的负载均衡使客户端来服务请求被均衡的分配到集群中的每个计算资源。
服务故障的自动恢复和降级
我们知道任何代码都或多或少会存在逻辑缺陷,即使是世界上最厉害的大牛也无法避免,因此,我们需要一个机制来保障,当故障发生时,系统能自动捕获错误,并恢复服务的可用性。当一些物理上的瓶颈出现的时候,比如服务计算资源,网络带宽出现瓶颈的时候,继续按正常方式提供服务,可能会产生雪崩效应,导致整个服务不可用,在这个时候,我们需要通过服务降级的方式来保障最主要的功能是可用的。比如关闭视频并不会对沟通造成严重的影响,但关闭音频可能使沟通无法继续,那就保留音频,关闭视频,来保证整个服务的可用性。
服务资源弹性伸缩
在虚拟化,SDN等技术的加持下,使得计算资源,网络资源的动态分配成为可能,因此在服务资源成为瓶颈时,动态伸缩服务资源在技术上是可行的。
异地容灾备份
在一些极端情况下,比如我们部署服务集群的机房发生火灾,如何来保证我们的服务可用?这个时候,我们会在不同地理位置部署多个服务集群,在正常情况下,不同地理位置的服务集群都会同时提供服务,当某个集群发生不可用的时候,我们的服务监控会检测到相应的事件,并及时调整路由,把新的服务请求调度到可用的其他服务集群。

在以上几个主要技术的加持下,拍乐云目前已经可以做到99.95%的高可用,并服务于全球用户。

02

服务的高质量


面对复杂多变的网络环境,如何保证提供高质量的音视频服务是音视频服务系统非常重要的任务,在这方面,拍乐云主要使用了这些技术来保证服务的高质量:带宽评估、拥塞控制和平滑发送、丢包重传和前向冗余纠错、错误隐藏和恢复、基于时域和空域的多层分发(SVC & Simulcast AVC)、基于图像和语音的去噪和增强、回音消除、音量自适应调整、网络资源预留。通过这些技术的应用,拍乐云即使在70%的丢包率下,依然能提供非常高质量的音视频服务。

03

超大规模,超高并发


SFU架构中的有选择的数据转发

大家知道,在SFU方案中,音视频数据是全量转发的,也就是说在10个人的会议中,服务端要把每个人的数据转发给其他9个用户(10*9),在用户数小的时候,问题不会太严重,但随着用户量的增加,问题会变的越来越严重。假设会中有100个人,每个人的视频数据是1Mbps,实际服务端需要转发的是100*99 = 9.9Gbps,在现实情况下,这几乎是不可能的。在实际情况中,受屏幕大小的限制,每个人不可能同时去看另外99个用户的视频,最常见的情况是1大+6小,或2*2、3*3、4*4、5*5等几种模式,这样,通过按需转发的方式,数据量可以大幅度的减少。
边缘计算与加速节点
在上面实时通讯系统的网络拓扑结构中我们讲到,通过部署多个边缘计算节点,按树型结构链接到主DC,可以大幅度扩大会议的规模。边缘计算节点也可以通过就近接入来解决最后一公里的接入问题。

在单向直播的场景中,我们也可以通过第三方CDN网络来扩展会议规模,但这种方案的延迟会比较大,会达到3~10秒的延迟,基本无法互动沟通,只能单向直播,当需要互动沟通的时候,必须切换接入方式到边缘计算节点或中心DC。

04

拍乐云音视频系统技术架构


架构图的左边主要是服务的注册、认证、配置、发现、调度。右边主要是大数据分析平台,服务健康状况监控报警,服务资源弹性伸缩。中间是拍乐云的产品服务:语音通话、视频通话、互动白板、互动直播,云端录制等。

#05

业界动向与最新技术

近年来,音视频通讯领域的发展非常快,出现了各种前沿新兴的技术,有的已经落地,有的还在深入的研究之中,很多技术的应用前景都非常看好。在这里我们举几个例子:

01

WebRTC


2010年5月,Google收购Global IP Solutions的GIPS引擎,将其开源并改名为WebRTC。2014年7月,WebRTC成为W3C标准,并发布浏览器标准API1.0。自此以后,实时音视频通讯服务的门槛大幅度降低,很多基于WebRTC的实时音视频服务如雨后春笋般蓬勃发展起来。可以说WebRTC的出现改变了音视频通讯领域的市场格局。

WebRTC目前还在不停的演进之中,有兴趣的可以从下面的链接获取最新的信息:
https://webrtc.org/
https://groups.google.com/forum/#!forum/discuss-webrtc
https://twitter.com/webrtc

https://webrtcweekly.com/

02

SDN


Software Defined Network即软件定义网络,最初是由美国斯坦福大学CLean State研究组提出的一种新型网络创新架构,可通过软件编程的形式定义和控制网络,其控制平面和转发平面分离及开放性可编程的特点,被认为是网络领域的一场革命,为新型互联网体系结构研究提供了新的实验途径,也极大地推动了下一代互联网的发展。

其核心概念是:控制与转发分离,管理与控制分离。其可编程和虚拟化特点可以帮助快速定义网络,并实现自动化部署和运维。控制和管理的集中,使得网络路径最优化变得更加容易实现。

03

基于机器学习的新算法


机器学习在很多领域都得到了广泛的应用,在实时音视频通讯领域上也出现了很多应用方向,比如:

网络传输相关:智能拥塞算法,智能带宽评估算法,智能路由等;
视频图像相关:虚拟背景,超分辩率,视频融合,deepfake等;

语音相关的:语音识别,语音增强等。

04

虚拟现实、增强现实和3D技术


虚拟现实(Virtual Reality),就是虚拟和现实相互结合,是一种可以创建和体验虚拟世界的计算机仿真系统,它利用计算机生成一种模拟环境,使用户沉浸到该环境中。增强现实(Augmented Reality)是一种将虚拟信息与真实世界巧妙融合的技术,真实环境和虚拟物体之间重叠之后,能够在同一个画面以及空间中同时存在。通过VR,AR,3D技术的结合,相信不久的将来,实时音视频通讯可以实现类似于现实世界中会议室一起开会的效果。



技术交流,欢迎加我微信:ezglumes ,拉你入技术交流群。

私信领取相关资料

推荐阅读:

音视频开发工作经验分享 || 视频版

OpenGL ES 学习资源分享

开通专辑 | 细数那些年写过的技术文章专辑

NDK 学习进阶免费视频来了

你想要的音视频开发资料库来了

推荐几个堪称教科书级别的 Android 音视频入门项目

觉得不错,点个在看呗~


浏览 66
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报