WebRTC 用例和性能

实现低延迟、点对点传输是一项艰巨的工程挑战：有 NAT 遍历和连接检查、信令、安全、拥塞控制和无数其他细节需要处理。WebRTC 代表我们处理以上所有内容，这就是为什么它可以说是自网络平台成立以来最重要的补充之一。事实上，这不仅仅是 WebRTC 提供的单个部分，而是所有组件协同工作以提供用于在浏览器中构建点对点应用程序的简单统一的 API。

然而，即使有所有内置服务，设计高效和高性能的点对点应用程序仍然需要大量仔细的思考和规划：点对点本身并不意味着高性能。如果有的话，对等点之间带宽和延迟的增加的可变性，媒体传输的高要求，以及不可靠交付的特性，使其成为一项更加艰巨的工程挑战。

音频、视频和数据流

点对点音频和视频流是 WebRTC 的核心用例之一：getUserMediaAPI 使应用程序能够获取媒体流，内置的音频和视频引擎处理流之间的优化、错误恢复和同步。然而，重要的是要记住，即使采用积极的优化和压缩，音频和视频传输仍然可能受到延迟和带宽的限制：

高清质量的流需要 1-2 Mbps 的带宽；请参阅音频 (OPUS) 和视频 (VP8) 比特率。

好消息是全球的平均带宽容量正在持续增长：用户正在转向宽带，5G 的采用率正在上升。然而，即使有乐观的增长预测，虽然高清流媒体现在变得可行，但这并不能保证！同样，延迟是一个长期存在的问题，尤其是对于实时交付，对于移动客户端而言更是如此。5G 肯定会有所帮助，但 4G 网络也不会很快消失。

更复杂的是，大多数 ISP 和移动运营商提供的连接不是对称的：大多数用户的下行链路吞吐量明显高于上行链路吞吐量。事实上，10 对 1 的关系并不少见——例如，下行 10 Mbps，上行 1 Mbps。

最终结果是，当您看到单个点对点音频和视频流占用大量用户带宽时，您应该不会感到惊讶，尤其是对于移动客户端。考虑提供多方流？您可能需要对可用带宽量进行一些仔细规划：

移动客户端可能能够下载高清质量的流（1 Mbps+），但由于上行链路吞吐量较低，可能需要发送质量较低的流；不同的参与方可以以不同的比特率进行流式传输。
音频和视频流可能需要与其他应用程序和数据传输共享带宽——例如，一个或多个 DataChannel 会话。
无论连接类型是有线还是无线，或者网络的生成方式如何，带宽和延迟总是在变化，应用程序必须能够适应这些条件。

好消息是，WebRTC 音频和视频引擎与底层网络传输一起工作，以探测可用带宽并优化媒体流的交付。但是，DataChannel 传输需要额外的应用程序逻辑：应用程序必须监控缓冲数据量并准备好根据需要进行调整。

多方架构

具有双向高清媒体流的单个点对点连接很容易占用用户带宽的很大一部分。因此，多方应用程序应该仔细考虑如何在对等方之间聚合和分发各个流的架构。、

一对一连接易于管理和部署：对等方直接相互交谈，无需进一步优化。但是，将相同的策略扩展到 N 路调用，其中每个对等方负责连接到所有其他方（网状网络），这将导致N-1每个对等方的N X (N-1)连接，以及连接总数！如果带宽非常宝贵，通常是由于上行链路速度低得多，那么这种类型的架构将很快使大多数用户的链接饱和，而只有少数参与者。

虽然网状网络易于设置，但对于多方系统而言，它们通常效率低下。为了解决这个问题，另一种策略是使用“星形”拓扑，其中各个对等点连接到“超级节点”，然后负责将流分发给所有连接方。这样，只有一个对等点必须支付处理和分发N-1流的成本，其他所有人都直接与超级节点对话。

一个超级节点可以是另一个对等节点，也可以是专门为处理和分发实时数据而优化的专用服务；哪种策略更合适取决于上下文和应用。在最简单的情况下，发起者可以充当超级节点——很简单，它可能会正常工作。更好的策略可能是选择具有最佳可用吞吐量的对等方，但这也需要额外的“选举”和信令机制。

巴特西

WebRTC 用例和性能