谁是最好的WebRTC SFU？

　　首先要注意一个重要的问题——问什么样的SFU是最好的就像问什么样的车是最好的。如果你只想快点，那么你应该买一辆一级方程式赛车，但这不会帮助你送孩子上学。供应商从不对这些类型的测试感到兴奋，因为它把它们的功能归结为几个性能指标。这些指标可能不是其设计标准的主要部分，而且很多时候他们并不是那么重要。特别是对于WebRTC SFU，因为您可以在SFU上加载很多流，所以可能存在有许多弹性，用户行为和成本优化的原因。负载测试也不会深入研究端到端用户体验、开发的易用性，或者所有其他能够成功实现服务的功能元素。最后，像这样发表的报告代表了一个时间点——这些系统一直在改进，所以今天的结果可能会更好。

　　在discussion-webrtc邮件列表上的一个反复出现的问题是“什么是最好的SFU”。这总是会产生来自各个SFU供应商和团队的响应。显然，它们不可能同时是正确的！

　　你可以在这里检查整个线程。Chad Hart随后带着对话友好地回答了这个问题，并表示需要：

　　在任何情况下，我认为我们需要全局（同样适用于所有）可重现且无偏见（可用的源代码，并且每个供应商可以根据需要调整其安装）基准，以获得多个可伸缩性指标。

　　三年后，我和我的团队建立了这样一个基准系统。我将解释这个系统是如何工作的，并在下面展示我们的一些初步结果。

　　一些SFU供应商提供负载测试工具。Janus有Jattack。Jitsi有jitsi-hammer，甚至发表了他们的一些研究成果。Jitsi尤其在透明度方面做了大量工作，提供了可靠的数据和足够的信息来重现结果。然而，并不是所有的供应商都有这些工此外，每个工具都旨在为自己的环境回答略有不同的问题，例如：

　　没有办法进行真正的比较研究——一个独立可重复且无偏见的研究。这种固有的模糊性也为一些人的一些令人不快的行为打开了大门，他们意识到自己可以逃避任何索赔，因为没有人能真正检查他们。我们想要产生一些结果，人们不需要承担责任，可以通过同行评议。

　　要想对“什么是最好的SFU？”有一个很好的答案，你需要解释你打算用它做什么。

　　我们选择研究似乎最受关注的两个用例，或者至少是那些在discuss-webrtc上产生最多流量的用例：

　　大多数视频会议问题都集中在单个服务器实例上。在给定的会议中有20多人通常是很多人。相关研究表明，在大多数社交案例中，大多数呼叫都是1-1，平均值大约为3.这种配置非常适合任何公共云提供商中的一个小型实例（只要你获得1Gbps NIC ）。然后，您可以使用非常简单的负载平衡和水平可伸缩性技术，因为发送者与观看者的比例很少。另一方面，媒体流通常涉及从单个源流向成千上万的观众。这需要多服务器层次结构。

　　我们希望适应不同的测试场景，并在几个WebRTC服务器上以相同的方式实现它们，这样唯一的区别就是所测试的系统，并且结果不会有偏差。

　　在与谷歌和其他许多公司的合作下，我们开发了KITE，这是一个测试引擎，它可以让我们轻松地支持各种客户端——浏览器和跨移动或桌面的本机客户端——以及各种测试场景。它被用来测试WebRTC的实现，每天都在不同的浏览器上运行。

　　负载测试通常使用单个客户机来控制客户机的影响。理想情况下，您可以在单个虚拟机中并行运行测试客户机的多个实例。由于这是WebRTC，所以使用其中一个浏览器是有意义的。Edge和Safari只局限于一个进程，这并不使它们非常适合。此外，Safari只运行MacOS或iOS，而iOS只在苹果硬件上运行。如果运行的是Windows或Linux，那么在AWS上生成100万个虚机相对比较容易。要安装100万台Mac、iPhone或iPad进行测试，难度和成本都要大得多。

　　这样你就有了Chrome或Firefox，可以同时运行多个实例。我们认为Chrome的webdriver实现更容易管理，需要处理的标志和插件更少（比如H264），所以我们选择使用Chrome。

　　我们测试了以下SFU：

