视频交流是Vimbox平台上师生交流的主要方式。 我们很早之前就放弃了 Skype，尝试了几种第三方解决方案，最终选择了 WebRTC - Janus-网关组合。 有一段时间，我们对一切都感到满意，但一些消极方面仍然不断出现。 结果，创建了一个单独的视频方向。
我请新方向负责人基里尔·罗戈沃伊 (Kirill Rogovoy) 谈谈 Skyeng 视频通信的演变、发现的问题、解决方案以及我们最终使用的拐杖。 我们希望本文对那些通过网络应用程序自行创建视频的公司有所帮助。
有一点历史
2017 年夏天，Skyeng 开发负责人 Sergey Safonov 在 Backend Conf 上发表演讲，讲述了我们如何“放弃 Skype 并实施 WebRTC”的故事。 有兴趣的可以观看演讲录音 （~45 分钟），在这里我将简要概述其本质。
对于天成学校来说，视频交流一直是师生交流的优先方式。 起初，使用了 Skype，但由于多种原因，它绝对不能令人满意，主要是由于缺乏日志以及无法直接集成到 Web 应用程序中。 因此，我们进行了各种实验。
其实我们对于视频通讯的需求大概是这样的：
- 稳定;
— 每节课价格低廉；
——记录课程；
— 跟踪谁说了多少话（对我们来说重要的是学生在课堂上说的比老师多）；
——线性缩放；
- 能够同时使用 UDP 和 TCP。
第一个尝试是在 2013 年实施 Tokbox。 一切都很好，但结果却非常昂贵——每节课 113 卢布——并且吞噬了利润。
然后在 2015 年，Voximplant 被整合。 这是我们需要跟踪谁说了多少话的功能，同时该解决方案要便宜得多：如果只录制音频，每节课花费 20 卢布。 但是，它只能通过 UDP 工作，无法切换到 TCP。 然而，大约 40% 的学生最终使用了它。
一年后，我们开始遇到有特定要求的企业客户。 例如，一切都应该通过浏览器进行；公司只开放http和https； 即没有 Skype 或 UDP。 企业客户=钱，于是他们又回到了Tokbox，但价格问题并没有消失。
解决方案 - WebRTC 和 Janus
决定使用 。 它负责建立连接、编码和解码流、同步轨道和质量控制以及处理网络故障。 就我们而言，我们必须确保从摄像头和麦克风读取流、绘制视频、管理连接、建立 WebRTC 连接并向其传输流，以及在客户端之间传输信令消息以建立连接（WebRTC 本身仅描述了数据格式，但不是其机制传输）。 如果客户端位于 NAT 之后，WebRTC 将连接 STUN 服务器；如果这没有帮助，则连接 TURN 服务器。
常规的 p2p 连接对我们来说还不够，因为我们想记录教训，以便在出现投诉时进行进一步分析。 因此我们通过中继发送WebRTC流 。 结果，客户端不知道彼此的地址，只能看到 Janus 服务器地址； 它还执行信号服务器的功能。 Janus具有我们需要的许多功能：如果客户端阻止了UDP，则自动切换到TCP； 可以记录UDP和TCP流； 可扩展； 甚至还有一个用于回声测试的内置插件。 如有必要，Twilio 的 STUN 和 TURN 服务器会自动连接。
2017年夏天，我们运行了两台Janus服务器，另外还有一台服务器用于处理录制的原始音频和视频文件，以免占用主服务器的处理器。 连接时，Janus 服务器是按奇偶数（连接数）选择的。 当时，这已经足够了，根据我们的感觉，它提供了大约四倍的安全裕度，实施百分比约为80。同时，价格降至每节课约2卢布，再加上开发和支持。
回到视频通讯的话题
我们不断监控学生和教师的反馈，以便及时发现并纠正问题。 到2018年夏季，通话质量稳居投诉首位。 一方面，这意味着我们已经成功克服了其他缺点。 另一方面，有必要紧急采取一些措施：如果课程被中断，我们就有失去其价值的风险，有时还包括购买下一个课程的成本，如果入门课程被中断，我们就有失去潜在客户的风险共。
那时我们的视频交流还处于MVP模式。 简而言之，他们推出了它，它起作用了，他们扩展了一次，他们了解如何做到这一点 - 嗯，太棒了。 如果有效，请不要修复它。 没有人刻意解决通信质量问题。 到了 XNUMX 月份，很明显这种情况无法继续下去，我们启动了一个单独的方向来找出 WebRTC 和 Janus 的问题所在。
在输入时，该方向收到：MVP 解决方案，没有指标，没有目标，没有改进流程，而 7% 的教师抱怨沟通质量（也没有关于学生的数据）。
新的方向正在进行中
该命令看起来像这样：
- 部门负责人，也是主要开发人员。
- QA 帮助测试变更，寻找新的方法来创造不稳定的通信条件，并从一线报告问题。
- 分析师不断寻找技术数据中的各种相关性，改进对用户反馈的分析，并检查实验结果。
- 产品经理帮助确定实验的总体方向和资源分配。
- 第二个开发人员经常帮助完成编程和相关任务。
首先，我们建立了一个相对可靠的指标来跟踪通信质量评估的变化（几天、几周、几个月的平均值）。 当时是老师的成绩，后来加上了学生的成绩。 然后他们开始对哪里出了问题提出假设，纠正它，并观察动态变化。 我们追求的是容易实现的目标：例如，我们用 vp8 替换了 vp9 编解码器，性能得到了提高。 我们尝试使用 Janus 设置并进行其他实验 - 在大多数情况下它们没有产生任何结果。
在第二阶段，出现了一个假设：WebRTC是一种点对点解决方案，我们在中间使用服务器。 也许问题就出在这里？ 我们开始挖掘并发现了迄今为止最显着的改进。
当时，使用一种相当愚蠢的算法从池中选择了一台服务器：每个服务器都有自己的“权重”，具体取决于通道和功率，我们试图将用户发送到“权重”最大的服务器，而无需注意用户所在的地理位置。 因此，来自圣彼得堡的老师可以通过莫斯科与来自西伯利亚的学生进行通信，而不是通过我们位于圣彼得堡的 Janus 服务器。
该算法已重做：现在，当用户打开我们的平台时，我们会使用 Ajax 收集他对所有服务器的 ping。 建立连接时，我们选择数量最少的一对 ping（教师服务器和学生服务器）。 ping 越少意味着到服务器的网络距离越短； 距离越短，丢包概率越低； 丢包是视频通信中最大的负面因素。 三个月内消极情绪的比例下降了一半（公平地说，此时还进行了其他实验，但几乎可以肯定这个实验的影响最大）。
我们最近发现了另一件不明显但显然很重要的事情：与其在厚通道上使用一台强大的 Janus 服务器，不如使用两台带宽较薄的简单服务器。 当我们购买功能强大的机器并希望同时塞入尽可能多的房间（通信会话）时，这一点变得很明显。 服务器有带宽限制，我们可以准确地将其转换为房间数量 - 我们知道可以打开多少个，例如以 300 Mbit/s 的速度。 一旦服务器上打开的房间太多，我们就会停止选择它进行新活动，直到负载减少。 我们的想法是，购买一台功能强大的机器后，我们会将通道加载到最大，这样最终它将受到处理器和内存的限制，而不是带宽的限制。 但事实证明，在打开一定数量的房间（420）之后，尽管处理器、内存和磁盘上的负载仍远未达到极限，但负面情绪开始到达技术支撑。 显然，Janus 内部的情况正在变得更糟，也许那里也有一些限制。 我们开始试验，将带宽限制从 300 Mbit/s 降低到 200 Mbit/s，问题就消失了。 现在我们一次性购买了三台新服务器，其限制和特性较低，我们认为这将导致通信质量的稳定提高。 当然，我们并没有试图弄清楚那里发生了什么；我们的拐杖就是一切。 我们可以说，当时需要尽快解决紧迫的问题，而不是做得很漂亮； 另外，Janus 对我们来说是一个用 C 语言编写的黑盒子，修改它的成本非常高。
嗯，在这个过程中我们：
- 更新了服务器和客户端上所有可以更新的依赖项（这些也是实验，我们监控了结果）；
- 修复了与特定情况相关的所有已识别错误，例如，当连接断开且未自动恢复时；
- 我们与视频通信领域的公司举行了很多会议，了解我们的问题：流媒体游戏、组织网络研讨会； 我们尝试了一切对我们有用的东西；
- 对投诉最多的教师的硬件和沟通质量进行了技术审查。
这些实验和随后的改变使得教师之间对沟通的不满情绪从7,1年2018月的2,5%降低到2019年XNUMX月的XNUMX%。
接下来是什么
稳定我们的 Vimbox 平台是公司 2019 年的主要项目之一。 我们寄予厚望，希望能够保持这一势头，不再在投诉最多的地方看到视频通信。 我们知道这些投诉很大一部分与用户计算机和互联网的延迟有关，但我们必须确定这部分并解决其余部分。 其他的都是技术问题，看来我们应该能够应对。
主要困难是我们不知道质量实际上可以提高到什么水平。 找出这个上限是主要任务。 因此，计划了两个实验：
- 将 Janus 的视频与战斗条件下的常规 p2p 进行比较。 这个实验已经进行过，我们的解决方案和p2p之间没有发现统计上的显着差异；
- 让我们提供专门通过视频通信解决方案赚钱的公司提供的（昂贵的）服务，并将它们与现有服务的负面影响进行比较。
这两个实验将使我们能够确定一个可实现的目标并专注于它。
此外，还有许多可以例行解决的任务：
- 我们创建沟通质量的技术指标，而不是主观评价；
- 我们制作更详细的会话日志，以便更准确地分析发生的故障，了解它们发生的具体时间和地点，以及当时发生了哪些看似无关的事件；
- 我们在课前准备了自动连接质量测试，同时也为客户提供了手动测试连接的机会，以减少由于硬件和通道造成的负面影响；
- 我们将开发并进行更多恶劣条件下的视频通信负载测试，包括可变丢包等；
- 我们在出现问题时更改服务器的行为以提高容错能力；
- 如果用户的连接出现问题，我们会像 Skype 那样向用户发出警告，以便他明白问题出在他这边。
自XNUMX月份以来，视频通信方向已成为Skyeng内部的一个成熟的独立项目，处理自己的产品，而不仅仅是Vimbox的一部分。 这意味着我们开始寻找人 。 嗯，一如既往 .
当然，我们将继续积极与从事视频通信的人员和公司进行沟通。 如果您想与我们交流经验，我们将很高兴！ 发表评论，联系我们——我们会回答每个人。
来源： habr.com