今天看到这个项目的时候还是挺兴奋的，一直以来都想尝试基于分布式哈希表的支持大量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 在这里主要的作用有两个：
- 把文件做种成磁力链接（可以看成下载视频的种子文件，大家懂的）
- 通过磁力链接获取到文件（这里的下载过程对用户来说是透明的，就是去中心化的纯分布式的下载，类似BT种子）。
而建立WebRTC的PeerConnection需要交换信息，因此要搭建信令服务器，这里Socket.io的主要作用就是这个，不过它还起到下发磁力链接的作用。
然后讲一下工作原理：
- Broadcaster也就是直播者，将直播视频流录制成7秒时间间隔的短视频片段。
- 将短视频片段通过
WebTorrent制作成磁力链接，共享到p2p网络中 - 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的方案
问题与不足
- 因为有录制发送下载的过程，因此延迟较高。Demo里大概有10秒以上。
- 项目很多坑，可用性较差。
更进一步
- 可以去了解一下WebTorrent
- 原理很简单，而且可以扩展到任意平台，手机app理论上也可以
- 直接使用流
