在各种音视频应用充斥着市场的时候,毫无疑问,流媒体领域将会非常适合区块链技术进行场景落地。在上一篇文章中,我们主要讨论了 PPIO 的 PCDN 架构,接下来将介绍 PPIO 的中 P2SP 的下载逻辑和 IaaS 层的流量计数。

下载逻辑

上图为 PPIO 的 CDN 和 P2SP 的传输架构图。这里将会重点讲解 PPIO 中 P2SP 的下载逻辑,它主要分三个部分,Buffer 管理,下载状态机,和下载算法。接下来会对这三部分一一解释。

Buffer 管理

Buffer 管理,即理解为本地设备管理着资源情况,从而决定需要下载的 Piece 的优先级。Buffer 管理也是和实际应用场景是相关的,对于流媒体来说,存在一个视频播放位置,播放位置附近的内容就是紧急内容,该内容则会被优先下载。

#1 普通文件下载的 Buffer 管理逻辑

文件下载的 Buffer 管理相对简单,因为没有具体的播放位置,即内容在紧急程度上没有区别。下载算法将采用稀缺优先的逻辑,优先下载网络中稀缺的 Piece。Piece 越稀缺,其下载的优先级也就越高。如下图:

下载 Buffer 管理示意图

在示意图中,我们假设所有 Peer 都是一样的,而因为 CDN 节点的存在,实际情况则会复杂得多。CDN 可以被认为比较优质的,但是它不适合请求分散的碎片数据,更适合下载一段连续的数据。之所以将稀缺性作为普通文件的 Buffer 管理的指标,是为了增加 P2P 网络的资源健康度,并且让数据尽快在 P2P 网络中传播。

#2 流媒体的 Buffer 管理逻辑

和普通文件下载不同的是,流媒体下载存在具体播放位置,为了保证视频的观看体验,越接近播放位置的数据将会优先进行下载。

流媒体的 Buffer 管理示意图

设计 PPIO 的时候,我们根据视频播放位置,在流媒体下载的过程中,将其分为多个区间,越靠近播放位置的区间,下载优先级越高。

已过区间:视频播放位置之前的数据,无需进行下载。

紧急区间:需要立即播放的数据,在此区间的数据将采用极端下载策略,旨在以最快的速度获取数据。Piece 越靠近播放位置,下载优先级越高。这种策略更加依赖于 CDN 和超级节点,尽管有重复下载的风险,该区间将同时进行 P2P 下载,即在第一时间从多个 Peer 下载数据。

正常下载区间:稍后进行播放的数据。虽然此区间的数据也会很快被使用到,但是紧急程度不如紧急区间,因此这部分数据,也是越靠近播放位置的 Piece,下载优先级越高。但是此区间的策略不要过多依赖于 CDN 节点,并且在 P2P 下载的时候,尽量避免重复下载。

长远区间:播放时间迟于正常下载区间的数据,这部分采用类似于普通文件下载的稀缺性优先下载的逻辑。此区间的数据下载尽量不要依赖于 CDN 节点。

下载状态机

状态机是什么?它是一种根据 Buffer 状态来进行下载数据的方式。下载数据的方式有2种: P2S,即从 CDN 中下载数据;P2P,即从其他多个 Peer 中下载数据。那么这两种方式是如何切换的呢?这就是下载状态机要解决的问题。

#1 普通文件下载的状态机设计

普通文件下载的状态机随时评估 CDN 和 P2P 的下载质量和资源情况,在三个下载状态中相互切换,直到把文件完整地进行下载。

普通文件的下载状态机

#2 流媒体点播的状态机设计

流媒体状态机和普通文件下载状态机虽然类似,但是在其之上稍作改进,在判定 P2P 资源不足以支撑流畅播放的时候,直接放弃 P2P 的下载方式,不再尝试几种状态的切换,避免造成不必要的开销。

流媒体点播的状态机

下载算法

下载算法,就是将不同的待下载 Piece 分配到多个不同的 Peer 上的算法。这个算法在普通文件下载和流媒体下载的时候是不一样的。

#1 普通文件下载

PPIO 的调度算法大致如下:

  1. 为了数据传输更加高效,下载节点与每个拥有资源的 Peer 建立起多个连接。这里的连接,不限于 TCP 协议,也有 UDP 协议实现的会话逻辑。PPIO 同时兼容多种协议,在不同的网络环境下切换不同的协议,以应对网络的异构性;
  2. 对于每个 Peer,根据历史的数据传输情况,我们都进行速度预测。如果没有历史记录,则使用一个根据历史经验得到的默认值,缺省经验值;
  3. 根据 Buffer 管理的情况,确认所有下载 Piece 的优先级,然后随机通过连接向其他 Peer 发起 Piece 数据请求,对方接受请求后,立即发送 Pieces 数据;
  4. 任何一个连接只要收到一个 Piece,立即更新该连接的速度预测,并根据 Buffer 管理的情况请求下一个没有被下载的 Piece,直到下载完成;

如果 Piece 数据请求长时间没有得到回应,则会向其他 Peer 请求数据。对该长时间没有回复的 Peer 做惩罚,这个惩罚可能会减少该 Peer 连接数,从而降低该 Peer 下载权重。


