咱们常常听到很多做音视频 PaaS 云服务的产品会介绍本人有 200 个以上的节点，这听起来是个很大的数字，仿佛肯定可能比十几个节点提供更优的寰球网络覆盖和更优的音视频成果。事实真是这样吗？
Zoom 和 WebEx 都是服务寰球的视频会议产品，在疫情期间 Zoom 的日会议参与者达到了 3 亿，WebEx 平台用量也减少了三倍以上。要服务寰球 200 多个国家及地区的用户，如此大规模的在线会议，他们都部署了多少个节点呢？答案是：WebEx 在寰球部署了 12 个数据中心，Zoom 在寰球部署了 18 个数据中心。（数据参考自 https://tech.sina.com.cn/digi/2020-08-19/doc-iivhuipn9416086.shtml 和 https://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，这时，就须要一个在音视频各个技术点都有积攒的技术团队，在各个技术点都能谋求极致并能继续改良产品了。