如何构建全球实时音视频云及其海外网络传输优化?

ZEGO即构科技 博客主编  2021-11-17 14:40:54

全球不同国家和地区的网络基建水平参差不齐,如何利用有限的网络资源提供更高质量的音视频通话体验是音视频服务商必须面对的挑战。在此次LiveVideoStackCon 2021 音视频技术大会 北京站,我们邀请到了即构科技的RTC后台技术总监——肖潇,为我们介绍即构科技是如何构建全球实时音视频云以及其海外网络传输优化技术。

文 | 肖潇

整理 | LiveVideoStack

     图片

 

本次分享主要分为三个部分,首先是全球实时音视频云架构,其次是海外网络传输面对的挑战,最后是音视频传输优化实践。

 

一、全球实时音视频云架构

 

图片

 

架构往往服务于业务和产品,即构科技的定位是一家全球音视频云服务提供商,即构目前覆盖了全球212个国家和地区,提供100+的行业解决方案,我们自研了全链路音视频的引擎以及实时网络。至今,即构年服务人数达到300亿+,每日通话数达到30亿+分钟。

 

图片

 

即构服务全球的宗旨是“贴近用户,连通全球”。

 

首先,为了让用户有更好的音视频的体验,即构在全球部署了大规模的边缘节点,让用户能够更短更快地接入。另外,音视频是一个实时互动的场景,互动涉及到数据流传输,需要将连接海量用户的服务器进行级联以及媒体数据的全球传输。

 

图片

 

即构在全球有500+的网络节点,一些出海比较热门的地区,例如东南亚,南亚,南美,北非、中东等地区,即构都有比较丰富的节点覆盖。通过大规模的网络节点,即构能够为全球212个国家和地区提供优质服务。在全球的500多个节点之间,我们可以保证99.9%的优质传输率。

 

图片

 

即构全球音视频云的四个关键词分别是多云基础架构、边缘计算、全球多中心,MSDN全球传输网络。

 

多云基础架构从诞生起就在公用云的IaaS基础上构建音视频PaaS和SaaS产品。使用公用云也和即构作为创业公司的背景有关。充分利用公用云的优势,可以减少基础设施层面的研发和运营工作,使得业务更加聚焦,更加节约成本。另外,使用公用云可以使即构对全球优质节点做到随取随用。

 

边缘计算方面不再赘述。

 

全球多中心,媒体边缘调度和流数据的管理大多采用中心化的服务,但中心化的服务存在一些的问题,例如当服务中心在香港,那么香港和阿根廷的用户物理间的时延会很高。再者,单中心服务机房或者网络一旦出现故障,后果会令人难以接受。近年来几乎所有公用云供应商都出现过重大的故障。多中心首先要能够做到跨域之间双向信息的同步。举个例子,一位新西兰的用户正在推流,流信息写入东南亚数据库,拉流用户在南美,接入的是美洲中心。当东南亚的中心出现问题时,可以通过后台快速发现和配置的能力,迅速把流量导至欧洲中心。虽然时延可能会有所增加,但是能够较好的做容灾容错的处理。

 

接下来我将详细阐述——MSDN。MSDN就是在原有公网基础上搭建了一个“有序网”,有序是指它可以自动容错、智能选择最优传输路径,当出现线路故障时秒级响应/自动恢复,让使用者获得更高的网络质量。

 

这张“有序网”来自对亿级海量数据的实时质量评估&事后质量评估。根据海量用户的最优化实践、和亿级数据的最优化传输,即构MSDN逐渐成为一张覆盖面广、可用性强、支持超高并发、且具有超低延迟的“专线级”虚拟网络。

 

图片

 

先总体介绍一下音视频云服务端的架构。左图能够清晰地看出这是一个边缘计算加多中心的架构。流媒体相关的服务,例如转码、混流、CDN转推等比较贴近边缘。媒体相关的调度和控制管理的服务靠近中心,图中N代表多中心。右图表示媒体相关的服务在全球传输时的分层架构。第一层是接入层,用更多的边缘让用户更快接入。中转层通过MSDN进行网络之间的传输和加速。基础资源层是在IaaS基础上进行多租户地割离和共用。对有大规模拉流需求的企业来说,分发层会更加明显。图中的两个边缘节点是直连的,如果拉流端有百万级并发,就需要经过一个分发层,其作用是在推流和拉流侧搭建一个类似树的结构,放大整个推拉流的能力,汇聚成一个大的分发网络。分层架构会使关注点分离,每一层的重心更加明确,优势明显。例如接入层和分发层就不用太去关注中转层的传输问题,一定程度上提高研发效率。

 

