zoom技术研究、视频会议架构、国际服务器

对于视频会议的较为深的技术研究，视频会议系统的架构，未来的发展趋势，还有国际服务器的交互，搭建，租赁，这些都有利于视频会议的变革，更好更快的为中国客户提供优质便捷的服务。

一、常规构架

系统主要有3种构架类型：Mesh、MCU、SFU，关于他们的透露在网上很难找到，这里就不再赘述了，推荐看如下表所示几篇透露就好：

WEBRTC三种类型（Mesh、MCU 和 SFU）的多方通信构架

二、ZOOM构架猜想

继续之前，建议您先读该系列产品前三篇文章，以便对ZOOM构架有个基本认识：

视频会议核心技术研究系列产品（一）：组织工作原理的简短透露

视频会议核心技术研究系列产品（二）：视频会议如何提供业界领先的截图容量（译）

具体来说以下的知识，就很难画出ZOOM的构架差不多是如下表所示这种子的：

这张ABCD 4人与会的左图描绘描绘了如下表所示的3件事情：

ZOOM Media Server它只负责流新闻媒体转换，不做任何的汇合与音频文件组织工作，而且它是个SFU（Selective Forwarding Unit），有别与传统的MCU（Multipoint Conferencing Unit）；

ZOOM Media Server它并非sizes布署的，而是布署在遍布全球各地的信息中心，信息中心差不多是12个左右（那个数字应会有变化，数字可能没有你现象的大，是因为经过的级数越少，延后会越低），而新闻媒体伺服器非常多，它们之间通过公有相连接展开流的跟帖（那个公有相连接我们在以后的字数再讨论）；

在多人与会的场景，每个参与者就近推拉流，只推一路上流，但拉取了其他参与者的流。如左图ABCD共4人与会，A除了推一路上自己的流（SVC流），还拉取B+C+D三路流（SVC流），以便看见对方截图，听到对方语音，其他参与者类似。

那个构架有哪些优点呢？差不多能归纳为如下表所示4点：

使用SFU展开流的跟帖，而并非使用MCU展开音频、汇合再音频文件这种的密集计算，节约了伺服器端的巨量成本。那个成本节约幅度有多大呢？一块高性能CPU/GPU，即使做宗乡卡这种中低码率的流的音频文件组织工作，能并行几十上千路音频文件就已经是高性能了，如果ZOOM使用MCU构架，以ZOOM的使用者规模，它买下全球今年产的大部份CPU/GPU估计都不够；

由于不需要音频文件，只做流跟帖，音频文件延后没有了，实时性更好了；

使用云原生构架，而并非sizes服务工程项目，这种使用者能就近接入，推流和拉流质量都会提高；

由应用程序展开流的音频播放和流的组合，这种应用程序能很自由的展开视图的转换和显示布局的调整；

完美！

但是，等等，，，貌似经不起进一步推理：

首先，使用这种具体来说SFU构架，如果4人与会，一种参与者推1路流，拉3路流，所以整个全体会议推3路，拉12路；如果像ZOOM那样支持个100百路以下的与会，那整个全体会议就是推100路，拉近10000路！您没看错，拉流数被乘数级放大了。一种小型现场直播网站用户数的观众未必能有一万人，而开个100人的会耗掉的伺服器频宽就等于一种小型现场直播网站的用户数量，这太夸张了。而且，这种SFU构架一大问题是拉流数太多，伺服器用户数量消耗太大；

其次，即使你能承受那个用户数量消耗，而应用程序要同时拉这么分路流，要音频音频和截图，要渲染播放，应用程序CPU缓存是受不了的，普通PC跑个10路就已经很费劲了，更别提上千路和移动端了。而且，第二大问题是应用程序消耗的天然资源太多，用户数的人数非常有限；

再次，即使前两个问题能抗下来，而一种应用程序同时维护上千个相连接，那个相连接的稳定性也是让人怀疑的。

受限于以下的三大问题，而且具体来说SFU构架的宗乡卡系统虽然很多，有关的自由软件工程项目也琳琅满目，

三、ZOOM构架调研

所以ZOOM是如何做到的呢？打开ZOOM应用程序，参与一种100人的宗乡卡，打开Windows任务管理器（如下表所示图），发现CPU、缓存消耗都不高，甚至频宽消耗也不高，由此，本栏做了一系列产品调研组织工作：

图3：性能监控

3.1 界面优化

首先，从界面上看，难看见ZOOM并不会在一种页面同时显示大部份与会使用者的画面，目前最多25路截图（如下表所示示例图，这里不方便贴本栏的与会图，该图是网上找的），想要看见其他使用者，你需要翻页，这表明它没有下载大部份使用者的画面，而只下满一页而已，这是个取巧和妥协的设计，能节约大量的截图音频和渲染的天然资源消耗，也节约了大量的频宽。这种设计很多平台都模仿了，有些平台还用图片替代截图以降低应用程序天然资源消耗。但是音频确不同，你能听到大部份与会者的声音，这表明它下载了大部份与会者的音频信息，so，HOW？

3.2 相连接优化

然后，我们来看看ZOOM应用程序和它的伺服器端创建相连接的情况，打开Windows Power Shell, 输入如下表所示netstat命令，找到应用程序用到的路由器天然资源：

其中11756是应用程序的进程号，.143那个TCP相连接在入教开始期是ESTABLISHED的状态，几秒钟后变成CLOSE_WAIT状态。能看见，在与会的开始期，应用程序共使用了5个路由器，2个TCP路由器，3个UDP路由器，很明显TCP路由器是为了走HTTPS/WSS协议，这必须是掌控和链路有关协议，而UDP路由器必然是新闻媒体信息路由器。

