为什么专一于流媒体领域？PPIO 技术揭秘

工做日早晨8点的地铁，Lisa 拿出手机打开 Tik Tok 来打发半小时的通勤时间；12点，吃完午餐的 Lisa 趁着午休时间忙里偷闲看看 YouTube 上有趣搞笑的视频；晚上8点，忙碌了一天的她回到家以后躺在沙发上打开电视，在 Netflix 和 Hulu 上搜索着最新的电影准备充实夜晚的生活。看到这里，你是否是仿佛看见了本身的影子？确实，咱们天天都花费了大量的上网时间在音视频应用上，而对这一切咱们也许毫无察觉。

为何 PPIO 要作音视频

据2018年10月的《全球互联网现象报告》，视频应用使用所产生的流量占互联网总流量的58%左右。正如报告中所指出，视频应用在全球应用流量的份额出现了史无前例的增加。

PPIO 是为开发者打造的去中心化存储与分发平台，让数据存储更便宜、更高速、更隐私。官方网站是 pp.io 。

在设计 PPIO 的时候，咱们就把音视频这一方向视为重中之重，不只要顺利地支持主流音视频传输协议，还要把服务质量 QoS 作好。为了让你们能更好的理解接下来介绍的 PPIO 流媒体音视频的数据分发，咱们先来回顾一下 PPIO 的商业化架构。

PPIO 将陆续提供3套 API：

1. 基于 IaaS 层的存储空间和带宽租用的 API。

2. 基于 PaaS 的 POSS，PCDN，PRoute 的 API。

3. 基于 Application Service 层的点播，直播以及更多 API 接口。

开发者能够选择在任意一层进行开发，完成本身的 APP 或者 DAPP。

若是把 PPIO 和 AWS 云计算服务作对比，其层次类比为：

在 PPIO 的架构中，流媒体音视频的 API 是在 Application Services 层，由于它的场景很是贴近于应用，但 PCDN 的基础在 PaaS 层，下面将重点说明 PPIO 在流媒体视频上的设计尤为是流媒体视频数据分发的相关部分。

CDN 和 PCDN

CDN，全称是 Content Delivery Network，即数据分发网络，现代互联网的核心基础设施之一。CDN节点是在整个 CDN 的架构中最接近用户的节点。CDN 架构的设计初衷是将数据存储在中心，但中心数据并非离每一个用户都是最近的，因此 CDN 架构在不少边缘城域网上都部署了 CDN 节点，这些节点用于数据的缓存，当用户请求使用数据的时候，就能够快速直接地给出数据，从而保证了良好的用户体验。下图为 CDN 节点的架构图。

至今，CDN 技术已经发展了不少年，从事 CDN 业务的公司不在少数，而且已经出现大规模的商业应用。2018年末，全球 CDN 市场的总产值达到200亿美圆，市场规模巨大。

PPIO 在设计 PCDN 的时候，并非提出全新的数据分发方案，而是在现有 CDN 分发方案的基础上，给予 P2P 传输的补充方案，使得数据分发服务既可以兼容过去的方案，又能实现更廉价更高速。下图为 PCDN 兼容现有 CDN 方案的设计图。

分片和媒体

分片是 P2P 传输技术的基础。对 P2P 系统来讲，分片规则相当重要。那么，什么是分片？分片就是将一个文件或者一段流，按照某种统一的规则来进行切分和编号。被切分出来的每个单元称为 Piece，也就是 P2P 传输的单元。若是两个 Piece 编号同样，那么就认为他们是同一个 Piece。传统的 P2P 协议里面，分片是以中心化的方式来完成的；例如 BitTorrent 是由作种的用户（第一个用户）来进行分片，后面的 P2P 网络都按照第一个用户的分片方式来进行。

而 PCDN 的分片是不一样的。PCDN 使用的是 P2SP 的技术，这里的 S 指的是 Server（服务器），也就是说 P2SP 的数据最原始来源不是节点，而是一个标准化输出的 Server，多是 HTTP 协议，也多是 HTTP2，QUIC+HTTP/3 等其余协议。这样的 Server 在 CDN 体系下是标准化的，它们不具备切片的能力。因此 PPIO 在设计 PCDN 时，由 Peer（P2P 的普通网络节点）来分布式完成切片，因此这要求全部的节点，对于一个相同的资源里来讲，必须按照相同的分片规则来进行分片，从而确保 Peer1（节点1）和 Peer2（节点2）的分片是一致的。

PPIO 的分片方式是和文件结构或者流媒体协议相关的。 这里先介绍一下 PPIO 对两种主流的流媒体传输方式的兼容状况和具体方案，一个是分段流的方式，包括 HLS（Http Live Streaming）和 DASH 两种方式；另外一个是 HTTP 连续流的方式，好比 HTTP+FLV。此外，PPIO 将支持两种视频数据分发场景：直播和点播。

首先，说一下咱们对普通文件的分片方式。须要注意的是，这里的普通文件不是流媒体视频文件，不具有流媒体的特性。

首先定义一下名词。

