CN111372100A - 一种基于分布式选举的端到端内容分发网络系统和分发方法 - Google Patents

Abstract

本发明一种基于分布式选举的端到端内容分发网络系统，其特征在于：包括p2pcdn服务器集群和p2p客户端网络；所述p2pcdn服务器集群中可包含任意数量的服务器节点；所述p2p客户端网络中包含了任意数量的，需要使用所述端到端内容分发网络的p2p客户端端点，每个p2p客户端端点均可按需与所述p2p服务器集群建立连接。本发明能够充分利用手机、平板和PC在内的每台用户终端设备自身的上传能力，让各个终端设备之间互通有无，做到资源和数据的实时相互分享，组成“下载的人越多，速度反而越快”的新一代p2p CDN网络。

Description

一种基于分布式选举的端到端内容分发网络系统和分发方法

技术领域

本发明涉及互联网领域，尤其涉及一种基于分布式选举的端到端内容分发网络系统和分发方法。

背景技术

在互联网早期阶段，用户大多通过直接访问开发者架设的服务器来获取需要的文本、图片以及音视频等资源，如图 1所示，这种地域上远距离、链路上跨运营商的数据通信方式有延迟高、吞吐低、费用贵、并发性能差等致命缺点。最终导致内容提供商（CP）的带宽、流量等运营成本高，同时用户体验差（又慢又卡）。因此才有了这句多数中国网民当年都很熟悉的网语：“世界上最遥远的距离不是天涯和海角，而是我在电信、你却在移动”。为缓解上述问题，内容分发网络（CDN）技术应运而生。CDN技术从源站点层层拉取数据。在用户请求这些数据时，则尽可能使用与该用户较接近，并且ISP链路相同的数据缓存节点来向用户提供数据，如图 2所示，这种在地理位置和链路（运营商）层面上“就近供应”的方式显著地改善了用户体验。同时也有效降低了CP的网络流量成本（CDN流量费用主要由分发和回源两部分组成。综合来看，比未使用CDN前，使用CDN后可降低多达40% 左右的流量费用）。

但对CP来说，CDN费用仍然高昂。同时在高峰时段或对热门内容而言仍然有明显迟缓及卡顿，用户体验不佳。

综上，现有的CDN方案仍存在两大问题：

1. 流量费用高：越多用户访问就意味着越昂贵的流量成本。实际上，流量费用已经成为各音视频点播及直播网站的主要支出成本。据报道，优酷2011年度的流量成本就高达数亿元人民币；而youtube仅2009年度的流量费用，就已高达数十亿美元。

2. 卡顿、用户体验差：越多并发用户就意味着越多人同时分享有限的带宽资源（同时看的人越多就越卡）。因此在遇到爆点视频、热点文件下载，以及重大直播或网游活动等事件时无法避免卡顿，极大影响用户体验。

发明内容

本发明的目的是：提供一种基于分布式选举的端到端内容分发网络系统和分发方法，能够充分利用手机、平板和PC在内的每台用户终端设备自身的上传能力，让各个终端设备之间互通有无，做到资源和数据的实时相互分享，组成“下载的人越多，速度反而越快”的新一代p2p CDN网络。

为了实现上述目的，本发明的技术方案是：

一种基于分布式选举的端到端内容分发网络系统，包括p2pcdn服务器集群；所述p2pcdn服务器集群中可包含任意数量的服务器节点；所述p2pcdn服务器集群将每个待分发或共享的资源切分为数据块，并通过选举的方式在所述p2pcdn服务器集群中，为所述数据块分别选定各自的属主服务器节点，并以所述数据块为单位，对资源进行端到端的分发或共享。

进一步的，在每个所述p2pcdn服务器节点内部，为每个属于该服务器节点的所述数据块分别选举出对应的属主进程、属主线程或属主协程。

进一步的，所述数据块的属主节点，或其属主进程、属主线程或属主协程负责对该数据块的各项状态进行追踪、匹配和协调。

一种基于分布式选举的端到端内容分发网络系统，包括p2pcdn服务器集群和p2p客户端网络；所述p2pcdn服务器集群中可包含任意数量的服务器节点；所述p2p客户端网络中包含了任意数量的，需要使用所述端到端内容分发网络的p2p客户端端点，每个p2p客户端端点均可按需与所述p2p服务器集群建立连接；

所述p2pcdn服务器集群对外提供如下API原语：初始化（Init）、接收消息（消息推送，WaitMsg）、组网匹配（请求数据块，AcquireChunk）、分享数据块（OfferChunk）、取消数据块分享（RevokeChunk）。

进一步的，所述p2pcdn服务器集群对外提还供如下API原语：P2P连接发起（p2pOffer）、P2P连接回应（p2pAnswer）。

一种基于分布式选举的端到端内容分发网络系统的分发方法，所述p2pcdn服务器集群通过以下步骤处理来自p2p客户端端点的请求：

步骤1、等待并接受由p2p客户端发来的下一个请求；

步骤2、如果该请求是一个“Init”API请求，且该API请求并不在一个有效的会话上下文内，则为其创建新会话，并通过选举成为此新会话的属主；若该API请求正处于一个有效的会话内，则在其属主节点中查询该会话的相关信息，并通知所有该会话当前正在对外共享的数据块的属主节点，从其对应数据块的相关记录中淘汰该会话；

步骤3、如果该请求是一个“WaitMsg”API请求，则按需通过此调用向对应的会话推送消息；

步骤4、如果该请求是一个“AcquireChunk”API请求，则以任意给定规则为该会话（受体）匹配到任意个符合条件的供应方（供体），并向这些供体端点推送对应的资源请求“Res.Req”消息；

步骤5、如果该请求是一个“OfferChunk”API请求，则在当前会话的属主节点上更新和跟踪该会话的数据块分享状态，并尝试选举成为这些数据块的属主节点或通知其已存在的属主节点，将此新增的供体端点信息新增或更新到这些数据块的相关记录内；

步骤6、如果该请求是一个“RevokeChunk”API请求，则在当前会话的属主节点上更新和跟踪该会话的数据块分享状态。并通知这些数据块的属主节点，将当前会话从这些数据块的相应供体记录中删除或淘汰；

步骤7、跳转回第1步（继续处理下一个请求）。

进一步的，所述p2p客户端通过以下步骤访问所述p2pcdn服务器集群：

步骤1、初始化：使用“Init”API获取或重置会话，并通过“WaitMsg”API建立消息推送连接；

步骤2、针对当前会话上的资源，使用"AcquireChunk"API请求获取来自其它p2p客户端端点的数据块分享，或通过普通CDN、源站点或其它传统分发渠道分别获取其数据块；

步骤3、当接收到由p2pcdn服务器推送的p2p连接请求消息时，尝试与指定的受体端点建立p2p连接，成功建立p2p子网后即可直接与该子网中的各供体端点通信，接收由其发送（共享）的数据块内容；

步骤4、将已成功获取到的数据块加入本地缓存，并实时或定期通过“OfferChunk”API发布这些共享；

步骤5、实时或定期通过“RevokeChunk”API将已无法继续共享的数据块通知p2pcdn服务器，以取消对这些数据块的共享。

进一步的，在步骤6之后还包括以下步骤，

步骤7、如果该请求是一个“p2pOffer”API请求，则向请求中指定的p2p客户端端点推送指定的P2P连接建立请求消息；

步骤8、如果该请求是一个“p2pAnswer”API请求，则向请求中指定的p2p客户端端点推送指定的P2P连接建立应答消息；

步骤9、跳转回第1步（继续处理下一个请求）。

进一步的，所述p2p客户端通过以下步骤访问所述p2pcdn服务器集群：

步骤1、初始化：使用“Init”API获取或重置会话，并通过“WaitMsg”API建立消息推送连接；

步骤2、针对当前会话上的资源，使用"AcquireChunk"API请求获取来自其它p2p客户端端点的数据块分享，或通过普通CDN、源站点或其它传统分发渠道分别获取其数据块；

步骤3、当接收到由p2pcdn服务器推送的p2p连接请求“P2P.Offer”消息时，调用“p2pAnswer”API来建立p2p子网，成功建立子网后即可直接与该子网中的各供体端点通信，接收由其发送（共享）的数据块内容；

步骤4、将已成功获取到的数据块加入本地缓存，并实时或定期通过“OfferChunk”API发布这些共享，并通过“p2pOffer”API组建p2p子网，以便将它们共享给其它p2p客户端端点；

步骤5、实时或定期通过“RevokeChunk”API将已无法继续共享的数据块通知p2pcdn服务器，以取消对这些数据块的共享；

步骤6、当接收到由p2pcdn服务器推送的资源请求“Res.Req”消息时，通过“p2pOffer”API尝试与对应的受体端点建立p2p连接，在p2p连接成功后，当前p2p客户端端点（供体）即可尝试向受体端点分享其请求的数据块。

进一步的，还可以提供“惯性滑行”优化，在每次成功建立p2p子网后，所述受体p2p客户端点尽量沿用所述已成功建立的p2p子网继续获取其所需的其它临近数据块。

发明相对于现有技术的优势：

本发明可以将每个人已经下载的数据实时共享给附近有相同需求的“邻居节点”，同时也获得邻居节点分享的数据，对用户而言不再卡顿，极大提升体验；对CP来说节省了昂贵的流量，显著降低运营费用。

附图说明

图1是一现有技术结构示意图。

图2是另一现有技术结构示意图。

图3是本发明一种基于分布式选举的端到端内容分发网络系统的结构示意图。

图4是图3的具体组成结构展示。

具体实施方式

以下结合附图进一步说明本发明的实施例。

请参见图3所示，假设用户A、用户B、用户C和用户D都在同时观赏同一个页面内的视频。那么他们就可以通过相互分享自身已经从传统CDN网络或其它用户那里下载的资源缓存（数据块）来避免绝大部分（可高达98%以上）的传统CDN网络流量。

这种终端用户互联互助的形式，一方面大大降低了传统CDN网络的压力以及CP的流量成本，另一方面也使得同时在线的用户数越多，参与相互分享的人也就越多，从而资源的访问速度就越快，越不会卡顿。最终使得在线用户数越多，用户体验反而就越好。

举例说明：比如老王在上海杨浦区的家里打开了优更酷网站，看“中国船长”。碰巧上海虹口区有个老张也在看这个视频。现在老张已经下载了老王准备观赏的视频内容，因此老王就不需要再从优更酷下载，而是直接从老张那里下载即可（由老张直接向老王分享数据）。其它如老孙、老李、老赵等都类似，大部分用户不用再去优更酷或其CDN渠道下载资源，而是可以实时的互相分享。

这样的方式一来可以为优更酷节省多达98% 甚至更高的流量费用：本来要从优更酷源站点及其CDN渠道下载的绝大部分网络流量都由用户之间的相互分享给分摊掉了。二来也解决了看的人多时播放卡顿的问题：看的人越多，相互分享的人就越多，播放反而会越流畅。

