摘要

在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，不蕴含音视频通信的内容。

三、总体架构

  1. H5 P2P客户端

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

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

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

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

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

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

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

  1. 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，上面别离简略介绍一下：

  1. ICE

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

  1. STUN

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

  1. TURN

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

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

六、数据下载

  1. 资源编码

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

  1. 下载调度

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

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

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

  1. P2P任务分配

a. 工作编号

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

b.调配申请

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

  1. 内存管制

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


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

七、工程实际

  1. Goggle FlatBuffers

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

  1. 多浏览器兼容

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

  1. 内存池

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

八、技术后果

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

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

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

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