　　为了确保每个SFU都显示出最佳结果，我们联系了每个项目背后的团队。我们提议让他们自己设置服务器或连接到服务器并检查他们的设置。我们也分享了结果，以便他们发表评论。这确保我们正确配置每个系统以便为我们的测试提供最佳处理。有趣的是，在这项研究的过程中，我们发现了一些bug，并与团队一起改进了他们的解决方案。这将在最后一节中详细讨论。

　　我们使用以下方法将流量增加到高负载。首先，我们在每个视频会议室中每次只使用一个用户，直到用户总数达到7个。我们重复这个过程，直到达到目标用户总数。接近500个同步用户。

　　下图显示了测试平台中的元素：

　　大多数对可伸缩性问题感兴趣的人都会在“负载”（流、用户、房间…）增加时测量服务器的CPU、RAM和带宽占用。这是一种传统的方法，它假设流的质量、比特率都保持不变。

　　WebRTC的编码引擎使得这个问题更加复杂。WebRTC包括带宽估计、比特率适应和总体拥塞控制机制，不能假定在整个实验过程中流将保持不变。除了通常的指标之外，测试人员还需要记录客户端指标，比如发送的比特率、带宽估计结果和延迟。关注视频质量也很重要，因为它可能会在CPU、RAM和/或服务器带宽饱和之前下降。

　　在服务器端测量不同的度量标准就像自己汇集getStats API或集成callstats.io之类的解决方案一样简单。在我们的例子中，我们衡量：

　　由于篇幅限制，上述指标未在科学文章中发布，但应在随后的研究报告中发布。除视频质量外，所有这些指标都很容易制作和测量。什么是视频质量的客观衡量标准？存在几种视频质量代理，例如Google渲染时间，接收帧数，带宽使用情况，但这些代理都没有给出准确的测量结果。

　　理想情况下，当存在缺陷时，视频质量指标在视觉上是显而易见的。这将使我们能够衡量弹性技术的相对好处，例如弹性视频编码（SVC），从概念上讲，输出视频与抖动、丢包等编码方法的相关性较弱。有关视觉比较的一个很好的例子，请参阅Agora的以下视频：

　　https://www.youtube.com/watch?v=M71uov3OMfk

　　在快速研究了一种自动化这种视觉质量测量的方法后，我们意识到没有人开发出一种评估视频质量的方法，在没有实时流的参考媒体的情况下。因此，我们继续开发我们自己的度量，利用神经网络来利用机器学习。这使得实时的视频质量评估成为可能。另一个好处是，它可以在不记录客户媒体的情况下使用，这有时是一个法律或隐私问题。

　　此机制的细节超出了本文的范围，但您可以在此处阅读有关视频质量算法的更多信息。这种基于AI的算法的细节已经提交出版，一旦被接受就会公开。

　　我们使用从他们各自的公共GitHub存储库下载的最新源代码（使用Docker容器的Kurento / OpenVidu除外）设置了以下五个开源WebRTC SFU：

　　每个都是在一个单独但相同的虚拟机中设置并使用默认配置。

　　首先是一些免责声明。所有团队都看到并评论了他们的SFU的结果。Kurento媒体服务器团队意识到他们的服务器目前正在崩溃的早期，我们和他们一起工作来解决这个问题。在Kurento / OpenVidu上，我们测试了最多140个流（因为它很早就崩溃了）。

　　此外，libnice中存在一个已知的bug，它在我们的初始测试期间影响了Kurento / OpenVidu和Janus。按照Janus团队的建议应用libnice补丁后，他们的结果显着改善。但是，使用Kurento / OpenVidu上的补丁进行重新测试实际上更加糟糕。我们的结论是Kurento还有其他问题。我们正在与他们联系并致力于解决方案，因此，Kurento / OpenVidu的结果可能会很快得到改善。

　　最新版本的Jitsi Videobridge（到本文发表时为止）在240个用户时总是变得不稳定。Jitsi团队已经意识到了这一点并正在解决这个问题。但是，他们指出，他们的一般建议是依赖于使用此处描述的大量较小实例的水平扩展。请注意，以前的版本（如两个月前的版本）没有这些稳定性问题，但表现不佳（请参阅下一节中的更多内容）。我们选择保留0.1.1077版本，因为它包含使simulcast更好，并显着改善了结果。