以上仅为示例，实际上本发明用途广泛，可用于（包括但不限于）：

音、视频直播和点播平台：对用户来说，视频打开更快、消除卡顿、码率更高。对平台来说，可大大降低流量费用。

视频和音频在线会议或通信平台：对用户来说，会议更流畅、延迟更低，音频和视频品质更好（可以使用更高码率）。对平台来说，可以显著减少流量开销、大大降低实时流媒体的转发费用。

图片、文档、文件分享平台：显著加快图片、文档和其它格式文件的下载速度，明显提升热门页面加载速度，大大降低流量费用。

付费培训平台：通过强加密和基于公钥体系架构（PKI）的密钥分发机制确保付费传播的媒体和文件无法被恶意第三方截获并窃取。与此同时加快资源加载速度和降低流量费用。

手游、端游、页游等：加速资源包下载，降低流量费用。

等在内的，任何需要分发内容（数据）的场合。

另外，依托于WebRTC Data Channel等标准组件。本方案不但可内置于各种App中，也可以直接用于浏览器页面（Web页面）内。即：可使任何浏览器页面成为p2pcdn的客户端，向其它客户端（其它网页或App）分享自身已获得的资源（数据块），或从其它客户端（网页或App）处获得自身所需的资源（数据块）。

综上，本方案至少具备：

流量费用低：可为CP降低高达98% 以上的流量费用。

用户体验好：避免卡顿，同时在线的用户越多，反而速度越快、播放越流畅。

适配性强：不同于“BT 下载”、“电驴下载”、“百度金矿”、“迅雷赚钱宝 / 迅雷玩客云”、“优酷路由宝”等需要用户安装对应应用程序和/或使用专用硬件的解决方案。客户无需使用任何特制的硬件设备，也无需安装任何客户端、SDK等程序，可在浏览器页面、桌面App和手机App等任意客户端内实现开箱即用的零感知p2p分发业务。

适应性好：可以更好地适应p2p网络变换莫测的节点和数据可用性变化等问题。在p2pcdn网络中，用户可能随时做出诸如：关闭或刷新当前页面、跳转到其它页面、切换视频清晰度、切换音轨（配音），以及跳转播放进度等各种操作。这些随机且密集的操作会使得某用户上一刻还可以分享的数据块，到下一刻就无法继续提供。本发明可很好地解决这类“网络节点和资源随时都在动态变化”情形下的实时资源分享问题。

实时性强：数据块级别的精细化调度可以更好地支持音视频直播、网络会议、网络视频聊天等实时性要求较高的场景。

分享度高：数据块级别的精细化调度也可以显著提高资源的分享效率——用户可立即向他人分享其缓存中已下载的数据块。而不用等到某个具体资源被完整下载成功后，才能开始对其进行分享。

兼容性广：适用范围广，适合音视频点播、直播，图片、文件等资源下载等各类资源请求相关场合。同时兼容各大浏览器和操作系统平台。

简单易用：只需在现有页面引入一个js文件，并进行少量修改即可开启p2p CDN功能。

公平互利：由于无法解决“针对变幻莫测且海量的共享资源及p2p端点之实时精准跟踪、调度、路由和协调”等核心难题，因此“百度金矿”、“迅雷赚钱宝 / 迅雷玩客云”、“优酷路由宝”等现有“P2P CDN”技术方案均需要想共享自己带宽的用户实现购买上述各厂商专用的硬件盒子。换句话说，就是用户自己先要买一个小型的CDN服务器回家（当然，在大部分情况下，这个小号的CDN服务器也被包装成了可以同时兼任宽带路由器等功能）。

虽然绕过了其无法解决的核心技术挑战，但其模式也因此而误入歧途：

要用户购买、部署和实施专用硬件：要花钱买硬件，而且以绝大部分网民的技术背景来说，就算买回来也多缺乏正确实施和部署的技术背景。

没有遵循平等互利准则，比如说张三买了某酷网的CDN路由器：

1. 那么张三不管是不是正在看某酷，都要 7x24 小时贡献出他的电力和带宽，帮某酷分享内容给其它人。

2. 就算张三正在看某酷，那么他分享的内容也并不是他正在看的那个视频，而是某酷先占用他家带宽下载那些该网站认为需要分享的内容到盒子上，然后再用张三的上行带宽来分享这些张三本人都不知道具体是什么的内容。

3. 这个盒子从硬件、系统到应用都是某酷家的，他们可以遥控这个盒子在张三家里做任何事。

因此比起本发明，上述技术方案至少存在以下缺点：

4. 需要用户购买专用硬件；

5. 需要使用者有能力实施和部署该硬件；

6. 用户顾虑：7x24 分享--抢我带宽，拖慢网速；

7. 有成本：由于没有遵循平等互利准则，因此大头要分润给用户--必须按照用户有偿提供其流量的模式来运作；

8. 资源有限：只有购买硬件并加入计划的固定用户可提供带宽，而无法充分利用所有在线用户的闲置上传能力；

9. 扩展能力差：由于p2p节点固定，因此不能随着在线用户数增加而等比增加流量输出能力。

很显然，这样的模式成本仍然高昂，同时难以获得广大用户的真正认可和支持。

而本发明很好地解决了上述传统p2p CDN技术中的挑战，故可遵循平等互利的公平准则，避免了上述问题：用户仅在享受由他人帮助的同时，才需要去对等地帮助他人。一旦不再享受他人的帮助，就立刻停止帮助别人。而且不需要购买和安装任何专用软件或硬件，同时只需运行在浏览器等安全沙箱环境中。

本发明无需购买和部署额外的专用软硬件设施，使得几乎所有在线用户都能够贡献自己的流量，真正做到了"人越多越快"。与此同时，得益于严格遵循对等互利原则，因此可无偿利用用户的上行资源进行互帮互助，大大降低了流量成本等优点。

1. 前导知识

从上面的场景我们可以容易地看出：不同于传统的BT、电驴等静态资源的p2p分享机制。p2p cdn的核心难点在于需要以超高性能对海量在线的对象（数据块）进行强一致的实时跟踪和调度。以及应对超大规模的并发连接和请求数量，和变幻莫测的动态路由规划等问题。

例如：用户可能随时关闭网页、大幅拖动播放进度条进行跳转，或者切换视频的分辨率（比如从720p切换到1080p）或音轨（比如从普通话切换到英文），这些行为都会导致该用户之前缓存的数据在上述动作发起的瞬间被完全丢弃，进而无法继续被分享。

再比如用户正常观看在线视频时，播放器中仅缓存有限的数据。例如：某网站页面内的视频播放器可能仅缓存相对于当前播放时间点的之前300秒和之后120秒（预读）音视频数据，而超出这个缓存窗口的数据都将被丢弃。因此即使在用户正常观看视频时，也会持续地产生老缓存不断失效（淘汰），新缓存不断被加载（预读）的动态过程。更不用提用户通过拖拉播放器进度条跳转时的情形了（会造成大量老缓存失效和大量新缓存被加载）。因此就需要p2p cdn节点能以较小尺寸的数据块为单位（例如每个数据块16kBK、32KB、48KB、64KB、256KB、512KB等），进行细粒度的分布式实时跟踪和调度。

由此可见，上述在节点状态不稳定（快速变换）的超大规模并发环境下，对海量数据块分别进行细粒度的实时跟踪和调度之需求，势必需要使用分布式的服务器集群和高性能、大容量的分布式协调算法才能较好地支持。

众所周知的分布式协调（服务选举）算法大体分为以下两类：

首先是多数派投票算法，如：Paxos算法，代表产品为Apache ZooKeeper（https://zookeeper.apache.org/、https://en.wikipedia.org/wiki/Apache_ZooKeeper）以及Google Chubby（https://static.googleusercontent.com/media/research.google.com/zh-CN//archive/chubby-osdi06.pdf）等；Raft算法，代表产品为Consul（https://www.consul.io/、https://en.wikipedia.org/wiki/Consul_(software)）、以及etcd（https://etcd.io/、https://en.wikipedia.org/wiki/Container_Linux#ETCD）等；以及拜占庭算法等。

上述多数派投票算法均可提供强一致、高可用的分布式协调（如：服务选举、服务发现、分布式锁等）服务。但同时也存在容量小（通常能同时管理的在线对象在十万量级）、性能差、开销大（每次请求都要产生多次网络广播和多次磁盘IO）等缺点。使其对网络吞吐和通信时延要求很高，无法部署在跨IDC（城域网或广域网）环境。也无法应对高并发环境下的海量对象高性能实时协调等场景。

其次是散列 / 一致性散列算法：该算法通过对被管理（被选举）对象的名称或ID唯一特征值取散列等计算操作来实现选主（服务选举）的目的。

以最常见的取模算法为例：假设当前服务器集群中包含了N个节点，节点编号依次为0，1，2，...，N-1。此时若：

a) 所有节点都知道当前集群中有N个节点正常在线，并且

b) 大家都约定将任意给定对象的ID或对象名的散列等特征值，除以当前集群中的节点个数（N），然后取其余数（取模）即为该对象的属主节点的编号。

那么理论上就可以为任意给定对象在当前集群中选举出唯一一个与之对应的属主节点了。例如：

假设当前服务器集群中包含了100个节点，节点编号依次为0，1，2，...，99。此时给定一个ID为12345的对象，那么该对象则归属于集群中编号为45的节点（12345除100余45）。即：该对象的属主为第45号节点。

使用此类算法的知名产品如memcached（https://memcached.org/、https://en.wikipedia.org/wiki/Memcached）以及redis（https://github.com/antirez/redis、https://en.wikipedia.org/wiki/Redis）等。

众所周知，此方法至少存在如下缺陷：

1. 一致性问题：此方案能够成立的假设前提是：集群中的每个节点都精确地知道每时每刻该集群中具体包含了多少个节点。这实际上是不现实的，因为一个集群中的节点会因为故障、运维等原因随时增加或减少。

考虑上例中的集群，由于电力、网络或硬件故障，在某个时刻减少了2台（从100台变为98台）。则剩余的98台节点基本不可能同时感知到这一事件的发生。意即：哪怕剩余的98个节点最终都会感知到有2个节点故障下线，但这一感知过程在这98个节点上并不是整齐划一地在同一时间完成的，而是在各个节点之间存在先后顺序。

举例来说，当集群中的2台节点下线500ms后的时刻，很可能0号节点尚未感知到它们已下线，还认为集群中的100台服务器全部在线；而1号节点此时则已经检测到了有一个节点下线，因此它认为此时当前集群中仍有99个节点在线；而2号节点则在此刻检测到了所有2个节点均已下线，因此它认为此时当前集群中仅余98个节点在线。

