WebRTC 优化如何让你损失金钱并损害你的业务？

WebRTC 需要在资源和需求之间取得平衡。这使得优化 WebRTC 应用程序成为一项颇具挑战性的任务。在优化过程中，过度热衷于优化性能反而可能导致相反的结果。

WebRTC 资深专家 Tsahi Levent-Levi 分享了一些他反复遇到的典型案例，以便你避免犯类似的错误。以下为全文内容。

作者：Tsahi Levent-Levi
译自：https://bloggeek.me/webrtc-optimizations-killing-business/

在所有可能的地区部署TURN服务器

当你在各地部署TURN服务器时，仅仅因为某个时候有人会用到它们，就让服务器在阳光下晒着烂掉，简直是浪费钱。我还敢说，如果它们没有被使用，那么它们可能真的无法正常工作，而你根本无法真正了解情况（除了部署监控，这本身就会增加成本和复杂性）。

这并不是说不要在很多地区部署TURN服务器。只是说你应该决定在哪些地区部署你的TURN服务器。

该把它们放在哪里？如果不确定，我这里有一个建议：

• 收集用户来自的地区
• 将这些数据放在直方图上，显示来自每个地区的用户/连接数量
• 确保90%的用户所在地区都有TURN服务器

对这个方案不满意？这里还有一个方向截然不同的建议：

• 测量用户的RTT
• 过滤掉通过 TURN 服务器连接的用户（其余用户对本次优化无关）
• 根据 RTT 对用户进行排序，RTT 越高，你就越应该关注优化他们的价值
• 是否注意到某些特定用户区域的 RTT 值明显较高？这就是你需要在该区域添加 TURN 服务器的地方（如果尚未部署），或者评估该区域使用的数据中心是否足够优质（很可能不够）

在 iceServers 配置中添加过多的 TURN 服务器

直截了当地说，这其实是你们那边的一个软件 bug。

我为什么这么确定？因为如果在 Firefox 的 WebRTC 对等连接传递超过 3 或 4 个服务器，它就会向控制台抱怨 iceServers 太多了……

为什么会这样？

你添加到列表中的每个 TURN 或 STUN 服务器都意味着你的 WebRTC 客户端需要收集更多的 ICE candidates 。在收集这些候选项后，由于候选服务器数量增加，客户端需要进行更多次 ICE 连接检查。

最终结果？网络上传输的消息越多，耗费的资源也就越多，而这实际上毫无用处。

不过，这还不是最糟糕的……

假设你在 10 个地区部署了 TURN 服务器。这意味着需要为每个地区添加 30 个 iceServer，包括 UDP、TCP 和 TLS 协议。

如果用户处于“中间”区域，会发生什么情况？他可能会在各个区域之间来回切换，每隔几秒或几分钟就更换他所连接的 TURN 服务器。是的，我在现实生活中见过这种情况。

你不希望让 WebRTC 通过其内部逻辑来决定使用哪个区域，你应该通过 DNS 地理定位来实现这一点。

在每个地区部署 WebRTC 信令服务器

别这么做。

实现起来很复杂（你需要一个分布式数据库，或者至少一个分布式内存数据网格来存储所有活跃用户的状态）。

而收益呢？太小了。

用户最终可能会以 100 毫秒或更快的速度发送信号，但这不会影响实际媒体质量。

所以别这么做。

你的部署规模可能不够大，不值得为此付出代价。

无论如何都以高清分辨率发送视频

高清视频效果很棒。它能提供高画质的视频。同时，还可以以 60fps 的帧率录制 4K 视频，甚至更高。

越大越好，对吧？

别急。

理论上，传输更高分辨率和帧率的视频确实能提升媒体质量。

但这会消耗CPU和网络资源。你在这两方面并不充裕，因此每次决定提高分辨率时，都需要确保这样做是值得的。

我在协助客户处理此类问题时会自问：

