nile.js原理分析 - 基于DHT的Scalable的p2p实时视频直播

今天看到这个项目的时候还是挺兴奋的，一直以来都想尝试基于分布式哈希表的支持大量peer的直播流。不过随着了解深入，发现它只是简单的将本地视频录下来之后使用WebTorrent下载传输下去。作者解释是由于WebTorrent本身的限制，理论上是应该直接使用流的方式实现的。

这里我们不讨论直接使用流的方式，只涉及nile.js中p2p视频直播的原理。

简介

大家知道WebRTC所建立的p2p网络是十分原始的，假设我(x)要连接接到网络中的另外三个节点abc，那我就要分别与他们都建立连接(x, a), (x, b), (x, c)。

x - abc

然后我要直播给他们看的时候，我就要给这三个连接都发送视频流，假设我的视频流折算成网速是100k/s，那么我跟他们仨传，流出流量就是300k/s。人越多我流出的流量就更多，这当然是不可扩展的。而且WebRTC的连接还不一定连得上。

然而p2p网络发展到现在早已不是你链接我这种原始的方式了，基于中心节点的、去中心化的、基于分布式哈希表等的p2p网络方案，现在都有了广泛的应用（不然各种下载神器、种子哪来的）。

nile.js就主要通过WebTorrent使用一种类似于BT种子下载的方式实现了实时视频直播的方案。

原理

主要分三部分：

• Broadcaster (WebTorrent)
• Viewer (WebRTC & WebTorrent)
• Server (Socket.io)

首先讲一下这里涉及到的两个工具WebTorrent和Socket.io的作用。

WebTorrent 在这里主要的作用有两个：

1. 把文件做种成磁力链接（可以看成下载视频的种子文件，大家懂的）
2. 通过磁力链接获取到文件（这里的下载过程对用户来说是透明的，就是去中心化的纯分布式的下载，类似BT种子）。

而建立WebRTC的PeerConnection需要交换信息，因此要搭建信令服务器，这里Socket.io的主要作用就是这个，不过它还起到下发磁力链接的作用。

然后讲一下工作原理：

1. Broadcaster也就是直播者，将直播视频流录制成7秒时间间隔的短视频片段。
2. 将短视频片段通过WebTorrent制作成磁力链接，共享到p2p网络中
3. Viewer也就是观众，得到这些短视频片段的磁力链接之后通过WebTorrent构成的p2p网络下载这些片段，并且按照顺序进行播放。

是不是很简单，它主要依靠了WebTorrent的强大能力来保证视频文件传输的正确性和速度，而且理论上可以支持无限多的观众来观看直播的，并且不消耗额外的服务器资源。

原理

然而上面似乎都没有用到WebRTC，WebRTC在这里起到了什么作用？

有一点比较明显的作用是获取视频流，然后通过MediaRecorder录制成视频文件的buffer或者blob。

附加优化

WebRTC在这里还有一个用处就是使用DataChannel分发磁力地址，减小服务器负担。这块的负担并不是指视频，二是指长连接Socket.io连接数。

刚刚说到Broadcaster把录制好的视频片段生成一个磁力链接之后，Viewer都会得到这个磁力链接，我们默认得到方式是通过Server中的Socket.io来分发，这样的话所有的Viewer就都会链接到这个长连接服务器，那这块就又不是Scalable的了。

都通过socket.io

所以nile.js聪明的地方在于：

只有有限的节点会通过socket.io获得磁力链接，其他的节点的磁力链接都是通过这些根节点通过DataChannel的p2p的方式得到的。

nile.js的方案

问题与不足

1. 因为有录制发送下载的过程，因此延迟较高。Demo里大概有10秒以上。
2. 项目很多坑，可用性较差。

更进一步

1. 可以去了解一下WebTorrent
2. 原理很简单，而且可以扩展到任意平台，手机app理论上也可以
3. 直接使用流