二、海外网络传输面对的挑战

 

图片

 

图为Speedtest全球移动网络速率测算图表。中国之前一直位于第四,最近变为第五,但能发现中国的传输速率仍然是世界平均的三倍以上。比较热门的出海领域如埃及、巴基斯坦、印度等整个国家移动网络速度只有中国的1/10左右,可以看出海外很多国家的网络基础设施相对较差。

 

图片

 

终端用户经常遇到这六个问题:

 

  1. 弱网用户多

  2. 网络传输延迟大

  3. 网络抖动大

  4. 网络丢包严重

  5. 网速不均衡

  6. 跨GFW


遍布全球机房的互联网链路之间也存在类似的问题。

 

三、音视频传输优化实践

 

针对这些问题,即构采取了一系列的优化措施。

 

图片

 

3.1 MSDN

 

图片

 

首先是即构自建的称之为海量有序数据的MSDN传输网络,它是基于SDN技术而构建的全球传输网络。在可行性方面,即构拥有10个云服务提供商,500+个网络节点,不可能通过专线把它们使用类似full mesh的方式相连,复杂度太高。即使能搭建,专线的搭建周期长,带宽也不能大规模提升。另外成本方面,我们测算过海外公共互联网成本大概是专线的1%。基于这种情况,我们将MSDN定位为一个多云基础设施之上,基于公共互联网,来搭建的一个专线级别的低延迟、高质量的虚拟传输网络。

 

图片

 

MSDN架构分为控制面和数据面两大块。

 

控制面主要负责网络质量探测、路径规划和规则配置管理三个方面。网络质量探测中存在一些策略,例如机房A和机房B会进行独立、双向的质量探测。选择两个探测中相对较差的作为评分。如果A和B是三线机房,那么会在三条线路中选择较好的一条作为最终评分。数据面负责数据传输和转发,在即构MSDN架构中数据面扮演两个角色,一个是边缘、一个是中转。数据面将源端的数据逐跳发往目的端。

 

图片

 

图中展示了美国用户和印度用户之间的网络传输情况。依靠实时质量探测数据,MSDN可以很快发现链路中存在的线路故障。当故障发生时,MSDN快速从已有线路中选择一条,并进行秒级地自动化切换。案例中,数据从美洲到欧洲的路线走,故障发生以后,自动切换成美洲直接到印度的路线。线路自动切换大幅降低了网络故障的影响时长,保障音视频数据的稳定、高质量传输。需要指出一点,路径规划使用了基于网络质量分数的最短路径算法,并会考虑到容量和带宽成本、质量的平衡,所以最后路径的选择并不总是最优的,可能是次优的。

 

图片

 

图中是媒体服务器通过MSDN进行低延迟、高质量的传输来实现音视频通话的大致流程。MSDN除了支持全球任意两个流媒体服务器间的级联传输,也支持信令数据、IM等数据的传输。上海到孟买的线路,如果走公网丢包率常年在10%到60%波动,RTT在350ms左右,改为走MSDN后,延时在100ms左右,丢包率小于1%,可以发现MSDN对音视频体验确有提升。

 

图片

 

即构音视频使用MSDN其实也经历过迭代。

 

第一阶段是我们称为人肉运维的阶段,媒体的边缘节点是通过媒体中转节点去完成整个链路的传输。典型特征是静态配置,通过专线和互联网,当线路监控到波动或者专线容量满的时候需要人工调整,用户体验是有损的,画面静止或者黑屏。很快切入到第二阶段,只让信令数据走MSDN,MSDN仅仅提供路径规划,网络传输不走MSDN,仍是通过媒体本身的中转节点进行级联。现在已经完全把传输交给MSDN处理。

 

