构建一张音视频全球大网究竟需要多少个节点?Pano Backbone技术探秘

拍乐云Pano
我们经常听到很多做音视频PaaS云服务的产品会介绍自己有200个以上的节点,这听起来是个很大的数字,似乎一定能够比十几个节点提供更优的全球网络覆盖和更优的音视频效果。事实真是这样吗?

Zoom和WebEx都是服务全球的视频会议产品,在疫情期间Zoom的日会议参与者达到了3亿,WebEx平台用量也增加了三倍以上。要服务全球200多个国家及地区的用户,如此大规模的在线会议,他们都部署了多少个节点呢?答案是:WebEx在全球部署了12个数据中心,Zoom在全球部署了18个数据中心。(数据参考自https://tech.sina.com.cn/digi/2020-08-19/doc-iivhuipn9416086.shtmlhttps://help.webex.com/zh-cn/WBX28754/Where-are-the-Webex-Data-Centers-and-iPOP-Locations

是Zoom和WebEx没有资金部署更多的数据中心吗?抑或他们不愿意给用户提供更优异的视频会议体验吗?当然都不是,这是全球视频会议的领导者在技术上找到的最优解。

Part 1

更多的网络节点并不能降低时延

从技术上来说,网络分发本质上是hop by hop的,音视频通话也是这样,A和B进行音视频通话的本质就是将A的音视频数据通过互联网送给B,并将B的音视频数据通过互联网回送给A,数据从A到B中间可能经过了X个交换机、Y个路由器、Z个服务器等等。这些交换机、路由器等各种网络设备就像勤劳的小蜜蜂一样按照一定的路由规则将网络数据从一个设备运送到另一个设备,从而为我们构建了今天这样的高速互联网。

IP层及以下,例如路由器、交换机、防火墙、基站等网络设备都是采用硬件解决方案,数据分发效率非常高。熟悉Linux网络编程的同学可能会知道,在Linux服务端进行网络数据分发可能会面临这些性能损失:

  • 传统的收发报文方式都必须采用硬中断来做通讯,每次硬中断大约消耗100微秒
  • 数据必须从内核态和用户态之间切换拷贝,带来大量CPU消耗
  • 收发包都有系统调用的开销
  • 内核工作在多核上,为使全局一致,可能有锁总线等性能损耗

因此,在音视频分发网络上,硬件设备分发的效率是最高的,每多一个应用服务器,都会降低一次分发效率,增加一些网络时延。为了音视频分发的低时延,音视频设计者应该尽量减少网络分发所经过的节点数,尤其是应用服务器数。(有些场景需要利用硬件的高效率和软件的灵活性,感兴趣的同学可以了解一下DPDK技术)

那为什么有些音视频产品会需要200个以上的节点呢?在单一的一次通话中,如果总是需要引入多个应用服务器、即多个应用层节点来做音视频数据的分发,从数据路由角度而言这并不是最高效的做法。这些团队这么做的原因是因为多数音视频团队在构建实时音视频分发网络时参考了CDN的技术经验。

在CDN分发网络里,CDN厂商会在很多3、4线甚至5、6线城市部署边缘节点,这些边缘节点的带宽费用相对较低,边缘节点向中心节点回源实现了跨运营商的低成本分发,我们知道CDN服务于文件下载、视频点播和直播这样的应用,这些都是时延不那么敏感的,分发路径上经过了多个节点所带来的时延损耗并不会影响用户体验,CDN技术是一种低成本的用于大规模数据分发的技术方案。

而RTC这样的实时音视频应用对于时延是非常敏感的,采用类似CDN的分发技术在效果上并不是最优解。拍乐云Pano团队基于多年视频会议的研发经验,结合了WebEx全球网络技术经验和中国网络的实际情况,独创了Pano Backbone实时传输加速网络。

Part 2

Pano Backbone 实时传输加速网络

要构建一张全球音视频分发大网,问题的关键不在于多少个节点,或者说更多的节点参与网络分发反而可能有副作用。构建音视频全球大网的关键在于解决音视频全球分发问题,这些问题包括:

  • 各国出口带宽受限问题、防火墙问题
  • 各个运营商互联互通问题,尤其是中国的小运营商接入问题
  • 网络路由变化导致的Jitter问题
  • 网络传输协议的选择和拥塞控制算法的实现
  • 链路质量变化时的实时监控和智能调度能力

在解决这些问题时,拍乐云Pano团队作为有着丰富视频会议经验的团队,遵循分层、自适应、智能的原则,让上帝的归上帝、凯撒的归凯撒,该由网络层解决的问题就通过网络层来解决,该在应用层解决的问题就通过应用层来解决,该在传输算法层解决的问题就在传输算法层解决,充分利用了网络技术、传输算法等多种技术来多维度的高效解决了上述这些问题。

拍乐云Pano构建了一张覆盖全球的实时传输加速网络,由网络基建和应用层算法共同组成,保障了实时音视频的超高质量和超低时延,实现了全球网络覆盖和用户就近接入。网络链路质量随时都有变化,Pano Backbone实现了网络质量自反馈和网络链路自适应。

Pano Backbone由数据中心和POP节点组成,数据中心主要包含3大模块:调度中心、智能分发服务、媒体服务。当用户发起接入时,调度中心根据用户所在的地理位置以及不同的运营商,按照就近接入原则,分配离其最近的智能分发服务节点。智能分发服务负责链路加速,媒体服务负责分发。

Part 3

实现低时延音视频分发的更多要点

除了网络分发,音视频的时延和效果也取决于客户端的处理、服务端的高效分发等等,音视频应用是一个结合了算法和工程的系统性工作,最终的音视频效果由音视频引擎、音视频编解码、网络传输、弱网对抗、流媒体分发、网络加速等等多个方面共同决定,每一个技术点都会或多或少地影响时延和用户体验。

在多数时候,用户网络没有那么差,用户设备也没有那么差,各种音视频产品的体验相差不会太大。但是在实际场景中,总会有弱网、总会有设备资源和网络资源抢占、总会有各种corner case,这时,就需要一个在音视频各个技术点都有积累的技术团队,在各个技术点都能追求极致并能持续改进产品了。

阅读 147

拍乐云Pano
我们是一家由顶级音视频团队构建的实时通信Paas云服务公司,红杉资本投资,思科WebEx背景。我们通过提供...

我们是专注于RTC实时通信的拍乐云Pano,红杉资本投资,思科WebEx背景。我们通过提供极简、稳定和安全的SDK服务,让你的应用轻松实现音视频通话、互动白板、互动直播等能力。在这里,我们会分享关于拍乐云Pano的最新动态、技术心得、开源 Demo,以及使用 Pano SDK 的应用实践和场景案例。

12 声望
0 粉丝
0 条评论

我们是专注于RTC实时通信的拍乐云Pano,红杉资本投资,思科WebEx背景。我们通过提供极简、稳定和安全的SDK服务,让你的应用轻松实现音视频通话、互动白板、互动直播等能力。在这里,我们会分享关于拍乐云Pano的最新动态、技术心得、开源 Demo,以及使用 Pano SDK 的应用实践和场景案例。

12 声望
0 粉丝
宣传栏