那么此时再给出ID为12345的对象，0号节点将认为其属主仍为12345 % 100 = 45号节点；1号节点则会认定其属主为12345 % 99 = 69号节点；而2号节点则将判定其属主为12345 % 98 = 95号节点。

由上例可知，每当集群中的在线节点数量发生变化时，使用该算法选主都可能产生严重的一致性问题：集群中的不同节点在处理针对同一个对象（例如同一个资源或数据块）的请求时，将为该对象选择出各不相同的属主节点。这就导致了多主、脑裂等不一致问题。

需要说明的是“一致性散列”并未解决这个问题，其名称中的“一致性”只是为了缓解下文提到的属主失效问题。

2. 属主失效问题：正如在前文“一致性问题”中的例子所示，此算法集群中在线节点数量的微小变化，将会导致大量（几乎所有）对象的属主节点均发生变化。即：在有N个节点的集群中，即使仅有1个节点故障下线或恢复上线，都会导致几乎所有对象都失效，必须重新选举属主的问题。

很显然，这种惊群效应对集群的性能和可用性等有及其巨大的伤害。而一致性散列算法可在N节点集群中出现M节点变化时，将其失效对象控制在当前总对象数的M/N。例如：在管理着1000万对象的100节点集群中，若发生2个节点突然下线，则会导致1000万 x(2 / 100) = 约20万对象失效。因此一致性散列算法虽未根除，但确实有效缓解了上述属主失效（惊群）问题。

3. 负载不平衡：此类方法使用固定的数学公式来进行属主选举，完全不考虑当前集群中各服务器节点的负载情况。也无法实时根据集群当前负载情况进行动态的负载再分配（再平衡）。因此可能会产生集群中某些节点重载（甚至超载），而另一些节点轻载（甚至空载）的情况发生。这既降低了集群的整体利用率和集群性能，也劣化了用户体验。

由此可见，现存的分布式选举算法各自存在无法忽视的容量、性能、开销、一致性等方面的问题。

为解决上述问题，我方发明了BYPSS分布式协调算法：BYPSS可以在免除所有其网络广播和磁盘IO等开销的同时，提供与Paxos / Raft相同（甚至更高）等级之强一致、高可用分布式协调算法。与此同时，BYPSS还为用户提供了同时协调和管理万亿量级的在线对象的超高容量；以及千万量级并发、数亿次请求每秒的超强处理性能。与上述Paxos / Raft等传统算法及产品相比，其在容量、性能以及开销等方面均有高达数千至数十万倍的提升。

关于BYPSS的详细说明，可参考专利：CN2016103238805, PCT/CN2016/093880(WO/2016/169529), US10523586B2 (US20180048587A1), EP16782676 (EP3422668),SG11201808659V, KIRK-19002-HKSPT (19119473.7), J/003824(460) 等。

由于本发明需要对海量数据块进行属主节点选举（选主）。选举出的属主节点负责对对应数据块的状态（如：数据块的密钥、校验码、数字签名、授权信息、健康状态；当前可提供该数据块的端点（Peer）列表，以及其中每个端点对应的ISP、地理位置、SID等信息）进行实时追踪。

同时考虑到BYPSS算法在其性能、开销、容量、一致性、可用性等方面的巨大优势，因此我们下文将以BYPSS为例，来对本发明的技术方案进行描述（意即：BYPSS可为本发明提供强一致、高性能、大容量、高并发等好处）。但应当注意的是：BYPSS仅仅是为了方便说明而使用的例子，将其替换为上述或非上述的其它任意选举（选主）算法都不会对本发明产生任何影响。

2. 基本概念，在p2pcdn服务内，每个用户（User）可同时拥有任意个会话（例如：一个用户可同时在多个设备上用相同账号同时登陆同一应用，或一个用户可以同时打开同一站点上的多个浏览器页面。比如用户张三在IE浏览器里打开了站点“优更酷”上的“中国船长”视频页面；与此同时，他又在Chrome浏览器里打开了站点“优更酷”上的“中国列车长”视频页面，此时张三就同时拥有两个活动的“优更酷”会话）。而在每一个会话（Session，例如用户打开了一个视频播放页面，则该页面就可以被认为是一个独立的会话。会话通常由ID标识，会话的ID被称为Session ID或SID）中，可同时包含任意多个资源（Resource）。每个资源内又可同时包含任意多个数据块（Data Chunk）。

其中“资源”可以是图片、文件、音频、视频、程序、文档、消息等任意数据或实时数据流，一个资源可以由任意个数据块组成。数据块通常为事先约定好的固定尺寸（但也可以为互不相同的任意尺寸，例如：在处理HLS、DASH等分段数据，或者处理CMAF HLS、CMAF DASH等分段后再分片的数据等场景时，即使相同资源内的各个数据块也可能拥有各自不同的尺寸）。通常以升序的形式来对一个资源中的数据块进行顺序编号（但也可以以数字或名称等任意的方式来标识数据块）。因此，每个数据块都代表了指定资源中的某一段数据。

例如，在约定了数据块尺寸为32KB的前提下，资源：“2020/中国船长.1080p.mp4”的0号数据块表示该资源中，第0 ~ 32767字节的数据，而其1号数据块则表示第32768 ~65535字节的数据等等，依此类推。

此外，在本发明中，资源名用于唯一标识一个资源。显而易见，资源名应该具备以下两个特征：

相同的资源应该具备一样的资源名：除非希望对超级热点资源（例如：预计会有数亿或更多同时观看人数的视频直播等）预先进行分流处理（而不依赖本发明自身的数据块自动分裂/合并算法），否则应当尽量保证相同的资源拥有完全一致的资源名。

为此，在有多协议（同时支持http、https、rtmp）、或多主机别名（cdn.mysite.com、www.mysite.com、mysite.com）等的场合下，选择直接使用未经加工的URL来作为资源名可能就不是一个好方法了。因为不同协议和不同主机名的各种组合可能均指向同一个资源，这就使得一个资源同时拥有了多个名称（因此在p2pcdn系统中产生了分裂）。

不同的资源应该具备不一样的资源名：毫无疑问，在任意给定时间内，一个资源名应该可以无歧意性地唯一标识最多一个资源。歧义会导致各个p2p端点之间相互分享错误的数据块。

在一个实施例中，一个数据块可以由其所属资源名以及该数据块的编号之组合来唯一标识（也称为数据块ID，Chunk ID）。例如：“2020/中国船长.1080p.mp4:0”可以表示资源“2020/中国船长.1080p.mp4”下的零号（第一个）数据块。依照前文中的例子，这就代表了资源文件“2020/中国船长.1080p.mp4”中，位于第0 ~ 32767字节范围内的32KB数据。

需要注意的是，上述会话ID、资源名以及数据块编码等均仅用于举例。在实际应用中，它们可以为字符串（任意字符集编码）、整型、定点数、浮点数，以及二进制数据块（BLOB）等任意格式的数据（字节序列）。本发明对此并无任何限制。

3. 系统组成

如图 4所示，一个典型的p2pcdn系统由后端支持服务、p2pcdn服务器集群以及p2p客户端三个部分组成。

3.1. 后端支持服务

后端支持服务主要包含分布式协调服务，以及分布式消息队列服务等部分。

在p2pcdn系统中，BYPSS等分布式协调算法和/或服务主要用于完成服务选举和服务发现等工作：

1. 服务选举：正如前文所述，p2pcdn服务器集群通过分布式协调服务或算法来为服务器集群实现分布式的服务选举功能。

优选地，BYPSS可以为p2pcdn服务器集群提供强一致、高可用、高性能、高并发、低开销、大容量的分布式协调算法和/或服务。

服务选举的对象主要是资源、数据块、用户以及会话。例如：p2pcdn服务器集群可以通过使用分布式协调服务，为系统中的每个在线数据块（“在线数据块”即活跃、活动的，最近正在被分享和/或使用的数据块）分别选举出一个唯一的p2pcdn服务器节点作为其属主。

类似地，p2pcdn服务器集群也可以通过此服务为资源、会话、用户等其它在线对象选举出对应的属主服务器节点。

2. 服务发现：p2pcdn服务器集群中的节点可通过BYPSS等分布式协调算法查询指定对象的当前属主节点信息。例如：一个服务器节点可通过BYPSS服务查询到某个数据块的属主节点ID及其网络地址等信息。

优选地，服务发现与服务选举可被优化合并为一个请求。例如：服务器节点1向BYPSS发起选举，推举自己为数据块A的属主。若该选举成功，则服务器节点1在集群范围内正式成为数据块A的唯一属主（当然，该属主资格可由于管理、调度和故障等原因，被主动丢弃或被动剥夺），否则（已有其它节点成为数据块A的当前属主）BYPSS则返回数据块A的当前属主ID和地址等信息。

这样即可以仅通过一次请求即同时完成服务选举（若成功）和服务发现（若失败）两个动作，显著提升了请求效率。

需要再次强调的是，以BYPSS为例来说明分布式协调服务仅仅是为了方便说明。在实际应用场景中，可使用包括但不限於前文提及的各种算法和/或产品、服务来实现上述功能。

此外，分布式协调服务仅仅是逻辑上的服务。它既可以作为独立的服务被单独部署于与p2pcdn系统中其它角色（例如：p2pcdn服务器集群）相同或不同的物理或逻辑节点上，也可以作为p2pcdn服务器等系统中其它角色内的一部分，被嵌入和/或整合到其它业务逻辑内部（例如：被内置于p2pcdn服务器节点或p2p客户端节点的业务逻辑内）。

也就是说，无论最终以何种方式如何实现了上述服务选举和服务发现等算法，以及如何对其进行实施和部署，均不会对本发明的有效性造成任何影响。

分布式消息队列服务为p2pcdn服务器集群提供了服务器节点之间的高性能通信算法和/或服务。分布式消息队列服务既可以是如BYDMQ（http://baiy.cn/doc/byasp/mSOA.htm#BYDMQ、http://baiy.cn/doc/byasp/mSOA_en.htm#BYDMQ）、RabbitMQ（https://www.rabbitmq.com/、https://www.rabbitmq.com/）、RocketMQ（https://rocketmq.apache.org/、https://en.wikipedia.org/wiki/Apache_RocketMQ）、Kafka（https://kafka.apache.org/、https://en.wikipedia.org/wiki/Apache_Kafka）以及Redis（https://github.com/antirez/redis、https://en.wikipedia.org/wiki/Redis）等带有专门消息转发（Broker）节点的消息中间件；也可以是如ZeroMQ（https://zeromq.org/、https://en.wikipedia.org/wiki/ZeroMQ）等的，内置于具体应用程序（如：p2pcdn服务器节点）业务逻辑中的直连通信算法。

