关于webrtc:构建基于浏览器的Web-P2P网络直播

摘要

在 2021 年的互联网时代，越来越多的网络直播节目相继涌现。浏览器是用户最易接触的渠道之一，汇集了大量观看直播的用户。当用户们同时观看直播内容时，服务器接受的负载随着用户量的减少而增大，会导致播放的卡顿，提早等用户体验的降落；而且昂扬的服务器带宽老本也不容忽视。

那么是否存在一套解决方案，在保障用户体验与服务质量的前提下，又能够无效的升高服务器的负载与带宽呢？那就是接下来要介绍的 Web P2P 技术了。

一、Web P2P 的前世今生

2010 年，Adobe 在 Flash Player 10.0 推出了实时流媒体 RTMFP，应用 RTMFP 在 Flash Player 之间进行 P2P 成为可能。在随后的几年内，该协定在网络上如雨后春笋般的被宽泛部署，然而从 2020 年末开始，各家的浏览器都曾经彻底不反对 Flash 了。咱们又应该如何在 Web 外面应用 P2P 呢？

诞生于 2011 年的 WebRTC 技术，在 Google、Microsoft、Apple、Mozilla 等大厂的反对下，成为了 H5 的规范，并且 Chrome、Edge、Safari、Firefox 等支流浏览器也都反对 WebRTC。所以就能够通过 WebRTC 来实现 P2P 了。

下文把基于 WebRTC 实现的 HTML5 P2P 简称为 H5 P2P。

二、WebRTC 简介

WebRTC 的总体架构如下图所示，如果是浏览器开发者，通常须要关注并实现 WebRTC C++ API，而咱们的指标是基于浏览器实现 P2P，所以只须要关注 Web API 即可。

整体的 H5 P2P 都是基于 RTCPeerConnection 和 RTCDataChannel 来实现的，只是实现数据层面的 P2P，不蕴含音视频通信的内容。

三、总体架构

H5 P2P 客户端

次要蕴含通信模块、传输模块、节点治理、调度模块、存储模块和统计模块：

通信模块：次要负责和服务端（上图中的 Index、CPS、Tracker）进行信令的通信

传输模块：蕴含 HTTPClient 和基于 RTCDataChannel 实现的 RTCClient（上传 & 下载）

节点治理：不同用户间 P2P 主被动连贯、断开、淘汰、资源信息同步

调度模块：依据 buffer 水位、分片信息、节点品质和规模进行 CDN/P2P 调度

存储模块：负责媒体数据的存储、排序、以及淘汰

统计模块：蕴含零碎运行的埋点的实现

H5 P2P 服务端

次要蕴含 Index、CPS、Tracker 和 Stun 服务：

Index：索引服务，提供其余服务地址。

CPS：资源属性服务，将直播流的 URL 转换为 RID。

Tracker：资源追踪服务，次要存储用户和资源之间的索引关系。

MQTT：信令服务，转发用户间建设 P2P 连贯的 offer/answer/candidate SDP 协定。

Stun：采纳 coturn 部署，次要用户节点之间建设对等连贯的 UDP 穿透。

四、阶段流程

下图简略的展现了整体计划的各个阶段、流程：

Step 1：网页关上，首先向 Index 服务申请其余服务的地址，保留于内存中

Step 2：客户端收到直播申请，向 CPS 发送申请将 URL 转换为资源 ID(RID)，雷同内容雷同清晰度的直播流的资源 ID(RID)是雷同的，表明能够相互分享数据

Step 3：客户端首先会启动 HTTPClient 进行数据下载，优先保障秒播。同时做以下 2 件事

a. 客户端向 Tracker 服务发送 Address 协定，获取其余正在观看该直播的用户地址，待后续建设连贯，分享数据

b. 客户端向 Tracker 服务发送 Publish 协定，将本人的信息告知 Tracker，使得他人能够即便搜寻到本人，进行数据分享

Step 4：向从 Tracker 获取的其余用户建设连贯，彼此替换信息，数据分享

五、连贯建设

假如在 Peer1 和 Peer2 之间传输数据，那么在传输之前，首先须要建设连贯。在 WebRTC 中，浏览器间通过 ICE 框架建设对等连贯，次要蕴含 Stun、TURN，上面别离简略介绍一下：

ICE（Interactive Connectivity Establishment）提供的是一种 P2P 连贯框架，对立各种 NAT 穿透技术（STUN，TURN）。基于 offer/answer/candidate 模式，通过屡次地址替换，而后进行连通性测试，穿透用户网络间各类防火墙。ICE 次要蕴含 STUN、TURN 等协定。

STUN

STUN（Simple Traversal of UDP Through NAT）容许位于 NAT 设施后的客户端找到本人的公网 IP/Port 地址，以及查问出本人的 NAT 设施类型，通过这些信息使得两个同时位于 NAT 后的 2 个设施之间建设 UDP 通信，具体的 STUN 流程能够参考 RFC5389，不在此赘述。

TURN

