如何使用 WebRTC 创建可与上千人连接和互动的直播

您正在为一个直播活动或会议建立一个平台，将有成千上万的参与者参加。这些参与者希望与您的内容进行实时连接，还希望与内容和/或其他参与者进行互动。如果您正在构建这样一个平台，您就会知道这很难。

这篇文章是一次雄心勃勃的尝试，它记录了实现可扩展实时流媒体的各种方法。

为什么选择 WebRTC

WebRTC 正在迅速崛起，成为事实上的实时流媒体框架。它结束了专有编解码器的孤岛战争，可在大多数浏览器中无缝运行，并将安全性作为首要支柱。我们假设您知道 WebRTC 是什么，并希望使用它。

WebRTC 已经为大多数著名的视频会议应用程序（SecureMeeting、BlueJeans、WebEx 等）提供了支持。大多数视频会议应用程序并不关心规模，只要能让一群人（约 30 人）进行通话，并尽可能让他们出现在屏幕上就足够了。

谁想要可扩展的互动直播？

拥有成千上万用户的直播活动非常注重规模。即使在这个范围内，也很少有人能掌握规模和互动性。

例如，互联网上的体育直播通常会有 30 多秒钟的延迟。大多数观众要么不知道，要么不在乎这种延迟。但是，如果广播公司想让这些球迷在观看时参与进来，互动性就变得非常重要。在这一点上，要在有 1000 多人参与的情况下将延迟时间控制在亚秒级范围内是不可行的。

如果您属于以下任何一种情况，那么这篇文章就是为您准备的：

• 您正在构建一个需要规模和速度的实时流媒体应用程序
• 安全对您很重要
• 您是初创企业/小企业，没有大规模的基础设施–您将使用公共互联网来传输视频流
• 或者，您是主要的视频流媒体提供商，运行自己的围墙花园网络
• 或者，您是已经与 CDN 公司合作的主要视频提供商，但您觉得您的速度被限制了

当然，您也可以研究下即构的实时音视频SDK：支持万人实时互动功能，无房间人数限制，最多支持万人上麦音视频通话/直播功能。

问题：根据定义，”可扩展 “的 WebRTC 是不可能的

开箱即用的 WebRTC 是一种严格意义上的点对点（P2P）流框架。P2P 的扩展性很差–对于一个呼叫中的 N 个参与者，视频流的数量为 O(N²)。问题就在这里：如果 N 是一个很大的数字，系统就会崩溃。

有效的方法：假设 “B “是一个广播公司。如果 B 想让五个消费者（如 C1、C2……、C5）加入，他们只需直接与 B 开启视频会话即可。

行不通的地方： 如果 “B “想让 10,000 个消费者加入并进行互动（如 C1、C2……、C10000），他们就不能都直接与 B 开会话。如果还需要互动，B 的下行链路速度也必须达到 500 Mbps，这对每个消费者都是一样的。你一定是疯了。

安全性： 只要在 P2P 模式下使用，WebRTC 就能实现端到端 (E2E) 加密。在这种情况下，B 与 C1、C2、……、Cn 中的每一个协商加密密钥。同样，这在规模面前也是失败的。

解决方案 1：使用网关

网关 “是一个节点/进程，它充当 “B “源流的守门人。简单地说，网关将重新广播原始流，这样原始发送者就不必重新广播。

我们推荐 Janus。它是免费的、开源的，而且我们已经亲自对它进行了多次测试。

工作原理 您的广播公司 “B “向 Janus 网关发送视频流，Janus 网关 “会说 “WebRTC。想要订阅您视频流的客户端连接到 Janus。瞧，一切正常。

Janus 很轻。对于这样的服务，人们最关心的是它有多笨重。Janus 是轻量级的，以至于它可以在 raspberry-pi 上运行（我们试过）。

这可以扩展吗？简短的回答是肯定的。更准确的答案是，这取决于您运行的应用程序的类型。有大量证据表明，在部署过程中，参与者的规模达到了约 120 人。如何扩展到数千人？您必须运行多个 Janus 实例，每个实例（”工作者”）独立处理约 100 个数据流。以下是 Janus 官方文档的摘录：

每个 Janus 实例都是独立的，可以单独运行。尽管如此，您可以通过不同的方式在服务中实现可扩展性。其中一种方法是实施一个包装器/控制器应用程序，负责多个 Janus 实例，以便根据请求分配负载。如果情况允许，您还可以在不同的 Janus 实例上混合不同插件的概念（例如，使用 VideoRoom 插件的 RTP 转发功能，使同一 VideoRoom 发布者在其他 Janus 机器上作为流媒体挂载点使用）。