意即：与分布式协调服务类似，在本发明中，消息队列服务只是一个概念上的逻辑组件。它仅仅代表了p2pcdn服务器集群中的各个节点之间可以相互通信（投递消息）。它既可以作为独立的服务被单独部署于与p2pcdn系统中的其它角色（例如：p2pcdn服务器集群）相同或不同物理或逻辑节点上，也可以作为p2pcdn服务器等系统中的其它角色内的一部分，被嵌入和/或整合到其业务逻辑中（例如：被内置于p2pcdn服务器节点的业务逻辑内）。

也就是说，无论最终以何种方式如何实现了上述消息队列服务，以及如何对其进行实施和部署，均不会对本发明的有效性造成任何影响。

3.2. p2pcdn服务器集群

p2pcdn服务器集群向上消费后端支持服务提供的服务选举和消息通信等服务，向下接收并处理p2p客户端发起的各项请求，为客户端提供p2pcdn的跟踪、调度和协调等服务。p2pcdn服务器集群中，可包含任意数量的服务器节点。

p2pcdn服务器集群自身以会话为单位来管理用户，并以数据块为单位来管理当前活动的（正在被分享和使用的）所有在线资源。

p2pcdn系统在当前服务器集群中，为每个在线的数据块分别选举一个在当前时刻唯一确定的属主服务器节点。优选地，BYPSS可确保在一个p2pcdn服务器集群中，任意指定的数据块在任意给定时刻至多只有一个属主节点（即：可提供强一致保证，不会出现多主、脑裂等问题）。

与此同时，若p2pcdn服务器自身以多线程、多协程或多进程等方式实现，则在服务器节点内部还可以为其麾下的各个数据块（即：该节点已通过选举成功获得其所有权的数据块）再次分别推选出其属主线程（或属主协程、属主进程等）。优选地，由于同一节点内部的一致性容易保证，也不存在失效等问题，因此这种节点内部的二次选举可以通过散列、取模等简单的算法来实现。

在一台p2pcdn服务器节点针对某一给定数据块通过分布式协调算法和/或服务进行选举，并成功获得其所有权（即：成为该数据块的属主节点）后，此服务器节点即可在丧失（注销或失效）其所有权之前，对该数据块进行跟踪、协调、分析、匹配等管理工作。具体可包括：

服务器节点可为其麾下的每个数据块分别维护一张供体（donor）端点表：【供体端点表】中包含了所有可以提供此数据块（可将此数据块分享给其它用户或会话）的p2p客户端端点（因此叫“供体”端点）。同时还可以包含这些供体端点的所属ISP（互联网服务供应商，Internet Service Provider。如：中国电信、中国移动、中国联通、美国AT&T等）、其所在地区（如：中国上海、中国浙江、美国洛杉矶等）、以及其贡献度（根据成功分享次数、成功分享流量和成功比例等因素计算）、分享频率等在内的任意附加状态及描述信息。这些信息可以被用来更精准地描绘各个的供体p2p客户端端点（Donor Peer）的具体细节（画像），以便于更精准地进行p2p子网匹配。

上述供体端点表可以通过（包括但不限于）散列表、红黑树、B+树、数组、链表等任意数据结构和算法来实现。并可为其建立基于ISP、地区、贡献度等各项特性的任意多个单一或复合快查索引结构。

p2p客户端可以直接或间接（例如：通过其它客户端、服务器或消息中间件转发）地向指定数据块的属主服务器发起请求，声明自己可以或无法再继续共享该数据块。属主服务器在收到此请求后，可以通过修改该客户端节点于指定数据块对应的供体端点表中的相应条目来记录这些变化。

举例说明：比如服务器1（p2pcdn服务器集群中的1号服务器）收到了由p2p客户端A（供体端点）发来的“可以将某个数据块C共享给其它客户端端点”的请求（声明）后，即可将该客户端A的SID（会话ID）、所属ISP、所在地区等信息添加到数据块C的供体端点表中（假设服务器1当前正是数据块C的属主）。若在几分钟后，服务器1又收到了端点A发来的“取消供应数据块C”的请求，则可在数据块C的供体端点表中删除端点A所对应的条目，或将该记录标记为不可用。

服务器节点可为其麾下的每个数据块分别维护包含其所属资源ID、最后访问时间戳，以及其最近有效操作等在内的任意附加状态及描述信息。这些信息可用来帮助p2pcdn系统更精准地了解其麾下每个数据块的当前状态，以便于更有效地对其进行优先级调整、注销（淘汰，放弃对该数据块的所有权并释放相应内存等所有与之相关的资源）等管理操作。

例如：可以通过最近使用时间戳来周期性地主动淘汰那些指定时间内未被访问的数据块。或者通过使用LRU列表等方式来以活跃度为倒序，从最不活跃的数据块开始，强制淘汰那些超出了当前节点最大容量限制的数据块等等。

服务器节点可为其麾下的数据块进行p2p客户端【组网匹配】：当一个p2p客户端端点直接或间接地向某个指定数据块的属主节点请求对接该数据块的供体端点时（我们称发起这个请求，准备从受体端点接收数据块的p2p客户端为“受体”（donee）端点），该属主服务器节点可以针对此请求为此受体端点进行任意数量的供体匹配。

该匹配可通过利用与指定数据块相对应的供体端点表来进行，匹配规则可以是包括但不限於顺序匹配、随机匹配、ISP优先匹配、地理位置优先匹配、ISP+地理位置优先匹配、ISP+贡献度+地理位置优先匹配在内的任意方式匹配，或是这些匹配规则的任意排列组合。每次匹配的结果中均可包含任意数量的供体节点。

在匹配完成后，服务器节点可通过直接或间接的方式分别联系受体（请求者）以及为其匹配到的供体，以帮助它们成功建立起相互连接的p2p直连网络（p2p子网）。在受体和与之匹配的供体间，成功建立了p2p直连子网后，供体即可将受体所需的数据块，通过该p2p子网直接发送给受体（即：数据块的传输直接发生在受体和供体端点之间，不需要通过p2pcdn服务器等节点进行中转）。

例如：p2p客户端A（受体端点）向服务器1发起了一个请求为属于该服务器麾下的指定数据块D寻找合适的供体端点。服务器1利用其内存中存储的，与数据块D对应的供体端点表，按照双方的所属ISP、所在地区、贡献度、分享频率等维度进行最优匹配，最终挑选出了16个与端点A匹配的最优供体（p2p客户端端点B1~B16）。

在匹配完成后，服务器1分别联系端点A（受体）以及端点B1 ~ B16等16个供体，并通过为它们交换各自的SID、请求数据块（资源名+数据块编号）、SDP Offer及SDP Answer报文、NAT穿透报文（ICE Conditions）等信息来协调、引导和辅助它们顺利建立连接。

假设其中端点B16由于与端点A之间的网络连通性等问题而连接失败，则完成上述步骤后，端点A就分别与端点B1到端点B15等15个供体分别成功建立了直连（即：连接A-B1、A-B2，A-B3，……，A-B15等15条p2p直连连接）。可以将此直连网络看做以节点A为中心，由A辐射出15条边（每条边分别连接至B1~B15中的一个对应端点）的一个小型p2p网络。由于该p2p网络相对于当前p2pcdn系统管理的所有p2p客户端以及它们之间所有可能产生的p2p连接组合而言，通常为其微小子集，因此我们称该p2p网络为“【p2p子网】”。

换句话说，一个“p2p子网”就是针对某个特定的供求关系，在当前所有p2p客户端端点中，所可能组成的1:N连接的全集（即：在一个包含了M个客户端端点的集合中，逐一遍历每个端点，并让每次选出的端点与集合中剩余的所有N（1≤N≤M-1）个端点，在所有合法的N个子网规模取值范围内，进行各种可能的1:N连接组合，然后汇总上述排列组合形成的所有1:N可能性的集合）中，精选出来的其中一种连接方式。

优选地，由于属于一个资源的数据块在大多数情况下总是会被按顺序依次消费等特性，因此一个p2p子网在绝大部分情况下并不仅仅能够用来分享一个数据块。例如：端点A即可通过上述p2p子网，尝试向B1~B15等供体请求其需要的数据块D+1、数据块D+2、数据块D+3等位于数据块D附近的更多数据块，我们将在下文中详细讨论这种被称为“惯性滑行”的优化方法。

数据块级的分裂/合并：在同时分享和请求某数据块的会话过多时，为平衡服务器负载，同时提供分享效率，可以对该热点数据块进行分裂操作，即：将一个数据块分裂为更多的克隆块，每个克隆块分别交由不同的属主服务器进行管理。

优选地，与该热点数据块相关的各个会话（受体和供体）也可以（以任意规则）被分摊到各个克隆块来分别进行管理。

例如：当一个数据块A的相关会话（受体和供体）数量超出系统设定的阈值100000000（一亿）个后，系统可将其拆分为10个克隆块，并将它们各自交由p2pcdn服务器集群中的10个不同的服务器节点分别进行管理。优选地，与之相关的会话也可以随之被拆分，例如可使其中每个节点约管理其10%（约一千万）的会话。会话的拆分方式可以是随机分配、顺序分配，或按ISP、地域、贡献度等任意规则进行拆分。

数据块合并是上述行为的反向动作：当某一已分裂数据块的相关会话数量急剧减少时，可以将这些克隆块重新合并回一个数据块来进行统一管理。将已经数量不多的所有相关会话重新合并在一起，更便于为每个组网匹配请求统筹计算最优p2p子网。

此外，应该注意的是，前文中的“供体”与“受体”并不是互斥的两个角色。相反，除非发生（包括但不限於）以下例外情况：

某个p2p客户端由于网络连通性（如防火墙、代理等）或用户手动关闭p2p加速选项等限制，无法与任何其它p2p客户端点建立直连：此时该端点将成为一个只访问传统CDN服务的普通客户端。

由于未匹配到合适的供体，某个p2p客户端已从传统CDN等内容分发渠道获取到了当前会话下，其所需的所有相关数据块：此时该端点将成为一个纯供体。

由于某个p2p客户端正在使用3G、4G、5G等按流量计费的移动网络。为避免用户支付额外流量费用而暂停其供体功能：此时该端点将暂时成为一个纯受体。

等特殊情形，否则在一个典型的p2pcdn系统中，绝大部分p2p客户端节点都是在同时扮演着供体和受体这两种角色。换句话说，在本发明中，所有p2p客户端节点之间的身份地位上始终是相互平等的，本发明：既不会在其中选举出一个向其它p2p客户端“发号施令”（组织协调其它客户端）的“超级节点”（Super Peer）客户端；也不会限制只有某些身份特殊的“发布节点”（Publisher Peer）客户端才有资格向其它客户端分享数据；更不存在“种子节点”（Seed Peer）之类的概念。

这就与那些要在所有p2p客户端节点中选举出某些地位特殊的“超级节点”、“发布节点”或是“种子节点”的技术方案有本质区别：本发明只为数据块选举对应的属主服务器，而在本发明中，所有p2p客户端节点的身份都是相互平等的，并无任何“领导者”、“协调者”、“发布者”等身份特殊的存在。