艰深的说，TURN（Traversal Using Relays around NAT）就是中继 / 转发，并不是所有的设施之间都能够依附 STUN 来建设连贯的，那么当两个设施之间无奈依附 STUN 建设连贯时，就会启用 TURN 来进行数据直达。

因为咱们的指标是节约带宽，如果采纳 TURN 转发的话，并不能缩小服务器的带宽耗费，另外一个起因是，在整个建设连贯的过程中，有别于传统的视频通话只能 1 对 1，这里的传输模式是 1 对多传输，所以并不要求每个连贯都牢靠，因而在 H5 P2P 我的项目咱们仅仅通过 STUN 来实现连贯的建设。

六、数据下载

资源编码

Web P2P 网络直播计划也能够同时反对任意多路直播同时进行，必须保障各路直播流之间的独立性，因而，咱们提供一种对立的资源编码方式，用来标识惟一的一路直播流。这里次要借用直播流中的 StreamId，通过计算 MD5，生成固定长度的资源 ID（RID），不仅保障了内容雷同，清晰度不同，RID 也不同；也保障了雷同的内容，因为断流切换源地址，导致 URL 变动，保障资源 ID(RID)雷同。

下载调度

在整个直播过程中，因为可播放缓存的数据是十分小的，通常不超过 10 秒？因而如何实时的依据以后的网络状态、网络环境，作出应用 CDN，又或是应用 P2P 的决策呢？这里，咱们的最佳实际次要如下：

a. 为了保障用户的观看体验，当缓冲区的可播数据低于某个阈值（例如 5 秒），就切换 CDN 下载

b. 当发现某一片将来的数据，四周的人都没有的时候，即便可供播放的 buffer 还有很多，不满足 a 策略的形容，这个时候，为了尽快的散发数据，也应该及时切换至 CDN，呈现这种状况时，往往示意这个节点以及他连贯的节点都处于整个直播数据散发的顶层，为了防止出现“一人下载多人围观”的场景，本着更快的下载导致更早的上传理念，不仅仅要求该节点本身尽快 CDN 下载，同时也保障四周用户某个比例（例如 15%）也尽快采纳 CDN 下载，从而使得整体数据的散发效率晋升。

P2P 任务分配

a. 工作编号

对于每一个数据块都有一个自然数编号（sn），对于这个数据块，咱们依照固定长度（默认 16KB）的大小进行切分，简称 chunk_index，那么（Rid, sn, chunk_index）就能够惟一确定一个数据片了。

b. 调配申请

调配过程相似于扑克中的发牌机制，惟一的要求是对方这个节点领有这个数据块，并且品质越好的节点，越多越调配凑近播放点的、重要的数据。下图简明扼要的展现了 3 个雷同品质节点调配 2 个数据块（9 个数据片）的过程。

内存管制

对于 Web P2P 来说，所有的媒体数据都缓存在内存中，然而，也并不是会缓存残缺的数据。对于直播来说，所有用户的观看点都是十分靠近的，因而，内存始终缓存播放点前后的固定大小的数据。因为只有这部分数据分享利用率才是最高的。

如上图所示，有色彩的数据块都是以后在内存缓存中的数据，其中红色数据块示意以后的播放点，黄色数据块示意过来曾经播放过的内容，绿色数据块示意将来还未播放的内容，能够看到当播放点从 100 挪动至 101 时，97 号数据块就被淘汰了，同时 103 号数据块作为最新的数据被下载下来并缓存到内存中。

七、工程实际

Goggle FlatBuffers

不论是服务器通信还是点对点的 P2P 传输均采纳了 FlatBuffers。FlatBuffers 具备跨平台、内存和效率速度高，扩大灵便等劣势，被咱们全平台对立采纳，大幅升高了通信老本。

多浏览器兼容

线上反对 WebRTC 的浏览器不仅品种繁多，而且同一个产品的不同版本之间也可能千差万别。为了解决这一痛点，最终采纳了 WebRTC adapter.js 来解决这一挑战。

内存池

只管 Node.js 自带垃圾回收机制，以及内存管理策略，然而 GC 和内存调配也是须要老本的，况且 Web 端是单线程环境，任何性能的晋升都会缩小工夫上的损耗，进而能够解决更大吞吐的网络层传输以及业务逻辑。所以在内存调配上咱们采纳了内存池策略，根本实现了 100% 的内存重复使用。

八、技术后果

下图展现某次大型直播的带宽分时统计，显示在 19:25 到 21:00 阶段内的实在数据，随着人数的涌入和离去，Web P2P 全程带来可观的带宽收益。最终评估 Web P2P，在不影响用户应用体验的前提下，不仅能够无效升高服务器的负载压力，并且可能升高可观比例的带宽老本。

九、思考总结
目前，该技术曾经大规模利用在各网络直播中，良好的解决了服务质量与带宽老本的均衡。然而，咱们也发现在超大规模的直播下，存在了一些晋升的空间，次要如下：

(1) coturn 与 MQTT 的服务性能不高，会制约直播的服务质量。

(2) 接入边缘网络，打造多元化网络，缓解 CDN 负载，并且能够进一步升高 CDN 的带宽老本。