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应用程序不仅仅是遵循一套简单的规则。最终，这取决于你的具体用例和实现方式。
这需要在你希望实现的媒体质量水平（最高）与你可用的硬件和网络资源（从一个会话到另一个会话以及在一个会话内动态变化的未知资源）之间进行权衡。
如果你需要在这方面获得帮助，请知悉这是我在许多咨询项目中主要从事的工作。只需与我联系，我们可以共同探讨是否能为你提供支持。