Segment：文件，点播流，直播流的大段单位，不肯定是否固定长度。一个文件能够就是一个 Segment；可是一个直播流是由多个 Segment 组成；点播流看状况，多是一个 Segment，也多是由多个 Segment 组成。

Piece：P2SP 调度的最小单元，在 P2P 的 bitmap 会做为1个 bit 来表示。

SubPiece：最终 P2P 协议的传输单位，小于 UDP 的 MTU（通常为1350直接），PPIO 底层大量使用 UDP 协议。若是一个 UDP 报文大于 MTP，那么丢包率就会大大增长。

TS：Transport Stream，也就是分段流媒体的原始分段。这里以 HLS 为例，因此这里写成TS。若是是 DASH 流，就对应 FMP4。

TSP：对 TS 进行分片后的每一个 Piece。

VS：Video Segment, 对于 HTTP 连续流点播，由固定大小切片；对于直播，根据I帧边界和最小时长切分而得。

VSP：对 Video Segment 进行分片后的每一个 Piece。

#1. 普通文件的分片

如上图所示，

一个文件划分的 FS 等长，那么最后一个 FS 可能偏小。

每一个 FS 划分的 FSP 等长，那么最后一个 FSP 可能更小。

一个 FS 对应一个 bitmap，bitmap 中的一个 bit 对应一个 FSP。

若是是普通视频文件，透明支持拖动，也支持边下边播。用户若是拖动，播放器会指定 range，根据 range 和固定大小计算出 FS 索引，请求相关 FS 里面须要的 FSP。相关 FSP 下载完毕后，再合并流，传递给播放器。

#2. 点播

这里重点考虑了 PPIO 架构针对两种流媒体传输模式的分片。

#2.1 HTTP 分段流点播

这里，以 HLS 为例，DASH 等其余分段流相似。

从视频服务器上拿到 m3u8，获得里面的 TS 文件列表。通常来讲，一个 HLS 点播流所划分红的 TS 不必定等长。每一个 TS 划分的 TSP 等长，但最后一个 TSP 可能偏小。其中，一个 TS 对应一个 bitmap，bitmap 中的一个 bit 对应一个 TSP。

这样一样支持拖动：当用户拖动时，播放器指定 TS 索引，而后根据 TS 索引下载相关内容，相关 TS 下载完毕后，传递给播放器,  完成播放。

#2.2 HTTP 连续流的点播

这里以 HTTP+FLV 为例。

图中的 Tag 指得是流媒体中原始的数据特征。其中，一个 FLV 点播流所划分的 VS 等长，最后一个 VS 可能偏小；而每一个 VS 划分的 VSP 等长，最后一个 VSP 可能偏小。每一个 VS 对应一个 bitmap，bitmap 中的一个 bit 对应一个 VSP。FLV 点播的切片方式和文件下载的方式同样。

固然，这样也是支持边下边播和拖动的：当用户拖动的时候，播放器指定 range，根据 range 和固定的 Segment 大小来计算出 VS 索引，请求相关 VS。完成下载后，再合并流，传递给播放器。

#3. 直播

从切片角度来看，直播比起点播来讲要复杂。由于直播既没有开始，也没有结束，每一个用户开始观看直播的时候，下载的都是中间的数据。而且全部用户的数据要按照一样的分片规则来分片，这里不只仅要分片，并且还要可以同步。除此以外，通常直播还有回放功能。

这里重点阐述一下 PPIO 架构针对两种流媒体传输模式的分片的思考。

#3.1 HTTP 分段流直播

这里仍是以 HLS 为例，DASH 等其余分段流相似。

HLS 的直播和 HLS 点播的切片方式同样，假设当前直播 m3u8 文件， 播放 TS1，TS2，TS3，TS4，TS5。按照基准时延的设置，直播会从某一个 TS 开始播放，好比说从 TS1 播放，时延最长，所以从 P2P 网络中拿到数据的机会就越多，从而 P2P 利用率就最高；可是若是从 TS5 播放，时延最短，所以从 P2P 网络中拿到数据的机会就越少，从而 P2P 利用率就最低；若是从 TS3 播放，就是折中方案。

#3.2 HTTP 连续流直播

HTTP 连续流的直播，指的是一开始就没有结束的流，这里仍是以 HTTP+FLV 为例。

一个 FLV 直播流所划分的 VS 不必定等长，VS 以关键帧为边界开始，以一个时间单位为最小来进行切片时间。切片算法要保证每一个 VS 里面的每一个帧的数据都是完整的，而且必须包含一个关键帧。

假设当前直播播放 VS1，VS2，VS3，VS4，VS5，按照基准时延的设置，若是从 VS1 播放，时延最长，从 P2P 拿数据的机会就越多，P2P 利用率最高；若是从 VS5 播放，时延最短，从 P2P 拿数据的机会就越少，P2P 利用率最低；所以从 VS3 播放即是折中方案。

PPIO 除了支持 HTTP 分段流和 HTTP 连续流之外，后面还计划逐步支持其余媒体格式和协议。