• 发送的摄像头分辨率和帧率是多少？
• （从该该摄像头）发送的视频分辨率和帧率是多少？
• 在接收端，视频将要显示的窗口分辨率是多少？
• 该视频内容对特定交互的重要性如何？

我的观点是：

• 做最少的事情以获得足够好的结果
• 你对 CPU 和网络资源的保护和关注越多，系统就越稳定。在此基础上，你可以尝试提高质量，并为此牺牲更多的 CPU 和网络资源。

使用 Simulcast（或SVC）进行所有通话

Simulcast(多播) 和SVC都是很棒的技术。不过，它们有其适用场景和用途，并不适合在所有情况下使用。

为什么？

• Simulcast 和 SVC 通常比“常规”视频压缩技术占用更高的带宽，尤其是Simulcast。
• 它们还占用更多的CPU资源
• 还有 SVC可能不被编码器的硬件实现所支持，这意味着你可能最终需要使用软件编解码器

我对硬件方面不太在意，我更关注占用更多 CPU 和比特率的问题。如果最终它们占用更多资源，我希望看到一些价值。但在 1v1 通话中，通常价值较低（使用 Simulcast 时没有价值，有些使用 SVC 时则因为其提高了丢包恢复能力——但同样，对于大多数服务来说，我并不会追求这一点）。

所以不要一直使用这些技术。

总之，不要在 1v1 通话中使用它们，而这很可能是 WebRTC 应用程序中的大多数通话类型。

力求在任何可能的情况下使用视频硬件加速

硬件加速非常适合视频编码。视频压缩会消耗CPU资源，而在移动设备上，这也会影响电池续航和设备发热。当使用硬件加速进行视频编码时，这些问题会得到缓解，因为这些负担不再由 CPU 承担，而是由专用的DSP芯片来完成。

但问题是，你不应始终追求在 WebRTC 中使用视频硬件加速。

为什么？因为存在以下“ 小”的不便：

• 并非所有设备都支持你可能需要的所有视频编解码器的硬件加速
• 部分支持硬件加速的设备可能未正确或充分实现该功能。以下是与 Chrome 相关的 WebRTC 错误示例：
  • 在极低码率下编码视频时发生崩溃
  • 低分辨率下视频质量差
  • 无法编码或解码来自其他设备的特定流
  • 某些编码器不支持 SVC
  • 无法同时运行多个编码器或解码器
  • 交互式视频用例优化不足

那么你该怎么办？

• 确定视频编解码器的硬件加速是否适合
• 假设这将需要更多的 QA 资源和实验室中更多的设备
• 将硬件加速设备列入白名单（而不是在用户遇到设备时将其列入黑名单）
• 在这件事上，宁可谨慎

选择 AV1 视频编解码器用于所有通话

AV1是 WebRTC 提供的最佳视频编解码器。它采用了最新的编码技术和最高的压缩率。在给定的比特率下，它很可能比其他所有替代方案提供更高的视频质量。

那为什么不一直使用它呢？因为使用 AV1 通常会占用比其他替代方案更多的 CPU 资源，因此较旧的设备可能无法在你需要的分辨率和比特率下支持它。

如果为了使用 AV1 而过度占用 CPU 资源，结果将是媒体质量下降，设备将因资源不足而开始限速，导致丢包、丢帧、发热以及音视频卡顿。

决定使用 AV1？

• 准备在你的应用中动态使用多种视频编解码器
• 弄清楚何时使用以及何时不使用 AV1

WebRTC 优化的正确方法

优化 WebRTC应用程序不仅仅是遵循一套简单的规则。最终，这取决于你的具体用例和实现方式。

这需要在你希望实现的媒体质量水平（最高）与你可用的硬件和网络资源（从一个会话到另一个会话以及在一个会话内动态变化的未知资源）之间进行权衡。

如果你需要在这方面获得帮助，请知悉这是我在许多咨询项目中主要从事的工作。只需与我联系，我们可以共同探讨是否能为你提供支持。