根据以往设计高速 P2P 网络的经验,PPIO 采用对每个 Peer 进行多虚拟连接下载,这个虚拟连接是支持多种协议之间切换的,其底层协议,会先尝试 UDP,如果 UDP 不通再尝试 TCP,极大的提高了传输效率。为什么要这样做呢?那是因为 TCP 协议是多年以前根据互联网早期的状态设计的,其本身有弱点,即拥塞控制算法上采用了主动退让的逻辑,这会造成的传输的低效率,并不完全适合今天实际网络的传输。

#2 流媒体下载

PPIO 为流媒体下载提供了一套优化的 P2P 传输系统。为了保证观看体验,下载数据必须实时,并且能够应对 P2P 网络的不稳定性。为此,我们采用了数据驱动的 P2P 下载技术,并基于这个理念后做了很大的改进和优化,设计了一套基于预分配方式的 P2P 多点调度系统。实现最大化的下载速率,并将由于重复传输和请求所产生的开销降至最低。PPIO 流媒体调度算法的设计如下:

  1. 和文件下载器一样,给每个 Peer 建立多个连接,同时记录每个虚拟连接的历史下载速度;
  2. 对将要下载的 Piece,根据 Piece 的紧急程度(细节见前面的 Buffer 管理)排序做预分配至每个连接上,并预测每个 Piece 的到达时间,从整体来看,以越紧急越优先为原则。
  3. 针对未完成下载的 Piece,定时重做预分配,以适应每个连接传输速度的变化;
  4. 当每个连接每收到一个 Piece,则更新该通道的速度, 然后从该通道的预分配队列中找到下一个 Piece,并发起请求;
  5. 对于非常紧急的 Piece(需要立即播放),允许同时向多个 Peer 请求数据;

数据驱动的预分配下载算法示意图

PPIO 的 P2P 传输网络是完全动态的,可以持续保持高效状态。

你可能觉得目前为止我们所提及的都是传统的 P2SP 的技术,这和 PPIO 的区块链有关系吗?别急,下面就来解释一下,前面所介绍的内容,都是围绕着 PPIO 的 PaaS 层和 AS 层(Application Services层)所展开的。PCDN 的整个 P2SP 下载引擎都在 PaaS 层,流媒体格式和协议的支持,以及数据拆分,数据拼装都在 AS 层。而整个去中心化存储和区块链的基础设施都在 IaaS 层。

PPIO 整体商业化架构模块结构图

流量计数和IaaS层

PPIO 的设计理念不同于传统的 P2P 传输项目,传统 P2P 项目倡导的是“人人为我,我为人人”的共享网络,下载在传输上是“免费”的,上传是无偿的。而 PPIO 建立了激励网络机制,用户下载资源需要付费的,资源上传者进行一定的收费,即下载方要支付 Token 给上传方。

在 PPIO 的 IaaS 层,为了保证 P2P 网络的效率,不需要每个 Peer 都处理 Token 的支付和接收。因此 PPIO 设计了 Owner 机制。Owner 不是一个 P2P 传输角色,而是一个支付和结算角色。在 PCDN 架构中,每个 Peer 都需要指定一个 Owner。这个 Peer 产生的花费由他的 Owner 来承担,而同样该 Peer 赚取的收入也有他的 Owner 来接收。

如果在需求端,可以将其理解为 CPool(代理支付网关,见文章《为什么 PPIO 要设计支付代理节点》),如果在供给端,也可以简单理解其为“矿池”。对于 PCDN 业务来说,使用带宽的花费一般是由内容发布者来承担。

作为 User 的 Peer 要从一个作为 Miner 的 Peer 中下载数据,以下就是最简单的流程:

  1. Owner 先将足够的预支付款打到智能合约。
  2. User 从 Owner1 处申请一个 Check(类似于支票),Check 中含有这个智能合约的地址。以及最大消费额度,CheckID,过期时间等。
  3. Owner 审阅这个 Check 请求是否符合要求,若符合则将 Check 返还给 User;若不符合,比如申请的 Token 过多,则可以拒绝。
  4. User 向 Miner 请求数据(通过 P2P 数据传输协议)且顺利收到数据。
  5. User 会将 Check 扩展成 Voucher(类似于凭据),并发给 Miner,这个过程(步骤4和5)是多次的,Voucher 涉及的金额会越来越大。
  6. 当下载完成或异常终止时,就会提交该 Voucher 到 Miner 的 Owner,即 Owner2。
  7. Owner2 收到该 Voucher,会向该区块链智能合约发起提款。
  8. 如果 Voucher 正确且未超时,那么就能提款成功。

PPIO 最简单的下载流程图

对 PCDN 业务的开发者来说,既可自己部署 CPool(即 Owner),也可以接入其他第三方 CPool(即 Owner)。另外,如果下载方和上传方的 Owner 是同一个,那情况就会变得更加简单,交易不用上链,在 Owner 的内部进行即能解决,Owner 的金钱数量不会变动。就这样,PPIO 将 P2P 传输和区块链计费进行了有效的结合。

当然,这只是一个 PPIO 中 IaaS 层计费中的一个最简单的流程,实际情况会复杂得多。之后会有更多的文章来深度解析 PPIO 的 PCDN 相关的智能合约。

不可否认,流媒体领域在众多区块链技术应用场景中潜力巨大,PPIO 将结合自身丰富的 P2P 经验和前沿的区块链技术为大家带来更好的视频观看体验。体量虽小,能量巨大,好戏正要上演,还不赶紧加入社群一起探讨吧!