此外，与传统CDN方式以文件（资源，尺寸通常在数MB ~ 数GB）为单位不同，本发明将资源分割为较小（通常为KB级）的数据块，并实现了在海量资源和超高并发用户场景下，对其中每个数据块分别进行实时跟踪、协调、分析、调度和匹配。

数据块级别的精细化调度不但可以更好地支持音视频直播、网络会议、网络视频聊天等实时性要求较高的场景，也可以显著提高资源的分享效率——用户可立即向他人分享其缓存中已下载的数据块，而不用等到某个具体资源被完整下载成功后，才能开始对其进行分享。除此之外，数据块级别的资源精细化调度也可以更好地适应如前文所述的p2p网络变换莫测的节点可用性和瞬息万变的数据可用性变化等问题。

除了负责管理数据块之外，p2pcdn服务器集群还要负责对用户会话进行管理。与管理数据块类似，p2pcdn也可以通过BYPSS等任意分布式协调算法和/或服务来为每个会话选择一个属主服务器。然后由选举成功的属主服务器负责该会话的管理工作。具体可包括：

维护会话表：每个p2pcdn服务器节点维护一张【会话表】，其中包含了其麾下所管理的所有当前在线的会话，以及其中每个会话所对应的SID、最后活动时间、推送消息队列、所属ISP、所在地区、贡献度、分享频率、以及该会话当前正在对外提供分享的资源及数据块列表等信息。

SID是会话的唯一标识。最后活动时间则记录了当前会话最后一次访问服务器的时间戳，通常作为会话验活的重要依据（例如：超过设定时长仍未成功联系服务器的会话可被判定为已下线）。对已下线的会话，p2pcdn系统可清空其所有正在分享的数据块等状态信息。

【推送消息队列】负责缓存待推送给相应会话的消息列表。消息推送队列一来可临时存储待推送的消息，防止在p2p客户端与服务器节点间的消息推送连接暂时断开时，所到达的消息丢失。二来也可为连续到达的消息提供自动批量打包发送（推送）的功能，显著增加网络传输利用率和吞吐量。

【资源及数据块列表】则记录了其对应会话当前正在分享的所有资源和数据块。资源及数据块列表可用于以会话为单位，实时精确地跟踪和统计每个会话当前的可分享资源状态。

会话表用来跟踪和维护当前服务器节点麾下，所有活动（在线）会话的实时状态。p2pcdn系统可以此为依据，更好地对资源、数据块和用户（会话）进行路由、协调和调度。

接收并处理来自其麾下会话的API请求：p2pcdn服务器节点要接收并处理其麾下各会话的API请求。例如：初始化、接收消息（消息推送）、组网匹配（请求数据块）、分享数据块、取消数据块分享、P2P连接发起（Offer）、P2P连接回应（Answer）等各项API请求（详见下文）。

管理【消息推送连接池】：每个会话（客户端）均可与服务器建立（直接或间接的）消息推送连接。消息推送连接可以长连接、短连接、长轮询、短轮询等任意方式，基于任意通信协议来实现。一个客户端中可同时包含任意多个会话，每个会话中可同时建立任意数量的消息推送连接（但通常为每会话或每客户端（用户）一个消息推送连接的形式）。客户端及其中的会话可通过消息推送连接，实时或周期性地接收由服务器推送而来的消息。

在连接池管理的过程中，服务器可以对超时、超限或重复的消息推送连接进行强制淘汰（断开连接）。

例如：在某个具体实施例中，一个客户端可同时开启多个会话，其中每个会话各自通过“接收消息”API，以HTTP长轮询的方式向其属主节点发起一个消息推送连接。该连接除可实时接收服务器推送的消息外，还同时兼任了为服务器提供心跳连接（更新其最后活动时间戳）的保活功能。

比如在该实施例中，我们可以将服务器端的长轮询超时设置为60秒（每次收到长轮询请求60秒内仍没有待推送消息则返回空响应。客户端每次收到响应后，应立刻发起下一次长轮询请求）；客户端长轮询超时设置为90秒（每次发起长轮询请求后90秒内仍未收到服务器返回则取消该请求，并立即尝试发起新的长轮询请求）；而将服务器端的长轮询心跳超时设置为120秒（120秒内未收到客户端发起的长轮询请求即认为该会话已下线）。

服务器周期性地将超过设定时限未发送心跳（重发请求）的连接从连接池淘汰，同时将其对应的会话标记为“已下线”或“待验证”的状态。对于超出当前服务器最大连接池限制的情况，服务器可以最近最少使用的原则（LRU）对超限连接进行淘汰。由于在此实施例中，每个会话同时只能保持一个消息推送连接，因此当属于同一会话的另一新消息推送连接重复到达时，已有的老连接将被强制淘汰。

此外，p2pcdn服务器集群还需要对资源进行管理。与管理数据块和会话类似，p2pcdn也可以通过BYPSS等任意分布式协调算法和/或服务来为每个资源选择一个属主服务器。然后由选举成功的属主服务器负责该资源的管理工作。与前文所述的数据块管理类似，对资源的管理主要涉及以资源为单位的实时状态追踪、资源级别的分裂/合并、调度、协调等操作，以及对该资源麾下各数据块的状态追踪和统筹分析管理等职能。

对于支持用户注册和登陆功能的应用来说，p2pcdn服务器集群还应支持用户管理功能。每个用户可以同时拥有多个会话。与会话管理类似，p2pcdn也可以通过BYPSS等任意分布式协调算法和/或服务来为每个用户选择一个属主服务器。

优选地，在启用了用户管理的场景中，也可以不再为每个会话单独选主，而是仅针对用户进行选主，然后由会话所属用户的属主服务器来统一管理所有属于该用户的会话（显而易见，这种方式可以更高效地实现某些用户相关操作，例如：向指定用户麾下所有会话统一推送某条消息之类的场景，等等）。与前文所述的会话管理类似，用户管理主要涉及用户级别的各项实时状态追踪、统计、请求处理和协调等操作，也可以包含对该用户麾下各会话的状态追踪和统筹分析管理等工作。

除上述业务逻辑以外，p2pcdn服务器集群还需要实现诸如：配置管理、HAC（故障检测、故障转移（failover）、故障恢复（failback），可通过BYPSS等分布式协调组件，或其它任意方式实现）、集群内消息通信（服务器节点间消息通信，可通过诸如BYPSS之类带消息分发功能的分布式协调服务、BYDMQ之类高性能分布式消息中间件，或ZeroMQ等点到点直连协议等任意方法实现）等各项常见通用功能。

3.3. p2p客户端

p2p客户端（p2p端点，peer）可以浏览器页面，或移动、平板、桌面App应用等任意形式存在。正如前文所述，本发明中不存在“超级节点”等概念。所有p2p端点在身份上都是完全对等的：即是内容的消费方（受体），又作为其已消费（成功下载）内容的供给方（供体）而存在。即使偶有因网络连通性限制等前文所述的特例存在，在本质上也不影响上述对等关系。

取消了“超级节点”、“发布节点”等“少数菁英节点”之概念，在本发明中，每个p2p节点在接受他人帮助的同时，都尽可能贡献出自己的力量，同时向他人分享自己的资源（数据块）。

p2p客户端主要完成以下工作：

【初始化】：对于新加载的页面等情形来说，初始化工作主要包含创建新会话并获取对应SID等动作。对于正在刷新内容的单页应用（SPA）或App来说，初始化动作主要为清空（停止共享）所有属于当前会话的老内容（数据块）等。初始化工作可通过“初始化”API来完成。

优选地，在完成初始化动作的同时，还可以将该客户端与服务器之间的通信（以任意方式）绑定到新会话的属主服务器节点（会话粘滞），这可以在后续的通信中极大地避免消息转发，显著提升通信效率。

例如：某用户初次在浏览器打开一个名为“中国船长”的视频播放页面时，该页面可通过调用“初始化”API来获取新SID，并同时以浏览器Cookie等方式将由该页面发起的所有相关请求均绑定（粘滞）到此新会话的属主服务器节点上。

与此同时，假如该页面是个单页应用，即：在跳转到播放列表或页面内的相关推荐视频时无需刷新（重新加载）当前页面或跳转到其它页面。则在本页面内完成内容切换（例如：切换到名为“中国列车长”的新视频）后，应重新调用“初始化”API来清空（停止共享）所有属于当前会话的老内容（即：清空所有属于“中国船长”的数据块）。并重新开始获取和分享新资源“中国列车长”的相关数据块。

请参考：“【供体端点表】”、“【会话表】”、“【Init API】”等相关小节。

【接收消息推送】：成功初始化后，p2p客户端与p2pcdn服务器集群间，应保持至少一条消息推送连接。用以接收来自服务器的推送消息。优选地，消息推送连接还可以兼为心跳连接，周期性地向服务器发送心跳信号。

例如：上例中的浏览器播放页面，在初始化成功后即可以HTTP长轮询的方式调用p2pcdn服务器上的“接收消息（消息推送）”API，建立消息接收连接。优选地，该客户端可通过在每次API返回（无论是因为接收到服务器打包推送的消息还是超时）后，立即发起下一次请求来使此消息接收连接兼任保活心跳连接的职能——服务器在指定的超时时间内未收到来自客户端的“接收消息（消息推送）”API请求即可认为该会话已下线。

请参考：“【推送消息队列】”、“【消息推送连接池】”、“【WaitMsg API】”等相关小节。

【资源请求】：客户端可通过“组网匹配（请求数据块）”API，或从传统CDN等处直接下载来取得需要的资源。

正如前文所述，当一个p2p端点作为受体，向p2pcdn服务器发起了“组网匹配（请求数据块）”API调用后。服务器将根据预定的规则，为该客户端匹配任意数量的p2p端点作为其供体，并帮助它们建立起相应的p2p子网。在此过程中，还可能需要用到接收消息，以及P2P连接发起和应答等其它API。

优选地，正如前文所述，由于在绝大部分应用场景下，所有客户端均以递增的顺序逐个请求和消费数据块，并以由小到大的顺序将其从缓冲区中淘汰。因此在实际使用场景中，用户并不需要对每个数据块分别调用一次“组网匹配（请求数据块）”API。

相反地，由于上述规律普遍成立，所以用户通常只需要使用此API找到一组能够为其提供第一个（通常序号最小）其所需数据块的对端（供体），并成功建立p2p子网。即有很大概率可以成功地向它们继续请求后续的数据块了，我们称上述模式为“惯性滑行”。

而通常只有在用户拖动播放进度条（进行视频跳转）、切换音轨等场景下，这种“滑行”才会失效。此时可再次调用此方法来开始新一次的“惯性滑行”过程。换句话说，p2pcdn中的资源（数据块）分享，就是由一次接一次的“惯性滑行”过程组成的。

