权利的游戏、破冰行动都烂尾了，那就来讨论一下视频点播吧

爱奇艺、腾讯视频、优酷、哔哩哔哩…… 我们经常在这些网站上追剧看电影，很多同学为了先于第一时间追剧或者不喜欢看广告，手里都有一个或多个会员

你说这些网站，我们冲了那么多会员，咋还不盈利呢……

咳咳，有点跑题，有同学问了，现在H5就有video标签，直接把视频地址填进去不就能看了吗？而且也可以边下边播。

确实能看，但是这种边下边播是基于渐进式下载（Progressive Download），是一种“伪流媒体”，这种方式会把电影下载到本地，而且会暴露视频的原地址，那样谁还去办会员呀。

所以，今天来浅浅的研究一下这些网站是怎么把视频在网站上呈现给我们看的。

协议支持

RTMP & HTTP_FLV

我们以前看在线视频经常听到一个格式--flv，FLV (Flash Video) 是 Adobe 公司推出的另一种视频格式，是一种在网络上传输的流媒体数据存储容器格式。包括现在还有很多网站都在用这种格式做视频点播或者直播，为什么把http_flv和rtmp放在一起，因为这两个协议实际上传输数据是一样的，数据都是flv文件。

RTMP，全称 Real Time Messaging Protocol，即实时消息传送协议。Adobe 公司为 Flash 播放器和服务器之间音视频数据传输开发的私有协议。工作在 TCP 之上的明文协议，默认使用端口 1935。协议中的基本数据单元成为消息（Message），传输的过程中消息会被拆分为更小的消息块（Chunk）单元。最后将分割后的消息块通过 TCP 协议传输，接收端再反解接收的消息块恢复成流媒体数据。RTMP的延迟很低，适合用于直播领域。但是RTMP基于 TCP 传输，非公共端口。另外apple一直想要干死Flash，所以apple的设备都不支持RTMP。

HTTP-FLV 也是Adobe推出的，根据http中的 Content-Type 来选择相应的程序去处理相应的内容，使得流媒体可以通过 HTTP 传输。相较于 RTMP 协议，HTTP-FLV 能够好的穿透防火墙，它是基于 HTTP/80 传输，有效避免被防火墙拦截。除此之外，它可以通过 HTTP 302 跳转灵活调度/负载均衡，支持使用 HTTPS 加密传输，也能够兼容支持 Android，iOS 的移动端。

HLS

HLS （HTTP Live Streaming）, 是由 Apple 公司实现的基于 HTTP 的媒体流传输协议。Apple 的全系列产品支持，由于 HLS 是苹果提出的， 所以在 Apple 的全系列产品包括 iphone、 ipad、safari 都不需要安装任何插件就可以原生支持播放 HLS，鉴于Apple在移动端的地位 Android 也加入了对 HLS 的支持。然而PC端的浏览器大多都不支持原生播放HLS，但是他们之中有个叛徒 -- Edge。

HLS 的基本原理就是将视频文件切分成很多小段的ts文件，同时建立一个 m3u8 的索引文件来维护最 ts 片段的索引。当播放视频时，它是从 m3u8 索引文件获取 ts 视频文件片段来播放。相对于 RTMP 协议 ，HLS 最大的不同在于直播客户端获取到的并不是一个完整的数据流，而是连续的、短时长的媒体文件，客户端不断的下载并播放这些小文件。 HLS 可以平滑的切换码率，以适应不同带宽条件下的播放。

但是 HLS 用作直播时的延迟较大，所以 HLS 更适合于点播服务，爱奇艺、腾讯、优酷的新视频都是用的 HLS 的方式。

MPEG DASH

苹果推出了 HLS ，但是却只有苹果设备才支持，Adobe 公司的协议苹果又不支持，这样给开发人员造成了很大的开发难度。所以很多公司（包括苹果公司）就一起制定了新的国际标准 DASH 。

DASH和苹果的HTTP Live Streaming（HLS）技术相似，MPEG-DASH通过把内容分割成小的基于HTTP的文件段序列，来进行流媒体播放。各个文件段可以设置成不同的比特率进行编码，以满足不同的客户端的网络需求。比如，DASH客户端可以根据当前的网络状况，自动选择对应的最匹配的比特率文件段下载，进行回放，而不会引起停顿或重新缓冲。这样，DASH客户端可以无缝地适应不断变化的网络条件，并提供高品质的播放，而能够尽量减少播放的停顿或缓冲。 DASH的特点也与 HLS 相似，直播时的延迟较大。哔哩哔哩、YouTube、Netflix、Hulu都是使用 DASH 方式

应用

每种协议都只能支持部分设备，那么媒体开发还是只能开发多个协议吗？显然不是的，这要归功于浏览器的新的API -- MSE（Media Source Extensions API）

媒体源扩展 API（MSE） 提供了实现无插件且基于 Web 的流媒体的功能。使用 MSE，媒体串流能够通过 JavaScript 创建，并且能通过使用 <audio> 和 <video> 元素进行播放。简单来说就是通过 MES 可以用 js 来把各种协议转化成浏览器能播放的形式，这样哪怕原生设备不支持的协议，我们可以通过 js 来搞定。

所以现在 H5 时代大多数视频网站直播在领域还是使用FLV的形式保证低延迟，通过 flv.js 在 H5 播放。在点播领域各大网站在 DASH 和 HLS 两种方案二选一，通过 dash.js 或 hls.js 实现 H5 播放。 虽然DASH是国际标准，但是 HLS 出现的更早，在业界占主流。

到现在为止，无论使用哪种协议视频应该可以播放了，但是对于视频网站来说，还有一个重要问题亟待解决 -- 防下载。毕竟网站花了好多钱买的版权，不能被人轻易的就下载拿走了。DASH 和 HLS 的切片可以增加下载难度，但是全部下载下来再反转回去对于技术人员来讲也不是难事。我们都知道前端是没有秘密可言的，所以要解决这个问题只能从内容下手了，对视频加密。

以 HLS 为例， HLS 支持AES-128方式加密，使用FFmpeg软件对视频文件进行切片与加密。在生成的m3u8文件中可以看到#EXT-X-KEY字样

其中URI字段是秘钥key的请求地址，在浏览器解析视频之前会先请求秘钥，再使用秘钥解密视频。

这样视频是加密了，但是会产生新问题，请求秘钥的时候会暴露秘钥，拿到秘钥一样是可以解密视频的。这也是对称加密的问题，在秘钥传输过程暴露秘钥，但是在视频播放的时候对于解密效率有较高的要求，不能采用非对称加密的方式。

所以视频网站的一个技术核心点就是如何隐藏秘钥key。这里我也没有深入研究，只能提供个思路：在URI上提供一个私有协议，然后拦截请求，拿到地址内容，对它进行各种变换解密，最终拿到秘钥。

各家网站的处理方式也不一样，但是有一点可以肯定，不管秘钥隐藏的有多深，总会有办法拿到的，所谓的防下载是不存在 100% 安全的，毕竟实在不行还有物理外挂--录屏呢。能做的只能是提高门槛，让大多数人都没办法轻易地把视频拿走。

所以，知道为啥今年这么多剧烂尾吗？先点个赞再说！