安全考虑。WebRTC 的 E2E 安全性只有在对等方直接对话时才能发挥作用。引入网关后，这种对等连接的感觉就被打破了。在短暂的时间内，从 B 传出的数据流将在网关处终止，并为每个消费者重新创建。在这短暂的时间里，内容并没有加密。解决这一问题的办法是严格控制对网关的访问（将网关设在自己的场所内，并限制对网关的访问）。

使用可插入流的 E2E。在撰写本文时，Google 提供了一个版本的 Insertible Streams，可通过端到端加密确保 WebRTC 通话的安全。

还有其他替代方案吗？当然有。该领域的其他公司包括 Jitsi、Licode、Kurento 和 Hubl.in，仅举几例。我们推荐 Janus 而不是这些替代品。这是一个快速发展的领域–我们期待这些技术不断发展。

去中心化技术：LivePeer

未来是去中心化的，是时候让我们清醒地认识到这一新现实了。

什么是去中心化？集中式架构涉及一个管理基础设施的 “中央 “参与者–想想亚马逊AWS这样的大型基础设施公司，或者Akamai这样的CDN公司。去中心化基础设施在没有任何中央服务器的情况下运行。它们利用数以千计的志愿者的计算资源，其中大部分人以加密货币作为报酬。

中心化架构容易受到黑客攻击和审查，更不用说中心故障点了。去中心化架构可以抵御审查。它们基本上是不可阻挡的。

在本节中，我们将详细介绍 LivePeer，一种用于可扩展直播流的开创性新型去中心化架构。

什么是 LivePeer？

LivePeer 是建立在以太坊区块链之上的去中心化、开放式视频基础设施。它是亚马逊 AWS 或其他集中式 CDN 的对立面。在撰写本文时，LivePeer 可同时容纳 1000 名观众，同时确保 8-15 秒的延迟。

这里有一个精彩的 10 分钟入门指南，帮助你掌握基本知识（由发明者自己提供）。

LivePeer 能解决什么问题？

LivePeer 主要解决转码和分发问题。转码是 “编码 “和 “解码 “相结合的术语–它是将原始视频文件转换为可分发格式的过程，反之亦然。这种可供分发的格式是 MP4 或 WebRTC (VP8/9)。

从大规模交付视频的端到端延迟来看，转码延迟很容易占到 e2e 延迟的 30% 或更多。AWS 等基础架构服务配备了完善的服务器来处理转码。

LivePeer 将转码过程委托给数百个节点，由它们共同对原始视频流进行转码，从而实现了转码的民主化。这些节点还帮助进行分发。这从根本上改变了视频传输过程，而无需依赖集中式基础设施。

为什么随机节点会参与？与大多数 Web 3.0 项目一样，LivePeer 通过用 LivePeer 代币（LPT）补偿节点来激励节点参与。目前，LPT 是一种建立在以太坊基础上的 ERC-20 代币。在合理的奖励/补偿经济模型的支持下，该项目已经吸引了众多志愿者。

eCDN：内部实时视频

您不是初创企业。您运行着自己的围墙花园网络和/或 eCDN，并希望扩大直播参与者的数量。您定期为公司的每个人举办全体会议和/或实践会议。您一直在考虑通过 eCDN 和/或内部网络配置进行 “组播 “或 “p2p”。让我们深入了解一下。

什么是 eCDN？企业 “CDN 的简称。这是一种企业已经拥有 CDN 基础设施的情况。

问题/挑战。如果您的公司有 1000 多名观众，仅仅使用企业 CDN 来流式传输视频是不够的。观众仍然会看到缓冲、延迟和视频质量波动。更不用说向成千上万的接收者发送相同的流媒体，这将扼杀关键的传输点。

解决方案：P2P eCDN。为了减少阻塞点的负载，并更好地利用网络中已经存在的冗余视频数据包，实现扩展的一种明显方法是利用对等共享。这种技术有点类似于多播，但更依赖于点对点共享。

结论

低延迟（500 毫秒以下）可扩展的实时流媒体仍然是互联网上的一项公开挑战。虽然在 “围墙花园 “内网中可以实现一定的延迟控制，但在公共互联网上却远远无法实现。

流量波动、BGP 路由阻尼和链路故障的普遍不可预测性使得互联网难以控制。同时，组播协议和视频转码，再加上高带宽要求，也使规模难以掌握。我们希望这篇文章能为当前的技术水平提供一个方便的参考。

推荐阅读：实现万人实时连麦互动技术难点