请参考：“【组网匹配】”、“【AcquireChunk API】”等相关小节。

【资源分享】：客户端可通过“分享数据块”，以及“取消数据块分享”等API向其属主节点声明该会话当前的可分享数据块相关信息。在当前会话所属的服务器节点（属主）收到相应请求后，可以视具体情况将本次变更（共享或取消共享）分别通知到相关资源和数据块的属主服务器节点。并更新与之对应的各项实时统计和状态信息，

例如：服务器收到请求后，可更新其位于属主节点会话表中的数据块、分享频率等信息，以及更新其位于对应属主节点数据块供体端点表中的对应状态信息等等。

请参考：“【供体端点表】”、“【会话表】”、“【OfferChunk API】”、“【RevokeChunkAPI】”等相关小节。

【P2P连接管理】：客户端可通过“P2P连接发起（Offer）”、“P2P连接回应（Answer）”等API来请求p2pcdn服务器帮助建立p2p子网。优选地，上述P2P连接管理相关API也可被优化到诸如（包括但不限於）“组网匹配（请求数据块）”、“分享数据块”、“初始化”、“接收消息（消息推送）”等API中，以达到减少API调用次数，提到通信效率、简化API数量等目的。

例如：在上例的浏览器页面中，页面可通过WebRTC中的Data Channel标准组件，在p2pcdn服务器的帮助下建立起p2p子网。

请参考：“【p2pOffer API】”、“【p2pAnswer API】”等相关小节。

缓冲区管理：除上述主要功能外，p2p客户端还应当包含诸如缓冲区管理、鉴权和授权、音视频播放、图片展示、文件编辑和保存等与具体业务逻辑相关的基本功能。

例如：在上例的视频播放浏览器页面中，受体端点通过p2p子网或传统CDN渠道成功取得指定数据块后，可以将该数据块存放于页面内维护的LRU缓存中，并将该数据块关联到页面中的视频播放器。与此同时，页面立即或周期性（如：每秒）地调用“分享数据块”API，将包含该数据块在内的，当前页面缓存中新增的数据块分享给其它p2p客户端。

对应地，当LRU缓冲区的数据块被淘汰后，页面应当立即或周期性（如：每秒）地调用“取消数据块分享”API，取消分享该数据块，以及该周期内的其它已淘汰数据块。

请参考：“【组网匹配】”、“【AcquireChunk API】”、“【OfferChunk API】”、“【RevokeChunk API】”等相关小节。

综上所述，本发明公开的p2pcdn系统由后端支持服务、p2pcdn服务器集群，以及p2p客户端三层结构组成。正如前文所述，其中的后端支持服务可以只在逻辑上存在。

4. API原语

优选地，p2pcdn服务器集群可对外提供如下API原语：初始化（Init）、接收消息（消息推送，WaitMsg）、组网匹配（请求数据块，AcquireChunk）、分享数据块（OfferChunk）、取消数据块分享（RevokeChunk）、P2P连接发起（p2pOffer）、P2P连接回应（p2pAnswer）。以下逐一说明：

【Init API】（初始化）：初始化当前会话。正如前文所述，此API可用于生成新会话或清空现有会话正在共享的所有资源（数据块）。

若客户端调用此API时未指定会话，则服务器将为此请求创建一个新会话。

若客户端调用此API时已处于一个有效的会话中（例如：指定了一个有效的SID），则此方法清空属于该会话的所有资源和数据块。正如前文所述，这是为那些需要切换场景的单页应用（SPA）或App客户端准备的。例如：对于一个用于播放视频列表的SPA来说，当用户从列表中的一个视频跳转到另一个视频时，页面可通过重新调用此方法来确保立即停止分享所有与上一个视频相关的数据块。

若调用此API时指定了一个无效的会话，则p2pcdn服务器可返回错误，或为该请求创建一个新会话。

若需要，p2pcdn系统可根据实际情况通过使用此API或另外添加其它API来实现用户的鉴权、授权、登陆、登出等各项通用基本操作。由于这些通用基础操作与本发明所述的技术方案并直接关系，因此本文不再赘述。

请参考：“【初始化】”等相关段落。

【WaitMsg API】（接收消息-消息推送）：开始接收由p2pcdn服务器推送的消息。正如前文所述，p2p客户端调用该请求接收来自p2pcdn服务器的推送消息。客户端可以长连接、短连接、实时或轮询等各种方式以及任意通信协议来调用此API。服务器将通过此API向客户端推送消息。

例如，在一个实施例中：服务器可以通过此API向客户端推送如下消息：

【资源请求“Res.Req”消息】：该消息在受体调用“组网匹配（请求数据块，AcquireChunk）”API完成组网匹配后，由服务器通过此API向与之匹配的各个供体端点推送，消息中可包含诸如：受体SID、请求资源名、请求数据块，以及预估数据块读入方向及范围等任意相关字段。

【P2P建链协商邀请“P2P.Offer”消息】：在收到“Res.Req”消息的供体端点通过调用“P2P连接发起（p2pOffer）”API同意共享数据块后，p2pcdn服务器即可通过此API将向相应的受体推送本消息。消息中可包含诸如：该供体的SID、该供体提供的资源名、该供体当前缓冲区状况，以及由该供体生成的，用于创建p2p连接的协商握手邀请（例如：SDP Offer、ICE Candidates）报文等任意相关字段。

【P2P建链协商应答“P2P.Answer”消息】：在受体收到上述来自供体的“P2P.Offer”消息后，若决定接受该供体所分享（提供）的数据块，并为此调用了“P2P连接回应（p2pAnswer）”API，则p2pcdn服务器会向对应的供体推送此消息。消息中可包含诸如：该受体的SID、受体请求资源名，以及由该受体生成的，用于创建p2p连接的协商握手应答（例如：SDP Asnwer、ICE Candidates）报文等任意相关字段。

请参考：“【推送消息队列】”、“【消息推送连接池】”、“【接收消息推送】”等相关段落。

【AcquireChunk API】（组网匹配-请求数据块）：受体调用此方法，以获取资源为目的，请求针对指定的资源下的数据块进行p2p组网匹配。即：请求使用p2p分享的方式获取指定资源中的指定数据块。

正如前文所述，此API的目的是为当前受体（调用方）匹配能够分享（提供）指定数据块的供体端点。并帮助它们以分享这些数据块为目的，来组建相应的p2p子网。

优选地，在完成组网匹配后，p2pcdn服务器集群向本次成功匹配的各个受体端点逐一或批量推送资源请求“Res.Req”消息。

优选地，此API不仅可支持对单一资源下的单一数据块进行请求，也可支持对单一资源下的多个数据块，或者对多个资源下的多个数据块等批量处理模式。

优选地，服务器可通过此API或WaitMsg等其它API向客户端返回其请求数据块之相关信息。例如（包括但不限於）：该数据块的校验和、数字签名、长度、宽度、起始位置、播放时长等各种相关元信息。

请参考：“【组网匹配】”、“【p2p子网】”、“【资源请求】”、“【资源请求"Res.Req"消息】”等相关段落。

【OfferChunk API】（分享数据块）：为当前会话新增可共享给他人的数据块。正如前文所述，此方法可以单一或批量的形式向p2pcdn服务器声明当前端点有那些已有和/或新增的数据块可以被分享。

本方法支持以实时或周期性的方式进行调用。优选地，建议周期性（例如：每秒一次）地调用此方法，来批量地更新当前客户端可共享的资源（数据块）增量。

请参考：“【供体端点表】”、“【资源及数据块列表】”、“【资源分享】”等相关段落。

【RevokeChunk API】（取消数据块分享）：从当前会话移除指定的可共享（可提供给其它端点的）数据块。正如前文所述，此方法可以单一或批量的形式向p2pcdn服务器取消当前端点中已无法被继续分享（无法继续提供）的数据块。

本方法支持以实时或周期性的方式进行调用。优选地，建议周期性（例如：每秒一次）地调用此方法，来批量地移除当前客户端中已不可共享的资源增量。

请参考：“【供体端点表】”、“【资源及数据块列表】”、“【资源分享】”等相关段落。

【p2pOffer API】（P2P连接发起）：向指定的会话发起P2P连接请求。正如前文所述，若调用成功，服务器将向指定的客户端推送一条“P2P.Offer”消息。

优选地，此方法可以单一或批量的形式发起请求。在批量方式中，此方法可以通过一次调用针对多个会话，向不同资源各自发起不同连接请求。

也可以简单地将此API理解为：向请求中指定的p2p客户端端点推送指定的P2P连接建立请求消息。

请参考：“【P2P建链协商邀请"P2P.Offer"消息】”等相关段落。

【p2pAnswer API】（P2P连接回应）：向指定的会话发送P2P连接回应。正如前文所述，若调用成功，服务器将向指定的客户端推送一条“P2P.Asnwer”消息。

优选地，此方法可以单一或批量的形式发起请求。在批量方式中，此方法可以通过一次调用针对多个会话，向不同资源各自返回不同连接应答请求。

也可以简单地将此API理解为：向请求中指定的p2p客户端端点推送指定的P2P连接建立应答消息。

请参考：“【P2P建链协商应答"P2P.Answer"消息】”等相关段落。

需要说明的是，本发明并未限制上述API的名称，在实际使用场景中，无论其名称为何，或如何对上述功能进行拆分和/或组合。只要最终是实现了上述功能原语的API接口，均应被认为是在本发明覆盖范围内。

5. 典型工作流程

为了更清楚地描述其工作流程，作为示例，一个p2p客户端端点（Peer）的典型的p2pcdn应用流程分为如下几个步骤：

1. 初始化：使用“Init”API获取或重置会话，并通过“WaitMsg”API建立消息推送连接。

2. 针对当前页面上的各个资源，使用“AcquireChunk”等API（通过p2p方式）请求获得来自其它p2p客户端端点的数据块分享，和/或通过普通CDN、和/或源站点、和/或（包括但不限于）“百度金矿”、“迅雷赚钱宝 / 迅雷玩客云”、“优酷路由宝”等现有“P2P CDN”等在内的一切传统分发渠道来获取这些数据块。

3. 随时通过“WaitMsg”API接收由服务器推送的“P2P.Offer”消息，并调用“p2pAnswer”API来建立p2p子网。成功建立子网后即可直接与该子网中的各供体端点进行p2p直连通信，接收由这些供体端点发送（共享）的数据块内容。

4. 将已成功获取到的数据块加入本地缓存，实时或定期（批量）通过“OfferChunk”API发布这些共享。并通过“p2pOffer”等API组建p2p子网，以便将它们共享给其它p2p端点（Peers）。

5. 实时或定期通过“RevokeChunk”API将已无法继续共享（例如：已从缓存中移除）的数据块（批量）通知p2pcdn服务器，以取消对这些数据块的共享。

