0 序
同学们整了个直播平台。
他们跑起来了！他们用的服务器没有前端！
他们自己写了！他们写挂了！他们来折磨我了！
1 技术栈
他们用的是这玩意 https://github.com/ZLMediaKit/ZLMediaKit。其实我是不开心的，因为这种大而全的东西往往代码都比较离谱，而且文档和沟通记录全中文，怎么看怎么离谱。
不过我不趟这浑水，跑都跑起来了管他干啥。
2 HLS
HTTP Live Streaming，缩写为HLS，是由苹果公司提出基于HTTP的流媒体网络传输协议。是苹果公司QuickTime X和iPhone软件系统的一部分。它的工作原理是把整个流分成一个个小的基于HTTP的文件来下载，每次只下载一些。当媒体流正在播放时，客户端可以选择从许多不同的备用源中以不同的速率下载同样的资源，允许流媒体会话适应不同的数据速率。在开始一个流媒体会话时，客户端会下载一个包含元数据的扩展 M3U (m3u8) 播放列表文件，用于寻找可用的媒体流。
source: https://zh.wikipedia.org/wiki/HTTP_Live_Streaming
支持上，Chrome 原生支持，Firefox 需要 hls.js 之类的插件。
HLS 支持事实上最广泛，很容易在 Github 上找到一车 HLS 的库。
缺点是标准的 HLS 受到切片时间限制，延迟往往会超过 5s 甚至 15s。
后来果子又整了个 LLHLS，但是技术栈不支持这东西。
直接套用 video.js 就可以获得良好的体验。
延迟太大了，得解决一下。
3 HTTP-FLV
你说的 FLV，是不是那个已经进了坟墓的 Flash？
还真是。
技术细节没啥可讲的，只要我不发 context-length，浏览器就不断连。
Flash 坟头草都比人高了，需要 flv.js 续命。
实践起来的话，flv.js 会更改 video 的 src，所以每次需要销毁并重建 video.js 来更换链接。
延迟在 3-5s。
4 WebRTC
一方面，我们不想和尸体打交道，另一方面，FLV 的延迟还可以更低，来看一下 WebRTC。
WebRTC (Web Real-Time Communication) is a technology that enables Web applications and sites to capture and optionally stream audio and/or video media, as well as to exchange arbitrary data between browsers without requiring an intermediary. The set of standards that comprise WebRTC makes it possible to share data and perform teleconferencing peer-to-peer, without requiring that the user install plug-ins or any other third-party software.
source: https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API
WebRTC 的连接分为以下几步：
- 通过信服务器交换两边的媒体数据和 ICE 服务器。
- 通过 STUN nat 打洞。
- 通过 P2P 连接。
这东西一看就知道纯纯的花活，不再像上面两者一样基于 HTTP 链接，而是通过其他协议来降低延迟。
WebRTC 在 Firefox 和 Chrome 系都内置支持。但是很难找得到库，似乎是因为大家的信令服务器的交换方式各不相同，令人头大。
好在手搓 sdp 交换难度并不大。
这东西的延时约在 1s 左右，相当吓人。
需要注意的是因为极低的延迟在网络波动时很容易卡顿以及 Firefox 在使用 Socks 代理时会无法建立链接。
5 结
最后提供了一个选择 HTTP-FLV 或 WebRTC 的选项。
没办法，WebRTC 延迟虽然低，但是又是会有波动性，还是要确保大家都能用。
Firefox 什么时候修 WebRTC 的 Bug 啊，我都找到好几个 issue 了。
乐
乐