工作日早晨8点的地铁，Lisa 拿出手机打开 Tik Tok 来打发半小时的通勤时间；12点，吃完午饭的 Lisa 趁着午休时间忙里偷闲看看 YouTube 上有趣搞笑的视频；晚上8点，忙碌了一天的她回到家之后躺在沙发上打开电视，在 Netflix 和 Hulu 上搜索着最新的电影准备充实夜晚的生活。看到这里，你是不是仿佛看见了自己的影子？确实，我们每天都花费了大量的上网时间在音视频应用上，而对这一切我们也许毫无察觉。
为什么 PPIO 要做音视频
据2018年10月的《全球互联网现象报告》，视频应用使用所产生的流量占互联网总流量的58%左右。正如报告中所指出，视频应用在全球应用流量的份额出现了前所未有的增长。
PPIO 是为开发者打造的去中心化存储与分发平台，让数据存储更便宜、更高速、更隐私。官方网站是 pp.io 。
在设计 PPIO 的时候，我们就把音视频这一方向视为重中之重，不仅要顺利地支持主流音视频传输协议，还要把服务质量 QoS 做好。为了让大家能更好的理解接下来介绍的 PPIO 流媒体音视频的数据分发，我们先来回顾一下 PPIO 的商业化架构。
PPIO 将陆续提供3套 API：
基于 IaaS 层的存储空间和带宽租用的 API。
基于 PaaS 的 POSS，PCDN，PRoute 的 API。
基于 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
