现在，没有呼叫功能似乎找不到信使。 这对用户来说很方便，因为所有通信都可以在一个应用程序中进行。 如果我们结合媒体上所有可用的统计信息，结果表明人们每天通过Internet进行的通话时间超过十亿分钟。 随着技术的发展，视频通信的份额正在增加，因为视频可以更好地传达对话者的情绪，并允许您创建在场效果。
视频通话服务的新挑战是立即聚集一个来自世界各地的全家人或一群朋友，或在同一项目上远程工作的同事进行计划。
视频和磁带平台的开发负责人Alexander Tobol（
alatobol ）将向您展示
幕后有一个视频呼叫服务，使用哪些技术和黑客技术来制作会议服务器以及如何正确传输视频。 快来学习如何将一对一呼叫服务转移到100人的团体呼叫中，以及为什么需要这么多参与者的支持。
本文基于有关
HighLoad ++ Siberia的报告，其中Alexander Tobol试图给出完整的图片。 如果您已经熟悉该主题的其他材料（例如，
有关视频传输和
网络协议的功能 ），则可以跳过理论部分，直接进入
解决方案 。
文章概述：通话记录
带有视频的第一个著名的通话应用程序是Skype，它于2006年问世。 在Odnoklassniki中，我们在2010-2012年基于Adobe的解决方案发起了呼叫。几年前，我们在WebRTC上完全重做了它（有关此发布的更多信息），去年我们添加了群组呼叫。 本文将讨论这种过渡。
为什么我可以告诉您该怎么做？ 因为我们每月使用电话的听众超过1000万人，而
我们每天有超过200万的电话 。 此外，其中一半以上是通过移动平台发生的。
群组通话是增长最快的服务，我们的目标是100个同时参加的会议。 为什么这么多？ 首先，有时您想与您的朋友和同学分享美丽的镜头或举办研讨会。 其次，即使您认为您的服务不需要什么，一切也会改变。
现在看来，不需要100个参与者的视频会议，而五年前，他们问我为什么要启动4K视频。 现在4K电视已司空见惯，而我们早在2014年就已准备就绪。
关键不是提前。 如果您想提供优质的服务，请提高您的要求标准。
如果您可以拨打50到100人的电话，那么对于6到10个用户来说，一切都会很好。
每个呼叫服务具有4个相对独立的组件：
- 发信号 任务是呼叫订户，交换初始数据，告知每个订户可以做什么，然后建立一个通道，通过该通道可以传输视频数据。
- 视频/音频。 视频和音频数据使用编解码器压缩。
- 网络。 有必要确保在不良网络中工作，实现数据包恢复，p2p连接等。
- 拓扑 -在组呼叫的情况下添加。
您可以单独讨论这些部分中的任何一个。 但是，我想大致了解通话的工作原理，因此我将尽力使所有内容都适合一个故事。
在开始使用该服务之前，您需要确定以下
要求 ：
- 快速建立连接，以便在对话者拿起电话后立即建立连接。
- 高通话质量，因此视频不会崩溃也不冻结。
- 通话中的参与者人数 ，以便您可以聊天，最多100位参与者。
- 呼叫者之间的等待时间短。 由于Polycom根本不适合我们，因此延迟时间为1.3 s。
以下是表达这些对群呼要求的具体含义：呼叫开始不超过1秒； 300 Kbps视频稳定运行的网络； 从呼叫者到收听者的等待时间不超过0.5秒； 一次通话100个用户。
怎么了？
如您所知，网络中的数据以数据包的形式传输：有一个套接字，向其中发送数据流，所有内容都飞走了，就好像在黑盒子中一样，它已经组装好并且可以工作了。
但是网络是不同的。 一半的通话是通过移动网络进行的，它们并不总是看起来像高速公路。
网络可能会过载，然后数据将丢失，必须将其还原，从而进一步加载网络。 有些网络似乎一切正常，但数据包仍然消失-例如，由于Wi-Fi路由器位于钢筋混凝土墙后面。
网络功能
我们将分析描述网络质量的主要特征。
RTT
往返时间-服务器将数据发送到客户端到收到确认之间的时间。
记住，我们要在1秒内建立连接。 如果往返时间为200毫秒，则在建立连接（例如，通过TCP加上一些TLS）的情况下，
仅在连接上可能会丢失500毫秒 。 仅剩500毫秒，即 还有几个请求，之后应该建立连接。 因此，对于RTT的额外要求，您需要非常谨慎地工作。
一个例子：
$ ping google.com 64 bytes from 173.194.73.139: icmp_seq=5 ttl=44 time=211.847 ms round-trip min/avg/max/stddev = 209.471/220.238/266.304/19.062 ms RTT = 220ms $ curl -o /dev/null -w "HTTP time taken: %{time_connect}\nHTTPS time taken: %{time_appconnect}\n" -s https://www.google.com HTTP time taken: 0.231 HTTPS time taken: 0.797 HTTP = 230ms HTTPS = 800ms
使用RTT = 220ms时，通过https接收响应最多需要800 ms。 因此，如果您具有Web套接字安全连接，则使用ping命令将使整秒钟消失。
该表显示了在移动网络中测量的握手延迟（在
此报告中，有关移动网络中应用程序操作的更多详细信息）。
通量
您可以根据需要将数据包发送到网络：分批发送或立即将所有内容放入缓冲区，它们仍将均匀地到达客户端。 每秒的数据包或数据数量是带宽或带宽。
问题在于
移动网络的带宽在不断变化 。 如果它急剧下降，并且数据以相同的比特率传输，则它们显然会丢失，用户的呼叫将“挂起”。 这也必须进行斗争。
丢包
传输数据时，数据包可能会丢失。 在这种情况下，可以选择：跳过部分数据包并获得失真，或者尝试重新传输数据包并获得冻结帧。
抖动
事实是，数据包一次不会均匀到达，而是以一定间隔进入捆绑数据包。
抖动易于测量：
PING highload.ru (178.248.233.16): 56 data bytes icmp_seq=11 ttl=43 time=117.177 ms icmp_seq=12 ttl=43 time=132.868 ms icmp_seq=13 ttl=43 time=176.413 ms icmp_seq=14 ttl=43 time=225.981 ms
Pinganuli highload.ru几次（ping是一个不稳定值，有必要进行平均），我们得到的平均抖动为：
((132-117)+(176-132)+(225-176)) / 3 = (14 + 44 + 79) / 3 = 46 。
假设我们传输视频，并且一帧是网络数据包。 连续播放了几帧，但第三只鸟由于抖动而延迟-我们得到了冻结帧。 因此，您需要在某个位置累积软件包并均衡该效果。
也就是说，要表征无线网络，只需知道以下值即可：RTT（往返时间）； 带宽BW（带宽）； 丢包率； 抖动。
用户是什么样的？
在开始优化网络工作之前，您需要确定用户拥有哪种Internet-也许每个人都有一个完美的网络，任何解决方案都可以使用。
在80％的情况下，最终用户使用无线连接：它是移动网络或Wi-Fi。
在俄罗斯，西部地区和大城市以外，平均网络特征为：RTT-200毫秒，带宽-1.1 Mbps，数据包丢失-0.6％，抖动-5ms。
我们将这些价值按网络类型划分，并意识到有必要进行学习。
通话开发功能
许多人忘记了，但是LTE和3G是不对称的通信通道：下行链路始终大于上行链路。 根据协议类型的不同，此比率可以从15/85到30/70不等。 设计呼叫时，这一点很重要。
如何检查您的客户拥有哪个渠道？
您可以看一下speedtest，移动和固定Internet之间的速度之比是多少。 事实证明，在世界范围内，固定互联网也是不对称的。 幸运的是，在俄罗斯，它是对称的：在俄罗斯，通过Wi-Fi固定的互联网上的上下行比率为50/50。 我们将专注于这样的价值观。
底线：无线网络非常流行且不稳定。
- 超过80％的客户使用无线互联网。
- 无线设置正在动态变化。
- 无线网络具有很高的丢包率，抖动率和重新排序率。
- 不对称的上/下行信道比例为30/70。
来电
有了这些知识，让我们返回到组调用的实现。 考虑一个简单的组调用算法，然后对其进行优化。
步骤1.爱丽丝想打电话给鲍里斯（Boris）并向他发送一个要约，其中要报告她所能提供的一切，其中包括协议，设置等。
步骤2. Boris回答Alice，之后建立传输连接。
步骤3.之后，音频/视频数据的交换开始。
任何呼叫的架构看起来都类似于下图。
总有一个共享服务器，但是建立连接后，用户已经可以传输p2p数据或通过第三方服务器进行传输。
摄像机捕获数据，然后将其编码在设备上并将其发送到套接字连接。 它们通过网络，由编解码器在另一端播放，并显示在屏幕上。
详细考虑算法的所有步骤，并尝试从一对一呼叫切换为群组呼叫。
发信号
任务：报告呼叫并建立数据连接。
一切都非常简单：
- 爱丽丝打电话，通知会发送到移动设备或浏览器上的鲍里斯。
- Web套接字或任何其他连接已建立。
- 此后，进行协商-爱丽丝（Alice）和鲍里斯（Boris）同意。
- 在一部设备上拿起听筒后，通话会在另一部设备上自动结束。
Odnoklassniki中的呼叫平台支持各种客户端和传输。 它们都靠近某种服务器，该服务器用于服务呼叫和转发消息。
如果服务器崩溃或安装了更新，则存在一个永久性存储，其中记录了所有消息。 万一服务器丢失，您可以轻松切换到另一台服务器。 这就是ZooKeeper所做的。
唯一的困难是
一次 。 我们不想两次应用某些消息。 这个问题很简单地解决了：所有消息都有序列号-单个消息两次都不会到达。
另外，在创建呼叫时需要小心。 一个人可以创建呼叫，挂断并创建另一个呼叫。 或者它可能不会挂起，但仍会创建另一个。 所有这些呼叫都是唯一的-尚不清楚这是中继还是用户双击呼叫按钮。 它很容易修复：在客户端上生成唯一的ID，并在其上执行重复数据删除。 原则上，
发信号没有困难 。
轻松完成向群组发送的p2p信号。
现在，爱丽丝不仅发送给鲍里斯，而且还发送给迪玛。 他们收到了他们的同意，数据交换渠道出现在他们之间。
音频/视频
为了应付小组通话并了解需要什么技术，我们将不得不谈一谈什么是视频。
视频为每秒24或60帧。 为了压缩它们，使用了编解码器。 编解码器的主要本质是每隔几帧就有一个参考帧（例如JPEG），中间帧是通过更改来确定的。
在上图中，机器的第一帧是参考帧，在下一帧中，仅对更改（机器的运动）进行编码，而在下一次仅对更改进行编码。
这称为图片组-可以解码的一组独立的互连帧。 编解码器是帧之间转换的算法。 编解码器越陡，压缩数据就越好，并且需要更多的资源。
关于编解码器比特率的比率，有一些通用规则（请参阅
链接 ）。
用于呼叫的最受欢迎的编解码器是
H.264和VP8 。 H.264之所以出色，是因为它在任何地方都可以正常工作并且不会消耗电池。 但是通常在电话上只有一个编码器（编码器）和四个解码器。 对于其他所有内容，您都需要消耗大量电池的VP8软件。 值得将组呼叫的优先级更改为H.264（请参阅有关如何执行此操作的
链接 ）。
编解码器可以使用可变（可变比特率）或恒定比特率（恒定比特率）进行编码。 设备上的许多编解码器不支持恒定的比特率，因此您必须忍受左侧的图片。
音频编解码器
有各种传统的音频编解码器，例如G711。 Opus编解码器非常受欢迎-它解决了低比特率和高比特率的编码问题，因为其中包含Skype的SILK和音乐的CELT编解码器。
值得一提的是，Opus具有前向纠错（FEC）主动纠错算法。 对于音频，此算法的工作方式如下：在每个数据包中，存在高质量的数据，并且一段时间内来自较低质量的前一帧的数据。 因此，如果先前的数据包丢失了，您可能会以低质量获得先前数据包的数据，并以某种方式丢失。 平均而言，结果还不错。
使用音频编解码器时，有趣的是该图，该图显示了输入信号质量与比特率的比率。
可以看出，Opus解决了几乎所有问题。 有趣的是，要注意在各种托管服务中对视频进行编码时使用的AAC，以及仅用于音频且最高32 Kbps正常工作的旧Speex编解码器。
媒体病理数据
为了了解拓扑如何工作，拓扑具有什么功能，您需要了解视频编解码器如何处理损耗。
在第一种情况下，什么也没有丢失，我们看到了一张好照片。 在第二行中，丢失了一个随机帧-图片中有小的伪像。 在第三种情况下，参考系消失了，因此，直到下一个参考系，将显示彼此随机重叠的变化。
显然，制作参考帧通常很昂贵，因为比特率不断增长。 因此，几乎所有的呼叫服务都以某种方式支持在丢失的情况下请求参考帧的能力。 在WebRTC中，这称为完整INTRA帧。
最简单的拓扑是将所有视频发送给所有其他会议参与者。
我们启动一个编解码器，然后开始传输视频。 爱丽丝打开摄像机（编解码器），将视频发送给鲍里斯和迪玛。 但是，如果Dima的互联网质量不佳，鲍里斯（Boris）就会受苦，因为您需要降低整个视频的质量。 如果迪马（Dima）丢了球并要求提供一杆，鲍里斯（Boris）也会得到，尽管他不需要他。
另一方面，您可以将所有视频粘贴在一个流中。 这将需要特殊的设备，并且可能会有额外的延迟，但是这种解决方案也存在。
以最小的延迟传输或交付视频和音频
我们可以选择TCP或UDP协议。
可能每个人都记得TCP是一种可靠的协议，在丢包的情况下，TCP会再次发送它们。 这就是为什么可以按以下顺序排列帧的原因。
如果数据包中缺少数据包，则可以随意跳过视频中24帧中的这一帧，但是TCP将不允许您接收以下内容，除非您发送丢失的帧。
通过TCP传输视频效率极低。 建议将UDP用于此类任务，并且所有呼叫服务都应使用UDP。
本文提供了这两种协议的所有功能，并解释了为什么所有流都可以在UDP上工作。 作为今天主题的一部分，足以让我们知道UDP并非在任何地方都可用，它不能在3％的网络中工作。
通常，用户可以在他们之间建立P2P连接。
这是最有利可图的，因为如果我们在新西伯利亚互相打电话，最好是直接通信而不使用额外的服务器来提供杠杆作用。
但是NAT存在，现在有97％以上的用户位于其后面-很少有外部IP。 一方面，IPv6迟早会解决此问题。 顺便说一下，在俄罗斯，MTS是第一个启动它的公司。 现在，他们完全支持IPv6，并且所有客户端都具有白色IP。
NAT可能会突破，也可能不会突破，然后您将不得不通过服务器使用回退。 还有
一篇有关如何突破NAT的
文章 。
传输和帧之间的抖动缓冲区
我们继续前进。 现在我们需要抖动缓冲器来均衡抖动的影响
我们主动开始显示具有某些延迟的帧，与此同时，我们在缓冲区中以相同间隔排列帧。
缓冲区动态增加。
如果丢失了帧，并且图片被冻结，则缓冲区增加，然后我们已经在使用这种大小的缓冲区。
但是当您需要减少缓冲区时，可能会出现相反的情况。 例如，网络已经稳定，需要花费时间。 如果您只是减少缓冲，那将是荒谬的，人们将开始以侏儒的声音非常快速地讲话。 因此，有一些特殊的算法会无意识地调节音频速度：消除单词之间的停顿或语音中声音过长的崩溃声音。
如果要对视频进行转码并修复某些内容，则首先需要具有抖动缓冲区，其延迟将不小于此网络的延迟抖动。 也就是说，它肯定会增加延迟，并且我们记住我们确实希望保持在0.5 s之内。
呼气-理论结束了！
通话确定
在进行群组通话之前，我们进行了p2p通话，使用了WebRTC库，收集了Web和移动客户端，并编写了信令。
竞争对手分析
当您不知道该怎么做时，请看看您的竞争对手。 作为参考，我们选择了一组：Skype，WhatsApp，环聊，ICQ，缩放。 我们测量了群组通话的最大参与者人数，延迟，电池消耗和质量。
最有趣的是确定延迟。 我们这样做：打开计时器，开始拍摄视频，打个电话。
100毫秒-从视频到达镜头那一刻起，到在手机矩阵上绘制视频之前的摄像头延迟。 之后，视频将发送到网络，并且通话中已经存在310毫秒的延迟。
不要忘记测量设备上的CPU使用率。 从iOS 12开始，可以系统地执行此操作，但是我们以旧的方式使用高温计。
得到了以下结果：
WhatsApp和ICQ最多有4个呼叫参与者，Skype有25个（Skype for Business 250），而Hangouts和Zoom每个都有100个参与者。 环聊曾经有大约35位成员，现在他跳到了100+部分。
缩放的延迟时间略长，但是环聊会消耗更多电池电量。 在我看来，Zoom具有更好的质量，但是有些文章则相反-这是一个主观指标。
一些服务使用开放的WebRTC，其他服务使用专有协议。 但是很明显，您在下面使用哪种传输方式不会影响通话的参与者数量。 解决方案有100个呼叫，各自的协议（Zoom）和WebRTC（环聊）。
从2到N
考虑一个有趣的情况：有一个客户端具有非对称通道，输入3 Mbit / s，输出1.5 Mbit / s，丢包0.6％，抖动50毫秒。 分辨率为600 bps的高清视频（1280x720）的比特率为1.5 Mbps，分辨率为640x360的视频（我们称之为LOW）。 我们要传输很酷的视频。
如果有两个人呼叫p2p，那么一切都很简单。 他们有足够的输入网络，输出网络足够紧，因为通道是非对称的，并且编解码器没有问题-所有编解码器都是免费的。
当我们开始进行群组通话时，我们需要重新连接所有人。 拓扑的最简单版本是
Mesh或“ all to all”。
不需要中间服务器真是太好了，但是为所有人提供具有此类特征的客户的视频变得越来越成问题。 而且，如果客户不能将视频单独分发给某人，则您需要降低质量，因为通用流是为每个人编码的。
在这种情况下，对于5个参与者，3或4 Mbps都不够。
因此，在群组通话中的WhatsApp中，最多有4个参与者，并且只要他们使用Mesh，就不再是参与者。
另一种选择是
在服务器上收集整个图片。 这对客户端来说是最有利可图的：它与服务器建立了一个连接，服务器收集了图片，客户端将其收回。
但是，假设我们来自Petropavlovsk-Kamchatsky，Komsomolsk-on-Amur和新西伯利亚的用户希望通过Moscow服务器聊天。 自然，结果将非常糟糕。 CDN的存在会有所帮助，但仍然会获得大量的抖动缓冲区，这将总体上增加延迟。
下一个拓扑-
结束混合 -建议不要在服务器上收集一般图片以避免这些延迟，而只是抛出数据包。
也就是说，这种拓扑中的服务器只是传输数据的中继。
一切都变得更好了：用户收到呼叫中所有其他参与者的信息流，并且仅发送一次自己的信息。 但是同样存在问题：
- 质量 您的信息流的所有收件人都具有不同的网络。 如果一个人的互联网连接不佳，则视频需要以低分辨率传送给他，因此，图像将对所有人不利。
- 风暴参考系 。 如果互联网状况不佳的人不断要求提供参考框架，那么每个人也都会收到意见。 这是比特率的低效使用，质量再次下降。
如果使用
集中式系统 ，即所有视频都收集在服务器上。 这需要许多编码阶段，这既增加了等待时间，又需要额外的硬件。 相反，在End混合中，一切都是快速而简单的。
缺点拓扑：- 网格-最多4个成员。
- 集中式-转码和抖动问题。
- 结束混合-质量限制和风暴参考帧。
只有ICQ和Skype可以在网状拓扑上工作，其余所有都是端混合。 但是，正如我们所记得的，所有服务的特征都是不同的-这意味着不仅有End混合，还有其他。
环聊通过结束混音来解决问题。
每个客户端上都会启动两种编码器：高质量的H.264和低质量的VP8。 因此，对于具有良好Internet的用户，服务器将传输高质量的视频，而对于那些Internet较差的用户，情况会更糟，并且质量较差的视频会适应最差的网络。 两种品质都不错，但这是来自客户的额外流量和电池消耗。 但是没有抖动缓冲区
该表显示，环聊运行时，手机最容易发热，延迟最小，但是质量受到影响，因为低质量仍然会吞噬高比特率。
, : - , H.264, ( ) End mixing . centralized-, , , , .
, : . , , , , - . , .
.
, , , latency . , , , , . centralized, , , jitter- . , , .
«», . 100, 50, 20 . .
— , 5 . . : , , , — .
«» , , , — . : , - , fps. , — . - , . , .
Mesh 3-4 latency, , Mesh. , HD End mixing, a SD — centralized.
Zoom.
, - , Zoom , WebRTC.
WebRTC , .
.
CPU , . — , , , , CPU , . , .
: , , .
screen sharing . screen sharing, , . screen sharing . , fps — , , .
. — centralized, , . , .
, , , . , , .
, , - . .
Packet pacing
-, UDP- . UDP pacing. UDP- , .
, UDP , 21 100%. — .
pacing? , (
) — , . , , , , , , - .
:
: , pacing , —.
packet pacing?
, ( ) , , - . ( ), , , .
— packet loss , pacing.
MTU
TCP , MTU. UDP, , MTU — , .
MTU 1500, MTU 1100, . , , , , , ( ). , MTU .
TCP , . , MTU: - , , , MTU. , MTU, , .
.
, : , , . 98% 1350.
MTU = 1350 , , 2% — , .
WebRTC SACK, NACK, FEC. .
, 1–3% — , .
WebRTC negative acknowledgement (NACK).
, , - , .
, TCP acknowledgement, selective acknowledgement. negative acknowledgement , FEC (Forward Error Correction).
, SACK, NACK, FEC,
.
FEC , , . : , , . , , — .
FEC — XOR, , , . , - .
, . , , , FEC-. , , , , .
, ,
. , :
- 90% 500 /.
- — 3-4, Mesh End mixing.
- — 27 (, ).
Check List
:
- Packet pacing.
- MTU discovery.
- .
- C .
, signalling, WebRTC, , , - .
, :
- Packet loss: , packet pacing, FEC, MTU.
- : back pressure , FEC-.
- Jitter jitter buffer, latency.
- RTT: , signaling.
WebRTC — . RTP, , , . WebRTC .
, Zoom, Skype Line, . . . , ,
UDP- ( , WebRTC), . , , . , Google STADIA.
STADIA — , . WebRTC, , . Google WebRTC. WebRTC SRTP WebRTC QUIC. , , .
QUIC, . Chrome c Android Google YouTube, TCP — QUIC UDP Google. 30% QUIC/UDP.
QUIC 20-30%, TCP. - QUIC , .
结论
, . , : signaling; / ; . , , .
?
/ .
, , —
. , latency, . , ! - :)
HighLoad++ . ( ) , 6-7 2020 . , .