下面我将从研发和运维效率、线路故障切换成本和耗时和线路故障切换的用户体验三个方面来对比他们之间的差异。第一阶段研发工作量不大,但是运维工作量非常多。一旦网络出现抖动,电话告警就会出现,需要人工切换线路,而人工切换的时间和成本都比较高,会出现10多分钟画面静止不动的现象发生,用户体验很差。而且这个阶段是线路级切换,所有走这条线路的传输都会受影响。第二阶段整个体验完成了闭环,但是媒体之间的数据有状态,在切换路径时需要先关闭原有会话并重新建立新会话。如果链路节点特别多,需要通过密集信令把状态串联起来,就需要巨大的成本以及超过三秒的耗时。这三秒的耗时就会影响用户的体验。

 

现阶段使用分层架构,媒体业务工作者只要关注媒体业务本身,传输则是MSDN负责,只需要配置规则就可以做各种自动切换,因此研发和运维成本都很低。而且对于A和B来说,这只是网络层面的切换,甚至可以看成一个小小的网络波动,所以耗时只需要秒级。实测对用户体验的改动不是非常明显。

 

3.2 DNS优化

 

图片

 

经常运营海外业务的同学会发现LocalDNS存在一些问题,例如DNS被劫持或者失效、DNS解析慢或者失败、DNS解析错误等。为了解决这样的问题,即构自建了DNS,这个DNS并不复杂,关键在于能够通过HttpDNS解决localDNS的问题,聚集多云商服务容灾容错。另外,通过Anycast IP做就近接入,解决了原先解析慢的问题。当ZEGO DNS应用至业务中,会有很强的扩展性,会带来更精细化的流量调度。以工程实践为例,即构和海外第三方合作,CDN的节点在互联网上,虽然即构所有的节点都在MSDN上,但并没有纳入MSDN网络中。如何做加速层面的优化呢?首先,在全球各个主要区域维护种子IP,通过ZEGO DNS进行相应区域的种子IP的DNS解析获得可选的CDN节点。其次,进行CDN节点质量探测,择优选择CDN接入点进行CDN转推,流量的调度使CDN转推异常率从千分之二降至万分之二,极大提升了对接第三方CDN转推的质量。

 

3.3 全球统一接入

 

图片

 

优化前SDK会和后端存在HTTP 、TCP多条信令类的连接,在国内的网络环境下能接受,但是在海外,我们经常观测到客户端日志,一个HTTP请求往往10s都拿不到响应,海外弱网情况下TCP的建连耗时、抗弱网特性差、队头阻塞、传输效率低等问题开始显现。

 

图片

 

为了解决这个问题,即构提供统一接入服务。该服务和用户以及MSDN两端都用QUIC连接。在用户端改善通讯协议,在后端则连接上MSDN。

 

图片

 

这几年我们看到音视频领域终端接入协议使用QUIC或者类QUIC的协议已经成为标配。这样做的好处在于建连时延低。相比TCP+TLS+HTTP/2的3RTT建连时长,QUIC在首次建连只需要1RTT、缓存ServerConfig能做到0RTT,优势明显。再者,QUIC的多流策略,使流之间没有顺序,关系相互隔离,减少HTTP队头阻塞问题发生。其可前向纠错,通过发送冗余包来减少重传。还有,对比TCP基于连接的拥塞控制,QUIC可以做到流级别的流控,拥有更好的拥塞控制。海外的一些用户,在网络不好时,会在4G和WIFI间来回切换。QUIC支持网络环境变化时的连接迁移,因此在这种场景下用户体验得以提升。下文会介绍连接的复用。

 

上述第一种方式会有很多连接,但是统一接入以后,在客户端会只保持一个连接,通过这个连接来做各种请求。最近香港某某云的攻击特别频繁,但是对于已经使用统一接入服务的即构的内部服务,基本上没有相应的攻击情况。即使存在攻击,我们的边缘节点非常分散,因此可以很容易下掉受攻击的点,也可以快速部署大量的边缘节点。整个后端服务并未直接暴露在互联网上,通过客户端抓包不能直接感知到。当客户端和统一接入建立连接后,只需要配置和指定相应的服务路径,请求由统一接入转发,后续请求处理不再依赖客户端侧的域名解析。

 

图片

 

从客户的的日志分析对比来看,统一接入优化前接入成功率只有80%,优化后成功率达到98%甚至更高。耗时优化百分比30%+,甚至在一些弱网的环境下优化百分比接近90%。

 

3.4 多链路质量探测

 

图片

 

