集成WebRTC一对一音频/视频通话会影响Web应用程序的性能

Question

在了解WebRTC的一些重要功能之后，我想到在我的Web应用程序中使用WebRTC一对一音频/视频通话。网络应用程序适用于许多组织/实体，他们可以每天为其内部工作和他们的客户注册并保持记录多个记录。这些个人组织/实体的客户也可以访问Web应用程序以访问他们的详细信息。

使用WebRTC的目的是为了客户和组织之间的沟通。也适用于这些组织对新产品和服务的日常查询。

在浏览谷歌等文章时，我发现广播或一对多的电话需要非常高的带宽给用户，如果我们不使用媒体服务器。

那么一对一电话的情况如何？ 它会影响Web应用程序的性能，或者如果多个用户同时作为例程同时进行音频/视频通话（一对一），会带来任何危急情况吗？

用户数量非常大，用户每天都会记录几项作为日常工作的条目。但它仍然是可管理的，应用程序将运行平稳，但我不确定WebRTC的新概念。它是否需要非常高的托管计划？是否使用WebRTC适合当前的情况？

Answer 1

WebRTC的本质是对等。这意味着流数据是由CLIENT处理的。所有解码，编码，ICE候选者收集/协商和媒体加密/传输都将发生在客户端而不是服务器端。所以，你会提供页面，客户端JS和一些数据交换（会话协商信令），但总的来说，这不是一个大量的工作。它应该很容易处理，而不必担心主机工作过度。

所有这一切说，这里是唯一一个性能问题，将可能影响您的托管服务器。

1. 信令会话启动，协商和去重。这是非常小的（在会话开始时只有一些json数据）。这不应该成为太多的负担，但您应该知道，如果1000个会话同时启动，您将有一个消息队列指向所需的各方。您如何确定参与方，转发消息，以及您在服务器端执行哪些工作都可能会影响性能。如果写得聪明（如何存储会话，如何转发消息等）不应该是一个可怕的负担。这可以很容易地完成SignalR，因为你在ASP.NET上，或者你可以使用一个单独的运行Node.js（或同一个盒子，没关系），如果你愿意的话。
2. RTP TURN继电器，如果需要的话。这可能会通过一个不同的服务器（或者如果你想要的话，与你的托管服务器相同）。对于某些连接，需要TURN服务器，任何生产就绪的WebRTC解决方案都应考虑到这一点。 Here is a good open source turn server。此处的带宽使用率可能会非常高，因为RTP数据包发送到此服务器并且转发给连接中的对等方。
3. 如果您正在录制流，您可能会增加托管流量，具体取决于您如何实施它。 Firefox支持client side recording，但Chrome不支持（他们表示目前正在开发中）。您可以使用existing JS libraries来记录提要客户端，然后将它们推送到任意位置。您还可以通过媒体服务器推送所有数据，这些媒体服务器将复用，解复用，并将数据转发到您喜欢的任何位置进行录制。 Janus-Gateway videoroom是mediaserver的一个很好的轻量级示例。

客户端是一个不同的故事。

1. 在Javascript中有更高级别的问题。如果您使用其中一个录制JS库，这一点尤其明显，因为它们每秒执行多次抓取画布，受到沉重打击并会降低用户体验。
2. 浏览器的CPU利用率将随着流式传输视频质量的提高而增加。这比较明显，因为HD视频帧比SD帧需要更多的CPU编码/解码能力。
3. 客户端带宽使用也可能是一个问题。 Chrome和Firefox试图动态修改每个视频/音频馈送的比特率，但视频比特率可以一直高达2 Mbps。您可以在Chrome中限制此项（通过在SDP中添加一个属性），但不能在Firefox中（最后检查）。