分片只是创建起了 P2SP 下载的秩序，高效的传输架构也是不容忽视的。介绍完分布式切片的方式，那么接下来就要讨论一下如何用 P2SP 网络进行高效的数据传输。

P2SP 的传输是一种结合了 P2P 下载和从 Server 下载的下载方式。数据传输须要解决的问题就是在合适的时间挑选合适的方式进行下载。

这是 PPIO 的 PCDN 全节点架构图，在此，分别介绍一下里面的角色。

1. CDN 节点：

CDN 节点是在整个 CDN 的架构中最靠近用户的节点；用户能够直接从中获取数据。CDN 节点发展多年，如今已经支持多种传输协议，包括 HTTP，HTTP/2，QUIC+HTTP/3 等。

#2. Mapping 节点：

CDN 中有资源惟一 ID，而 P2P 中也有惟一 ID，他们拥有的资源 ID 并不相同，咱们在进行 P2SP 协同传输的时候要把不一样的资源 ID 映射起来。Mapping节点做用就在于此，其职责就是把这两种不一样的 ID 进行映射，并提供查询功能。

Mapping 节点是个商业节点，开发者能够本身开发 Mapping 节点，用于本身应用的场景，由于只有开发者本人最清楚 CDN 中的资源惟一 ID 和 PPIO 中 P2P 的资源惟一 ID 是否一致。

若是开发者不本身开发 Mapping 节点，也能够对接公用的 Mapping 节点。公用 Mapping 节点创建的就是 CDN 中的 Url 和 PPIO 中 RID 之间的对应关系。

Mapping 节点是必须的吗？不是，由于 Mapping 节点只是一种对应关系，若是这个对应关系对开发者来讲能够用一套简单算法直接离线实现，就不须要 Mapping 节点。

#3. Peer 节点：

Peer 就是 P2P 网络中的节点，在 PPIO 的网络中，Peer 便可能是存储节点，也多是用户，也可能二者都是（即上传数据又下载数据的节点）。在 PPIO 的供给和需求以及区块链设计中，通常会把存储节点和用户分角色来描述，可是在 P2P 网络中，大部分功能和代码都是一致的，因此在这都称为 Peer 节点，他们在传输协议上也是对等的。

#4. Tracker 节点

PPIO 中 Tracker 节点的定位和 BitTorrent 中 Tracker 的定位是接近的。主要是用于管理 RID（资源 ID, 用于标记一个文件或流）和 P2P 节点之间的关系。Tracker 上对每一个 RID 都记录了拥有该资源的 Peer 节点的关系。当一个 Peer 要获取一个资源的时候，首先从 Tracker 中查询到首批 Peer，而后就能够从拥有该资源的这些 Peer 中下载数据了。后续能够从这些首批 Peer 中利用“泛洪”的机制查询到更多的 Peer，最终在本地造成一个愈来愈大 Peer 库，直到发现几乎全部的 Peer。

看到这里，你必定会有这样的疑问。Tracker 不就是网络的“中心”吗？只要这个“中心”出现问题，网络不就出问题了吗？那么 Tracker 是必须存在的吗？固然不是，由于 Tracker 只是对初始节点的发现，而在 PPIO 中还有一套发现初始 Peer 节点的机制，那就是 DHT，即分布式哈希表。PPIO 是使用 KAD 算法来实现 DHT 的。不过使用 DHT 方式去发现初始节点的效率比较低，没有经过 Tracker 来得快速和高效。

开发者在基于 PPIO 进行应用开发的时候，能够根据本身的要求来选择 Tracker 方式仍是 DHT 方式。若是追求效率和 QoS，Tracker 方式更好；若是追求彻底地去中心化，就能够只使用 DHT 方式。

#5. SuperPeer 节点

在 PPIO 的分发网络中，还有一种特殊的 Peer 节点，咱们称为 SuperPeer。SuperPeer 是咱们根据各方面的技术条件利用算法自动选择出来的。SuperPeer 的筛选条件会有不少，网络状况，存储状况，长时间在线状况，抵押状况，以及历史违约状况等都会考虑。当各方面的技术条件都达到要求的时候，就能自动升级为 SuperPeer。

SuperPeer 做为高质量节点，算法上会被优先照顾，回报和收益也会较高。

#6. Push 节点

Push 节点是用于作预热调度的，简单地说，就是把人为判断的将来必定会变热的内容强行塞到大量的 Peer 上。虽然 PPIO 有经过 Overlay 网络天然发现变热的机制，可是天然变热每每比较慢，而经过 Push 节点调度变热，可以作到预先处理，当须要下载该文件的时候，网络中已经有大量的 Peer 存储了这个文件进行数据上传，从而大大提高了用户体验。

固然，PPIO 的流媒体设计并非三言两语就能说清楚的，这篇文章主要讲解了 PPIO 的 PCDN 架构，更多内容会在下一篇文章中为你们慢慢道来，关注 PPIO 公众号，不要错过最新的精彩内容！

想了解更多有关 PPIO 的信息，能够移步官网：pp.io