之前提到的主要是就近调度和接入,那么为什么还需要多链路质量探测呢?先了解一下即构就近调度的方式。当拿到客户端的IP后,通过IP库解析出客户端所在的地理位置和ISP,然后再做地理位置就近接入和ISP优先的选择。虽然即构也聚合了很多家IP库数据,并基于线上运营经验进行持续调优,但是IP库解析仍然存在不准的情况发生。再者,即使采用最好的节点,本地运营商网络情况复杂,也可能存在连接A链路不通,连接B会更好的情况。为此即构支持在通话前主动调用SDK质量探测接口,根据质量探测的评分出从高到低的多条链路,优先选择最好的。SDK在通话过程中如果遇到当前链路有问题,也会自动进行链路切换。这个优化对海外最后一公里的质量也有明显提升。

 

3.5多层级分发系统

 

图片

 

在多层级分发系统中,即构将拉流分为CDN、CDN QUIC、低延迟直播和RTC拉流四个部分。业界其他厂商一般是会根据客户的需求选择其中一种的解决方案进行接入。通常情况下,选择CDN的客户对成本相对敏感。当客户已经在海外大规模运营之后,反馈经常卡顿。对于这种问题,即构一开始的想法比较简单,在排除推流端问题以及节点之间推流的优化后,认为是CDN的问题。于是我们增加相应国家CDN的节点覆盖。这样的作法不仅耗时耗力,而且收效不可控,会面临CDN再次缩小的情况。后来我们直接简单粗暴的用后台云控对部分国家/地区切换到低延迟直播或者CDN QUIC。好处很明显,但随之而来的是客户对成本提升的抱怨。

 

在不断的优化探索中,即构找到了一种新的灵活的形态,可以把不同类型的拉流方式聚合,通过Qos质量评分自动升降级操作。虽然听起来很简单,但是其中有很多小的工程问题需要解决。比如切换到低延迟直播和RTC依旧不好应该如何处理?用户不停的在切换主播观看是不是每次拉流都做升降级处理?另外,还有存在误切的可能。游客拉流体验差并不是因为拉流端的网络,可能是推流的主播自身的问题。这些小细节在做分层时都要考虑到。在做多层级分发的同时,即构也保留了灵活调度的能力,用以服务拥有特殊需求的客户。这样不仅保证了容灾容错的能力,还做到了成本可控下质量最优。

 

3.6引擎关键技术

 

图片

 

最后是即构音视频引擎的核心能力,这块即构做了很多工作,意在更好的对抗海外弱网的环境。即构结合FEC与丢包重传各自的优缺点:自适应的选择FEC only,retransmit only或者hybrid FEC+retransmit,追求有效传输的最大化(95%以上的有效传输),在丢包率70%的情况下依旧能保证流畅的音视频通话。通过精准的带宽预测,带宽预测400ms以内估计误差小于10%,拥塞控制结合自适应码率,自适应帧率,自适应分辨率及时避免拥塞。带宽利用率95%以上。自适应评估网络缓冲水平,结合自研TSM(time scale modification)技术,追求流畅与延迟的最佳契合。在低码下提供高清效果,即构也有分层编码、ROI编码以及各种后处理的核心技术积累和沉淀。

 

四、总结回顾

 

图片

 

今天的演讲可以总结为三块。一是通过低延迟、高质量的传输网络解决网络传输问题。二是通过DNS、全球统一接入以及多链路质量探测的优化方式提升最后一公里的体验。三是让系统拥有自适应的能力。除此之外海外传输优化还有一些非常常见的细节点可以进行优化,例如资源的预加载、服务器IP和其他关键数据的缓存、耗时请求的串行修改并行化的等优化。

 

以上就是我的全部分享,谢谢大家的聆听。

...全文
198 点赞 收藏 回复
写回复
回复
切换为时间正序
请发表友善的回复…
发表回复
相关推荐
发帖
RTC即刻构建
创建于2021-06-07

215

社区成员

音视频技术干货的分享聚集!
帖子事件
创建了帖子
2021-11-17 14:40
社区公告

这里是音视频开发者小伙伴的聚集大本营!大家可在此集中讨论RTC开发相关内容、工作中遇到的问题、资源求助等。即构期待与大家共同打造一个开放、包容的RTC构建交流社区~