　　另请注意，自测试以来，几乎所有这些产品都有版本发布。自从此处显示的测试结果以来，一些已经做了改进

　　作为参考点，我们选择了一种常用的视频测试序列，并使用多种视频质量评估指标计算其视频质量得分：

　　图1：基于不同比特率对各种视频质量度量进行基准测试

　　注意，质量分数和比特率之间的关系不是线性的。如果您从参考值（1.7Mbps）开始缓慢地减少带宽，那么质量分数只会略微下降，直到它达到一个低比特率阈值，然后急剧下降。要降低10%的感知视频质量，需要根据WMAF将带宽减少到250Kbps，根据SSIM将带宽减少到150k，根据NARVAL将带宽减少到100k。

　　对SFU的测试也显示出同样的模式。图2给出了比特率作为每个SFU参与者数量的函数。可以看到，WebRTC的拥塞控制算法在早期（大约250名参与者）就开始运行，以保持比特率。然而，图3显示了延迟的线性增长。尽管带宽减少，延迟增加，但是在图4中显示的视频质量度量只在带宽低于200k时报告质量下降。这再次表明，比特率和延迟并不是视频质量的好代理。

　　图2：JItsi在240名参与者失败。Kurento / OpenVidu很早就遇到了问题。Janus和mediasoup似乎比Medooze更好。它似乎与更好的CPU优化有关，因为拐点与各个CPU的饱和度相关。

　　图3：JItsi在240名参与者失败，Kurento / OpenVidu在50左右出现问题。否则SFU表现出类似的行为。

　　图4：视频质量仅在实验结束时下降，表明拥塞控制机制正在完成其工作，并设法做出正确的妥协，以便在调整其他参数的同时保持感知质量高。

　　除了上述结果本身之外，有趣的是，我们可以看到这项研究所引发的结果的进展。仅仅是提高知名度，就允许各自的团队解决最严重的问题。

　　你也可以观察到Janus很快就被限制了。他们已经在一个外部库中确定了这个瓶颈，以及一个可能的解决方案，但从未真正评估过真正的影响。我们可以清楚地看到这一节中的图（第一次运行）和前一节中的图（最新结果）之间的区别，Janus似乎表现最好。

　　比特率作为负载的函数。

　　之前（左）和之后（右）将补丁应用于Janus和Jitsi。我们还添加了mediasoup结果（绿色）。Medooze和Kurento / OpenVidu结果在两个图中都是相同的，因为第二次没有更好的结果。

　　RTT或延迟，作为负载的函数（对数标度）。之前（左）和之后（右）将补丁应用于Janus和Jitsi。我们还添加了mediasoup结果（绿色）。Medooze和Kurento / OpenVidu结果来自同一数据集。

　　最后，我们最初文章的一位审稿人指出，CoSMo的雇员塞尔吉奥？加西亚？穆里洛（Sergio Garcia Murillo）的Medooze最终成为了我们研究的重点，暗示了利益冲突可能导致的偏见。我们花了很大的努力来进行我们所有的测试，没有偏见的透明。我认为在最新的结果中看到一些SFUs与Medooze持平或更好，消除了一些人可能有的最后的担忧，这是令人振奋的。这对Medooze团队来说也是个好消息——现在他们知道他们要做什么（比如Medooze 0.46的改进），他们有了一个工具来衡量他们的进展。

　　结论

　　我们希望我们已经证明，由于KITE和CoSMo最近与WebRTC生态系统的作者合作开发的一些其他工具，现在相对容易实现对SFU的无偏见的比较测试。我们将继续与不同的开源WebRTC SFU供应商合作，帮助他们改进他们的软件。我们计划尽可能多地使用用于生成这些结果的代码公开，并且无论如何，以非营利的方式为公共研究人员提供对该工具的访问。最终，我们希望将这些结果作为“实时”网页托管，在新版本的软件可用时，可以获得新的结果。

　　请参阅本周在IIT实时通信会议上展示的论文全文

　　（https://www.cosmosoftware.io/publications/andre2018_Comparative_Study_of_SFUs.pdf）和幻灯片。

　　（https://www.cosmosoftware.io/publications/andre2018_slides_Comparative_Study_of_SFUs.pdf）摘要。

　　阅读原文