那个路由器挤占情况的调查是很有意义的，因为具体来说图1展示的SFU构架所实现的宗乡卡系统，应用程序路由器挤占一般都不止那个数，即使使用RTP/RTCP/Data都走同一种路由器的MUX模式，一路上流也会开启一种信息路由器，另加一种链路路由器，也就是至少一种TCP路由器，一种UDP路由器，所以在参加这种一种100人的全体会议，路由器挤占正常必须是200个（这里说的一般，不排除有些精心设计的产品，实现了路由器F83E43Se核心技术）。而大部分自由软件工程项目都是具体来说图1的逻辑开发的SFU，这估计是这些开发者们深受Streaming模式的影响。

ZOOM只使用了4个路由器，这难让人有如下表所示猜想：

即使在多人全体会议下，ZOOM与伺服器端只创建4个相连接通道？包括1个链路TCP相连接，另加3个信息UDP通道？

.143那个相连接必须只是使用者认证或建连链路相连接，因为它只在入教初始期创建，然后先期就不用了；而.42那个相连接是链路/掌控相连接，整个全体会议过程其相连接一直保持着。查了这两个IP来源，都显示：52.81.151.143北京市北京 Amazon云/52.81.215.42北京市北京 Amazon云， 这与前三篇文章透露的一致，ZOOM使用了较多的Amazon云服务工程项目。

3.3 伺服器端信息传输与转换

再然后，祭出品驭型大法，抓取入教期并采集几秒钟信息，本栏做了如下表所示分析：

第一步，看应用程序和.42这台伺服器都有哪些信息交互，把该伺服器IP信息过滤出来如下表所示：

能看见，应用程序TCP和UDP都是和这台服务工程项目通讯，由此可见这是一台新闻媒体服务工程项目，也既ZOOM SFU，所以该新闻媒体伺服器的TCP 443路由器必须是链路/掌控路由器，使用的HTTPS/WSS传输协议；443路由器的信息被加密了，我们无从得知其传输内容，但几秒钟的品驭型，那个路由器总共传了 262KB的信息（如下表所示图），由此可见其只展开了掌控命令传输。

第二步，看看新闻媒体信息的通讯情况，发现往应用程序UDP 61094/61095/61096这3个路由器的发信息的都是伺服器端的8801路由器：

由此可见伺服器端只使用一种8801路由器提供通讯新闻媒体信息服务工程项目。

这表明，伺服器端8801一种路由器服务工程项目了分路音截图流，大部份音截图都从那个路由器通讯；这与一般的自由软件SFU工程项目又有所不同，自由软件工程项目一般使用libnice库实现ICE，一种相连接占至少一种路由器，每路流都一种相连接的话，那伺服器端会挤占多个路由器，除非对libnice展开路由器F83E43Se改造。

当然，另一种假想是应用程序和伺服器端只创建了一种（非常有限个）相连接，F83E43Se那个相连接传了分路流。

UDP 61096路由器：在本栏关闭截图并降噪的场景下，61096路由器收到的的信息量是其他路由器的5倍以下，由此可见它接收了伺服器端的截图流。在初始期，每个路由器都有个相连接握手过程，必须并非DTLS 1.2，在品驭型信息的其他地方未见有类似的过程，由此可见那个通道只创建了一种逻辑相连接。

那个结论非常重要，虽为具体来说不完全信息的揣测，但却非常合理，ZOOM和应用程序的一种路由器只创建一种相连接来传输音截图信息，但那个相连接里传了分路流。这有别于大部分自由软件SFU工程项目，它们大都是每路流建一种相连接，这导致其性能开销大很多。

UDP 61095/61094：揣测其中一种是上行传送路由器，一种是音频路由器或信息路由器，不过这已经不重要了，没有太大参考意义。另外就是UDP路由器上下行都有信息包，这些路由器必须被RTCPF83E43Se了。

四、展毛

到此已经有些字数了，先来做个展毛吧，更细致的研究等先期再探讨。

根据以下初步研究结果，我们来重画一下ZOOM的构架，必须是这种的：

这图和图1、图2在逻辑上是有较大差别的，差别在于应用程序和伺服器端是创建一种（非常有限个数）相连接而并非每路流一种相连接，伺服器端做坑仔口的转换，这极为重要，这体现了SFU中的（Selective），而不仅仅是（Forward）。

而且，展毛一下ZOOM构架有如下表所示特点：

关于SFU：

使用SFU构架，伺服器端只做流跟帖，不做任何的编音频文件组织工作；

伺服器端和应用程序只创建非常有限个UDP新闻媒体信息相连接，相连接F83E43Se来传送分路流；另加一种掌控用HTTPS/WSS相连接；

为减少应用程序压力，只发非常有限路数的截图流；但传送了大部份发言使用者的音频流，揣测只传送发言使用者的声音包，不发降噪包，这能降低应用程序天然资源消耗，这在SFU端难做到，这也是它巧妙的地方；

关于服务工程项目布署：

在全球集中布署了一些信息中心，但是信息中心数量可能不多，因为越多级的跟帖导致的延后会越高；

伺服器间使用公有相连接，没有找到有关核心技术资料，揣测和应用程序相连接一样也使用了减少相连接数和减少信息传输量的有关核心技术，先期字数我们再谈探讨这些公有相连接；

数据流：

使用SVC截图数据流，根据应用程序反馈，传送适配的层。