6. 随时通过“WaitMsg”API接收由服务器推送的“Res.Req”消息，并通过“p2pOffer”API尝试与对应的受体建立p2p连接。p2p连接成功后，当前端点即可作为供体，开始向受体分享其请求的数据块（参考上述第3步）。

7. [可选] 在切换资源、离开当前页面或退出App前再次以当前SID调用“Init”API，这样可保证及时清空（取消共享）与当前会话相关的所有数据块，而不必等到该会话超时。

同样作为示例，一个p2pcdn服务器集群（服务器侧逻辑）的典型工作流程为：

1. 等待并接受下一个请求（该请求通常来自网络，并由p2p客户端发起）：

2. 如果该请求是一个“Init”API请求，若该API并不在一个有效的会话上下文内，则通过选举成为或找到此会话的属主，并在其属主节点的会话表中新建针对该会话的条目。

相反，若请求正处于一个有效的会话上下文内（例如：请求中带有有效的SID），则在其属主节点的会话表中查询该会话对应的条目。并逐一或批量通知该条目中已记录的，所有该会话当前正在共享的数据块的属主节点。然后分别从与这些数据块对应的供体端点表中淘汰此会话。

3. 否则，如果该请求是一个“WaitMsg”API请求，则按需通过此调用（例如通过发送数据、返回响应等方式）来向对应的会话推送消息。

4. 否则，如果该请求是一个“AcquireChunk”API请求，则以任意给定规则为该会话（请求方，受体）匹配到任意多个符合条件的供应方（供体）。并通过“WaitMsg”API向这些供体端点推送“Res.Req”消息。

5. 否则，如果该请求是一个“OfferChunk”API请求，则在当前会话的属主节点的会话表中更新和跟踪该会话的数据块分享状态。若本次请求确实声明了新分享的数据块，则尝试选举成为这些新增数据块的属主节点或通知其已存在的属主，并在其对应的供体端点表中分别新增当前会话。

反之，若请求中未包含新的数据块（即：所有本次请求中声明的数据块均已被当前会话分享），则忽略本次请求。

6. 否则，如果该请求是一个“RevokeChunk”API请求，则在当前会话的属主节点会话表中核查、更新和跟踪该会话的数据块分享状态。若本次请求确实撤销了正在被当前会话分享的数据块，则通知这些新撤销数据块的属主节点，在其对应的供体端点表中淘汰当前会话。

反之，若请求中未包含已分享的数据块（即：所有本次请求中声明的数据块均未被当前会话分享），则忽略本次请求。

7. 否则，如果该请求是一个“p2pOffer”API请求，则从请求参数中取出该请求针对的受体SID，以及资源名等信息。并通过与该受体SID所对应的推送消息队列（通过查询该受体会话属主的会话表条目获得）等组件以及其对应的“WaitMsg”API等调用，向该受体推送此P2P连接建立请求。

8. 否则，如果该请求是一个“p2pAnswer”API请求，则从请求参数中取出该请求针对的供体SID，以及资源名等信息。并通过与该供体SID所对应的推送消息队列（通过查询该供体会话属主的会话表条目获得）等组件以及其对应的“WaitMsg”API等调用，向该供体推送此P2P连接建立应答。

9. 跳转回第1步（继续处理下一个请求）。

注意：以上过程省略了错误处理，以及鉴权、授权、注册、登出、以及日志记录等与本技术方案没有直接关系的通用基础功能。是否加入这些众所周知的基本通用功能并不会影响本专利的覆盖范围。

此外，以上服务器集群逻辑还省略了服务器节点之间的通信。例如，在处理“OfferChunk”API请求时，当前会话的属主和待处理数据块的属主可能不是同一台服务器节点。此时可能需要通过BYPSS、BYDMQ等消息中间件（或以直接通信等方法）在p2pcdn服务器集群中的不同服务器节点间进行通信，来转发和/或传达这些命令和请求。

这些情形都以“在XX的属主节点上执行YY”，或其它类似的形式简化了。这是因为：首先，上述通过消息中间件在服务器集群内的节点间进行通信，是广为人知的基础功能和技术常识，因此无需专门赘述。其次，在一个分布式集群中，选举的结果常常存在很大的不确定性。任意选定两个会话或两个数据块，它们是否正巧属于同一个属主节点本质上是个概率问题（既有可能同属一个属主节点，也有可能分属不同属主节点）。甚至在极端情况下，若服务器集群中只剩下一个在线的服务器节点时，那么此时包括用户、会话、资源、数据块等在内的任何在线对象的属主将均为此唯一的服务器节点（因为此时集群中只剩下这一台服务器了）。

因此上述说明没有特别强调不同对象的属主是否为同一个服务器节点，以及不同服务器之间应当如何通信：这些问题均属于与本发明无直接关系的问题，亦并不影响本发明的覆盖范围。

5.1 用例：“中国船长”播放页

下面以视频“中国船长”的浏览器（Web）播放页面（p2p客户端端点）为例，来描述典型的一次典型的p2pcdn加速流程。假设老张打开“中国船长”的视频播放页：“https://www.YouMustKu.com/2020/中国船长.html”。那么在该播放页中，可能会执行如下步骤：

1. 在该页面初始化时，不带SID参数调用“Init”API，并将服务器返回的新会话SID保存到当前页面的全局变量中，同时在以后每次请求中均携带该SID字段。以下我们假设老张本次获得的SID为“A-000”。

2. 调用“WaitMsg”API来建立消息推送长连接通道。

3. 假设老张请求了两个资源：视频资源“2020/中国船长.1080p.h264”，以及音轨资源“2020/中国船长.普通话.228k.aac”。那么此时老张为上述两个资源分别向p2pcdn服务器发起“AcquireChunk”API调用。

4. p2pcdn服务器通过ISP等规则为老张成功匹配到48个供体（供体可理解为老王、老李、老赵等与老张同时观看相同视频的其它人）。以下假设他们的SID分别为B-001 ~B-048。这48个供体将通过各自的“WaitMsg”API，各自收到老张（A-000）发来的资源获取（p2p组网）请求。

5. 假设其中有40个供体（B-001 ~ B-040）同意分享其资源（数据块）给A-000。那么这40个供体则分别调用“p2pOffer”API向A-000发起p2p连接offer（其中SDP Offer的具体内容通常由浏览器WebRTC组件中的createOffer等方法产生）和NAT穿透（ICEConditions）等信息。

6. 老张（A-000）通过其发起的“WaitMsg”API成功接收到了上述40个p2p连接offer，并调用“p2pAnswer”API，针对收到的每个p2p连接offer，返回对应的p2p连接answer（其中SDP Answer的具体内容通常由浏览器WebRTC组件中的createAnswer等方法产生）和NAT穿透（ICE Conditions）等信息。

7. 对端供体（B-001 ~ B-040）通过各自的“WaitMsg”API分别收到由老张发来的p2p连接answer后，即可由WebRTC等组件自动通过STUN等形式与A-000建立p2p直连。以下假设其中有36个供体（B-001 ~ B-036）与受体（A-000）成功地建立了p2p直连连接。

8. p2p直连建立成功后（形成p2p子网），A-000（老张）即可与（B-001 ~ B-036）相互分享和交换相应资源中的数据块。

9. 老张每秒检查一次过去一秒内是否有新获取到的可提供（共享）数据块。若有则调用“OfferChunk”API，将这些可供分享的新数据块批量告知p2pcdn服务器集群。

类似地，老张还每秒检查一次过去一秒内是否有已经从缓冲区淘汰掉的旧数据块。若有则调用“RevokeChunk”API，将这些其已无法分享的数据块批量告知p2pcdn服务器集群。

若由于用户的请求（例如：老张将音轨从普通话切换到英语）等原因，导致指定资源被完全移出缓冲区。则他应通过调用“RevokeChunk”API来停止继续分享所有与该资源相关的数据块。

10.在退出当前页面或在SPA页面内加载新内容（如：“中国列车长”）前，应使用绑定了当前SID的“Init”API来清空当前页面中的所有可共享资源。

以上就是一个经典的“视频播放”用例流程。需要注意的是：

正如前文所述，由于在绝大部分应用场景下，所有客户端均以递增的顺序逐个请求数据块，并以由小到大的顺序将其从缓冲区中淘汰。因此在实际使用场景中，用户并不需要对每个数据块分别调用一次“AcquireChunk”API。

相反地，由于上述规律普遍成立，所以用户通常只需要在一开始使用“AcquireChunk”API找到一组能够为其提供第一个（序号最小，比如0号数据块）所需数据块的对端（供体），并以此建立起一个p2p网络，即有很大概率可以成功通过该p2p子网继续获得后续（比如第1号、第2号、第3号……等等）的数据块了——我们称这种模式为“惯性滑行”。

而通常只有在用户拖动播放进度条（进行视频跳转）、切换音轨等特殊场景下，这种“滑行”才会失效。此时可再次调用此方法来开始新一次的“惯性滑行”过程。

应当为一个页面下的不同资源分别建立不同的p2p网络群组。例如上例中的视频“2020/中国船长.1080p.h264”，以及音轨“2020/中国船长.普通话.228k.aac”应该分别拥有属于自己的LRU缓冲区，以及p2p子网等组件：每个资源各自存储（缓存）、分享和管理属于其自己的数据块集合，并各自连接到专用于分享该资源的任意多个p2p子网。

与此同时，多个p2p子网之间可以相互交叉和融合。例如：对于会话A-000来说，B-001 ~ B-036的身份都是其所需资源“2020/中国船长.1080p.h264”的供体，但与此同时，对B-001 ~ B-036等端点来说，A-000对它们来说也是该资源和/或其它资源的供体。

当这个网络越加复杂（比如：A-001连接了B-001 ~ B-018等端点、A-002连接了B-019 ~ B-036等端点）时，情况也是类似（此时，对B-001 ~ B-018等端点来说，A-000和A-001也均可以是它们的供体；类似地，对B-019 ~ B-036等端点来说，A-000和A-002也均可以是供体）。

应当为p2pcdn资源获取请求设置超时：一旦在指定的时间内，无法通过p2p网络获取到指定的数据块，则触发超时。此时可fallback回从普通CDN线路获取资源的传统方案。当然，通过普通CDN等传统方法获取到的资源也应当使用“OfferChunk”API分享到p2pcdn网络。

为了加快视频、音频等媒体的播放速度，可以考虑在用户点击播放按钮前，预加载部分数据；或考虑直接通过普通CDN等传统手段来加载每次播放开始时的前几秒钟数据；或先使用一个非常短（如：300ms）的超时时长来尝试从p2pcdn获取开播数据，若超时则fallback回传统CDN方式；或者双管齐下，同时通过传统CDN和p2pcdn来尝试获取这些数据等等的方式来优化用户体验。

由于播放时一般会对正在播放的媒体进行60~120秒的提前缓冲（预读）。因此在使用上述方式对视频开始的前几秒内容的加载进行了优化后，后面的数据块通常就会有更充裕的时间来慢慢进行缓冲加载，因此此时其加载的超时时长就可以被适当延长了。

例如：“中国船长”的视频播放页规定每当检测到其缓存剩余不足90s时，就重新进行预读，将其补足120s。此时只要在未来90s内获取到其所需的数据块，就不会造成播放卡顿等问题。

6. 小节

综上所述，本发明通过数据分块并为每块在线的数据分别选举属主服务器节点，然后由属主节点各自对其麾下的每个数据块进行实时状态跟踪、统计、分析和组网匹配。以及配合“惯性滑行”等技术，最终实现了一套可靠、高效、灵活，一致性强，可用性高的高性能、高并发海量数据p2pcdn系统。该系统解决了现有传统CDN分发渠道流量费用高、服务能力有限（高峰时段或热点资源卡顿）等现有问题。

与此同时，与BT、电驴等传统的p2p文件分享方案相比，本发明也至少具备以下明显区别和优势：

面向领域不同：BT、电驴等传统p2p文件分享方案主要面向文件等静态资源共享，而本发明主要针对音视频直播及点播、视频会议、网络研讨会、网络游戏等实时内容分享的场景。

支持功能不同：BT、电驴等传统p2p文件分享方案主要针对已能够完整访问的静态资源（在开始分享前，必须可以事先完整访问待分享文件的全部内容，然后以此为基础来制作“种子”等）。而本发明则无需上述步骤，可对音视频直播等无法预先获取完整数据的实时流媒体，或多人线上会议、网络游戏等其它类似的实时通信场景进行实时内容分发。

Web（浏览器）和App的集成和嵌入能力：BT、电驴等传统的p2p文件分享方案需要安装、部署专用的App软件和/或硬件设备后才可使用。而本发明可直接嵌入已有Web页面或应用中，直接为应用现有的业务逻辑进行加速。例如：直接嵌入某视频网站“优更酷”的网站页面以及其App中，为其现有的视频点播和直播服务提供p2pcdn服务，实现加速减费的有益效果。

完全对等，没有超级节点：由于本发明独创的“数据分块选主管理”算法，使得p2pcdn服务器集群可以有效地同时跟踪、统计和分析海量数据块，同时为海量在线用户（会话）同时提供针对海量数据块的资源匹配和p2p组网服务。因此，本发明不需要传统p2p文件分享方案中的那些地位特殊的“超级节点”（Super Peer）、“发布节点”（Publisher Peer）或是“种子节点”（Seed Peer）等特殊端点。在本发明中所有p2p端点地位完全平等（相互之间互不统属），均统一接受p2pcdn服务器集群的调度和指挥，也都在享受其它端点所贡献（共享）之资源（数据块）的同时，也为别的端点提供（共享）目前自己缓冲区中的可用资源（数据块）。

针对数据和端点均不稳定的海量超高并发场景：BT、电驴等传统p2p文件分享方案主要针对供体及受体节点相对稳定的环境。而本发明独创的p2pcdn服务器集群“数据分块选主管理”等算法，则可以更好地对随时都在剧烈变化的海量端点和缓存数据块集合做分布式的实时路由调度。

例如：用户可能随时关闭网页、大幅拖动播放进度条进行跳转，或者切换视频的分辨率（比如从720p切换到1080p）或音轨（比如从普通话切换到英文），这些行为很可能都会导致该用户（会话）之前缓存的数据块集合在上述动作发起的瞬间被完全丢弃。或者即使用户只是在正常观看视频，当该视频被播放到1小时的位置时，其第1分钟的缓存通常也早就被淘汰从而无法被分享了。上述情形再加上对海量资源和数据块的高性能实时跟踪、协调和匹配、以及处理数亿人同时在线观看直播这种超高并发场景等挑战。这都是BT、电驴等传统p2p文件分享方案无法解决的问题。

而本发明公开的p2pcdn服务器集群“数据分块选主管理”等算法很好地解决了上述问题。可以在上述数据块和端点可用性均不稳定的前提下，很好地应对海量数据、超高并发的应用场景。

综上所述，本发明通过有机地组合上述各项技术优势，克服了传统CDN以及传统p2p分享等技术方案中的各项缺点，与业界中的各项现有方案相比，具备明显的技术区别和有益效果。

Claims (10)

1.一种基于分布式选举的端到端内容分发网络系统，其特征在于：包括p2pcdn服务器集群；所述p2pcdn服务器集群中可包含任意数量的服务器节点；所述p2pcdn服务器集群将每个待分发或共享的资源切分为数据块，并通过选举的方式在所述p2pcdn服务器集群中，为所述数据块分别选定各自的属主服务器节点，并以所述数据块为单位，对资源进行端到端的分发或共享。

2.根据权利要求1所述的一种基于分布式选举的端到端内容分发网络系统，其特征在于：在每个所述p2pcdn服务器节点内部，为每个属于该服务器节点的所述数据块分别选举出对应的属主进程、属主线程或属主协程。

3.根据权利要求1或权利要求2所述的一种基于分布式选举的端到端内容分发网络系统，其特征在于：所述数据块的属主节点，或其属主进程、属主线程或属主协程负责对该数据块的各项状态进行追踪、匹配和协调。

4.一种基于分布式选举的端到端内容分发网络系统，其特征在于：包括p2pcdn服务器集群和p2p客户端网络；所述p2pcdn服务器集群中可包含任意数量的服务器节点；所述p2p客户端网络中包含了任意数量的，需要使用所述端到端内容分发网络的p2p客户端端点，每个p2p客户端端点均可按需与所述p2p服务器集群建立连接；

所述p2pcdn服务器集群对外提供如下API原语：初始化（Init）、接收消息（消息推送，WaitMsg）、组网匹配（请求数据块，AcquireChunk）、分享数据块（OfferChunk）、取消数据块分享（RevokeChunk）。

5.根据权利要求4所述的一种基于分布式选举的端到端内容分发网络系统，其特征在于：所述p2pcdn服务器集群对外提还供如下API原语：P2P连接发起（p2pOffer）、P2P连接回应（p2pAnswer）。

6.一种基于分布式选举的端到端内容分发网络系统的分发方法，其特征在于：所述p2pcdn服务器集群通过以下步骤处理来自p2p客户端端点的请求：

步骤1、等待并接受由p2p客户端发来的下一个请求；

步骤2、如果该请求是一个“Init”API请求，且该API请求并不在一个有效的会话上下文内，则为其创建新会话，并通过选举成为此新会话的属主；若该API请求正处于一个有效的会话内，则在其属主节点中查询该会话的相关信息，并通知所有该会话当前正在对外共享的数据块的属主节点，从其对应数据块的相关记录中淘汰该会话；

步骤3、如果该请求是一个“WaitMsg”API请求，则按需通过此调用向对应的会话推送消息；

步骤4、如果该请求是一个“AcquireChunk”API请求，则以任意给定规则为该会话（受体）匹配到任意个符合条件的供应方（供体），并向这些供体端点推送对应的资源请求“Res.Req”消息；

步骤5、如果该请求是一个“OfferChunk”API请求，则在当前会话的属主节点上更新和跟踪该会话的数据块分享状态，并尝试选举成为这些数据块的属主节点或通知其已存在的属主节点，将此新增的供体端点信息新增或更新到这些数据块的相关记录内；

步骤6、如果该请求是一个“RevokeChunk”API请求，则在当前会话的属主节点上更新和跟踪该会话的数据块分享状态，并通知这些数据块的属主节点，将当前会话从这些数据块的相应供体记录中删除或淘汰；

步骤7、跳转回第1步（继续处理下一个请求）。

7.根据权利要求6所述的基于分布式选举的端到端内容分发网络系统的分发方法，其特征在于：所述p2p客户端通过以下步骤访问所述p2pcdn服务器集群：

步骤1、初始化：使用“Init”API获取或重置会话，并通过“WaitMsg”API建立消息推送连接；

步骤2、针对当前会话上的资源，使用"AcquireChunk"API请求获取来自其它p2p客户端端点的数据块分享，和/或通过传统分发渠道分别获取其数据块；

步骤3、当接收到由p2pcdn服务器推送的p2p连接请求消息时，尝试与指定的受体端点建立p2p连接，成功建立p2p子网后即可直接与该子网中的各供体端点通信，接收由其发送（共享）的数据块内容；

步骤4、将已成功获取到的数据块加入本地缓存，并实时或定期通过“OfferChunk”API发布这些共享；

步骤5、实时或定期通过“RevokeChunk”API将已无法继续共享的数据块通知p2pcdn服务器，以取消对这些数据块的共享。

8.根据权利要求6所述的基于分布式选举的端到端内容分发网络系统的分发方法，其特征在于： 在所述权利要求6之后还包括以下步骤，

步骤7、如果该请求是一个“p2pOffer”API请求，则向请求中指定的p2p客户端端点推送指定的P2P连接建立请求消息；

步骤8、如果该请求是一个“p2pAnswer”API请求，则向请求中指定的p2p客户端端点推送指定的P2P连接建立应答消息；

步骤9、跳转回第1步（继续处理下一个请求）。

9.根据权利要求6所述的基于分布式选举的端到端内容分发网络系统的分发方法，其特征在于：所述p2p客户端通过以下步骤访问所述p2pcdn服务器集群：

步骤1、初始化：使用“Init”API获取或重置会话，并通过“WaitMsg”API建立消息推送连接；

步骤2、针对当前会话上的资源，使用"AcquireChunk"API请求获取来自其它p2p客户端端点的数据块分享，和/或通过传统分发渠道分别获取其数据块；

步骤3、当接收到由p2pcdn服务器推送的p2p连接请求“P2P.Offer”消息时，调用“p2pAnswer”API来建立p2p子网，成功建立子网后即可直接与该子网中的各供体端点通信，接收由其发送（共享）的数据块内容；

步骤4、将已成功获取到的数据块加入本地缓存，并实时或定期通过“OfferChunk”API发布这些共享，并通过“p2pOffer”API组建p2p子网，以便将它们共享给其它p2p客户端端点；

步骤5、实时或定期通过“RevokeChunk”API将已无法继续共享的数据块通知p2pcdn服务器，以取消对这些数据块的共享；

步骤6、当接收到由p2pcdn服务器推送的资源请求“Res.Req”消息时，通过“p2pOffer”API尝试与对应的受体端点建立p2p连接，在p2p连接成功后，当前p2p客户端端点（供体）即可尝试向受体端点分享其请求的数据块。

10.根据权利要求7或9所述的基于分布式选举的端到端内容分发网络系统的分发方法，其特征在于：还可以提供“惯性滑行”优化，在每次成功建立p2p子网后，所述受体p2p客户端点尽量沿用所述已成功建立的p2p子网继续获取其所需的其它临近数据块。

Images