技术领域
[0001] 本
发明涉及网络通信领域，尤其一种众包的内容分发网络的系统、方法与设备。
背景技术
[0002] 互联网（Internet）商业化运营中，由于多数服务均采用C/S（客户端/
服务器）模式，少数的中心服务器一方面由于自身的带宽、存储容量有限，在服务成千上万的用户特别是有大量用户
请求瞬间拥入时，很容易成为整个网络服务的
瓶颈；另一方面由于距离用户的地理距离、网络拓扑距离可能较远，且可能跨越多个ISP（Internet Service Provider，互联网服务提供商或运营商），传输路径中很容易遭受网络拥塞和抖动，以及运营商的限速等。
[0003] 在上述情况下，用户得不到较好的QoE（Quality of Experience，服务体验
质量）。
[0004] 20世纪90年代后期，各大Web
站点的hot spot（热点）和flash crowd（突发
访问）的现象越来越突出，造成的瓶颈问题不仅可以击垮一个
网站，甚至会带来多米诺效应－站点附近的网络都将受灾。
[0005] 为了解决前述各现象越来越突出，造成Web内容传送越来越慢、服务越来越不可靠的问题，
万维网（World Wide Web）之父Tim Berners-Lee在MIT（麻省理工学院）内部发起了一个旨在改进互联网内容传送方式的竞赛，参与此竞赛的研究生Daniel Lewin和其导师Tom Leighton基于参与此竞赛的成果在不久之后创办了后来世界上最大的CDN（Content Delivery Network，内容分发网络）公司－Akamai。
[0006] CDN的基本思路即是在网络中，跨地域、跨ISP地部署一系列服务器，并且以特定
算法把特定内容多副本地分发到不同服务器上，重定向用户请求，使得用户能够从距离自己较近的服务器上获取内容。但是，拓扑上来讲，即使花费巨大成本，这个距离还可能不是足够近。
[0007] 大约2005年之后，P2P（peer-to-peer，点对点即对等
节点）网络的应用开始流行并且持续了一段时间。在P2P网络中，节点没有了明显的C/S的区别，而每个节点都可以在获取数据的同时服务其他节点。由于当时用户的设备内外存的存储空间有限，P2P主要用于流媒体直播场景－在此场景中，特定时刻不同用户需求数据的重叠度较高。然而，由于深受spyware（间谍
软件或流氓软件）的影响，多数用户并不情愿安装单独（standalone）的客户端，P2P应用逐渐失去了魅
力。
[0008] 2010年后，随着
云计算技术的成熟和大规模部署，CDN厂商开始融合云技术，并且应用多层的架构，从ISP的
数据中心和/或边缘机房“批发”带宽和存储，把服务“零售”给云的使用者即内容提供商（Content Provider, CP）。Cloud CDN似乎赢得了和P2P这场
网络战争的胜利。
[0009] 然而，构建一整套CDN体系的开支不菲，而且其包括带宽和存储的运营成本也较高。这导致了在多数发展中国家只有极少数规模最大、盈利能力较好的内容提供商才能够承担得起自建或租借CDN服务的
费用。
[0010] 再者，随着Wi-Fi、3G/4G/5G网络的应用与普及，移动设备数量的指数级增长，以及富媒体应用的流行，用户对内容（包括并不限于HTML网页、JS脚本、图片、音视频、流及动态内容）等的带宽需求越来越大。而上述技术改善的是终端到基站或者网关这一段的网络速度，而运营商（ISP）的骨干传输网络（backbone network）并没有因此而本质上变宽，这些技术部署后，面向用户的“最后一公里瓶颈”得到缓解，但随之而来的是用户更大的流量或带宽需求，中间的传输骨干网面临更大的冲击，内容提供商对CDN需求会明显增加。
[0011] 此外，CDN本质上是通过减轻用户数/用户请求量与边缘节点－用户的可用带宽之间的逆线性关系而工作的。其结果是，给定CDN服务的用户数如果持续增加，其整体用户体验必定会下滑。
[0012] 近年来，为了缩减成本，一些厂商开始尝试采用CDN和P2P混合的模式。融合的技术可分为两种：一种是在CDN服务器节点之间使用P2P传输技术来进行内容的分发、交换，并互相备份，以提高中心服务器（内容的源点）向CDN末端服务器（边缘节点）进行内容分发的效率。二是在传统P2P网络中加入CDN的管理机制和服务能力，形成一个以内容分发网络为中心，对等传输为边缘的传输架构，使原对等传输网络具有更强的内容及用户的可管理性，同时使整个网络的流量更加有序。
[0013] 美国
专利US 2008/0155061A1描述了一个混合CDN和P2P的系统，用户对资源的请求最终到底是由CDN还是P2P网络来提供取决于两者的负载和带宽情况。
[0014] 中国专利CN 200710086556.7则具体描述了在这种混合架构中的一种承载和调度策略：当CDN某一边缘节点服务的区域用户超过某一
阈值时，原有客户端变为P2P节点，来服务后加入的用户。
[0015] 但是，以上的方法中，一者CDN边缘节点仍是构建在服务一个到数个省级行政区域的ISP机房的服务器上，对网络的边缘并不能很好地
覆盖，事实上用户距所服务的CDN边缘的平均距离远大于一跳，例如大多数CDN对于中国西部超过五省的服务仅用成都的一个CDN机房覆盖；二者P2P模
块构建在了用户直接使用服务的PC、PDA、智能手机、
平板电脑等设备上，这样几乎不可避免会让用户
感知其对用户设备I/O和CPU的使用，消耗移动设备
电池电量，从而伤害用户体验；三者CDN和P2P的使用都有次序的，并不是真正意义上融合了CDN和P2P技术的方案；四者CDN和P2P之间的带宽调度太粗糙，事实上在真实的商业系统中根本不可能采用这么简单而模糊的方式来调度二者流量。
发明内容
[0016] 为解决内容提供商中心服务器带宽和处理能力瓶颈，ISP骨干网压力大，CDN运营和使用成本高，CDN和P2P系统不能无缝融合、灵活调度等问题，本发明在距离终端用户最近的“零跳”设备如智能路由器和网页浏览器上构建分层、众包的内容分发网络，并且设计出一整套使各方都获益的商业运营方法。
[0017] 本发明的第一个方面提出一种众包的内容分发网络系统，包括中心和边缘两大部分，其中，中心包含对边缘节点的管理模组，用于部署、更新、配置边缘节点的服务器或处理模组，索引边缘节点的资源信息和当前状态，对边缘部分提供统一或分层的管理；
边缘部分包含边缘服务器或边缘处理模组，全部或部分地直接部署在与所有者网络拓扑距离为零跳（Zero Hop）的具有局域网-广域网接入（LAN-WAN Access）功能的设备或模组上。
[0018] 本发明的第二个方面提出一种内容分发网络方法，包括：管理与所有者网络拓扑距离为零跳的具有局域网-广域网接入功能的设备或模组，以及部署在其上的功能模组；
根据所述设备或模组的物理特性和历史在线时长分布特定决定所述部署在其上的功能模组的工作方式，以及对哪些
位置的资源进行索引；
根据所服务业务和/或用户当前使用的业务/资源特征决定对资源的索引、查找和传输的方式；
根据所述设备或模组所在的网络位置、连接性、负载、服务容量、资源量、资源特征、所有者或频繁访问者在社交网络或兴趣域上的距离之中一个或多个信息决定
加速节点选择/资源查找的方式；根据场景需要在数据传输之前尝试协助边缘设备或模组之间建立P2P连接。
[0019] 本发明的第三个方面还提出一种内容分发网络装置，其为前述边缘部分的组成要素或元节点，并使用前述的方法来工作。
[0020] 本发明的第四个方面还提出一种众包的内容分发网络的商业方法，以类传统CDN的方式从内容提供商处获得流量收益，并按用户所贡献的峰值带宽和/或总分发数据量，将一部分收益回馈用户。
[0021] 相对于
现有技术，本发明的有益效果如下。
[0022] 相对传统P2P应用，因为工作在用户路由器等网络设备，而不是PC、PDA、智能
移动电话等用户可直接感知的计算设备上，本发明的诸多服务对用户来说几乎透明，对用户使用其他服务的QoE的影响几乎可以忽略不计。
[0023] 优化了整个网络中的流量，使大部分的数据传输仅发生在距用户0-2跳处，缓解了对ISP骨干网的压力和对CP中心服务器的压力。
[0024] 重新规划非时间敏感（time insensitive）的任务与数据传输，宏观上为CP缩减运营成本。
[0025] 减少对资源和
能源的浪费。本发明一方面充分利用了近用户端的空闲带宽。另一方面，绝大多数用户有持续长的时间，甚至7天×24小时不间断保持路由器等网络接入设备开启的习惯，而这些设备的空闲功耗还满载功耗仍在一个数量级，本发明已较低的额外功耗，使得用户端的任务运行和流量传输尽量发生在“一公里”之内，减少了中心服务器的能耗。
[0026] 本发明是构建在数据中心里高可靠性的“云计算”的一种有力补充，可以定义为“雾”（Fog）、“本地云”（Local Cloud）或“朵云”（Crowd Cloud）的一种应用形式或补充。
[0027] 当然，实施本发明的任一产品、提供的任一商业服务并不一定需要同时具备以上所有特征或达到以上所述的所有优点。
[0028] 上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照
说明书的内容予以实施，并且为了让本发明的上述和其他目的、特征和优点能够更明显易懂，以下特举较佳
实施例，并配合
附图，详细说明如下。
附图说明
[0029] 图1为本发明实施例的一种众包的内容分发网络的工作示意图。
[0030] 图2为本发明实施例在只含有智能路由节点但包含对用户兴趣的分析模块时的工作示意图。
[0031] 图3为本发明实施例在局部网络故障时提高内容分发可用性这个简单但特殊场景中的工作示意图。
[0032] 图4为本发明实施例的一种典型的抽象示意图。
具体实施方式
[0033] 为进一步阐述本发明达成预定发明目的所采取的技术手段及功效，以下结合附图及较佳实施例，对依据本发明提出的众包的内容分发网络其具体实施方式、方法、步骤及功效，详细说明如后。
[0034] 有关本发明的前述及其他技术内容、特点及功效，在以下配合参考图式的较佳实施例详细说明中将可清楚地呈现。通过具体实施方式的说明，当可对本发明为达成预定目的所采取的技术手段及功效得以更加深入且具体的了解，然而所附图式仅是提供参考与说明之用，并非用来对本发明加以限制。
[0035] 如无特别说明，在整个说明书和
权利要求书中，“包括”、“包含”，均为“包括但不限于”的含义。“连接”或其
变形用语，为两个或以上元件、模组或系统之间直接或间接的连接，可以是物理的、逻辑的，或者它们的组合。“/”代表的含义为“或”，涵盖以下解释：罗列中的任意项目、罗列中的所有项目、罗列中所有项目的任意组合。使用单数或复数的词语分别也可以表示单数或复数的情况。
[0036] 本发明主要思想的一个出发点是合理地利用近用户侧（网络拓扑距离零跳）设备的空闲带宽和存储资源，而这种设备通常并不是用户直接使用的服务设备，因而用户对其不是直接感知--至少不是敏感的，只要把任务粒度、带宽和I/O分布和负载控制得合适。另一个出发点是把信令或元数据（signaling (meta data)）和数据（(mass) data）分离，将数据更多地分布在距离用户零跳的设备上，其实是以极底的成本将服务器、内容分发和概率可用性的存储服务托管在了用户侧：近年来虽然每bit/Byte的带宽/存储成本在缓缓下降，但仍然保持超线性增长的数据规模会使诸多互联网服务沿用多年的云（Cloud）模式不会持续太久，许多巨头已经出现了数据规模造成的运营支出的增长超出了营收增长的现象。那么在Cloud之后，还更需要更多的本地处理（Local Processing），那么本发明实质上揭示的Fog（雾）模式， 又可称为local cloud或crowd-cloud，在构建下一代CDN甚至ICN（Information Centric Network，信息中心网络）中便会起到缩减成本、改善多数场景性能的重要作用。再一个出发点是设计一种激励（incentive）机制，发现背后更多商业模式与商业方法，将CDN等业务收益的一部分回馈相应用户，反过来也便于将本发明的系统、方法、设备比传统CDN更好地覆盖到网络的边缘。
[0037] 请参见图1，其为本发明实施例的一种众包的内容分发网络的的工作示意图，其包括：边缘部分101、中心部分106。其中边缘部分101包含工作节点，即距其所有者网络拓扑距离为零的设备或模组，包括家用或商用的宽带路由器、网络电视机顶盒（IPTV SetTop Box）、带有Internet接入功能的网络附加存储（NAS）设备、带有Internet接入功能的伙伴
机器人等，图1表示的实施例场景中102和104为带有附加存储的智能Wi-Fi路由器，103和105是支持WebRTC协议或RTMFP协议的Web浏览器或浏览器
插件；中心部分106包含用以调度整个网络中的任务和流量的协调者（Coordinator）模组，其又进一步包含用以协助边缘节点建立P2P连接的STUN/TURN/Trickle ICE子模组107、智能DNS或动态DNS子模组108、构建在DNS模组之服务于某些场景的全局负载均衡GLB子模组109、用以加速节点和/或资源的发现、选择或查找的ALTO子模组110，还可能包含索引部分类型资源，维护部分场景中节点关系、维护部分较优查找或传输路径/分发树/图的Indexing/Routing子模组。
[0038] 在另一些实施例中，107、108和109可能既部署在中心部分又分布于边缘部分。
[0039] 管理与所有者网络拓扑距离为零跳的具有局域网-广域网接入功能的设备或模组，以及部署在其上的功能模组。如102、104将设备上所部署的程序在每次设备启动时和/或每间隔一定时间向106注册以及发送该设备当前的状态信息，如当前可用带宽、可用内存/磁盘存储、CPU/存储使用率、CPU负载、I/O负载等；在符合特定条件的交互中，可带上部署在该设备上的特定或所有边缘处理模组的版本号，如果满足条件，则106的相应子模组返回特定信令消息，用以指示升级对应的边缘处理模组或下载安装新的处理模组。升级可采用增量更新方法，如二进制差异更新，或者Courgette算法。
[0040] 此外，上述管理模组还具有通知102、104等设备更新
操作系统或系统模组，更新系统程序和应用程序配置，重启设备的功能。上述任何信令通信，均需要以协商密钥（如IKE）的方法加密传输，以保障安全。
[0041] 对于如103、105这样的Web浏览器或浏览器插件，则在每次浏览器启动、页面打开或插件运行时，向106的相应子模组注册，在和106交互期间以及和任意对等节点交互期间双方监听通信状态，一旦通信不可达则向106相应子模组报告，对应子模组则在其维护的在线节点列表里删除该节点记录或者将更改相应记录的状态属性。
[0042] 在少数高服务质量要求的场景中，为保险起见103或105的对应模组也可以每隔较短时间（如每10--20s）发送心跳信令。
[0043] 根据所述设备或模组的物理特性和历史在线时长分布特定决定所述部署在其上的功能模组的工作方式，以及对哪些位置的资源进行索引。一般情况下，当设备包含附加存储时，会预取下个时间槽中可能需要的资源，否则不预取资源；当设备内存存储较大且历史在线时间多数较长时，不仅索引本设备的资源而且索引临近其他设备的状态信息和资源，否则仅索引本设备的资源。
[0044] 当所服务的业务是静态资源时，边缘节点采用DHT（分布式哈希表）的方法索引，hash值一般是文件的某种全文哈希，或者URL的某种字符串哈希，在索引方法层面，一个可行的实施例是采用基于异或距离的Kademlia方法。当所服务的业务为直播流媒体时，采用划分子流的多分发树的方法，如FashMesh或其近似方法，在每个子流的分发树的构造中，m n对于每个节点j，选择其父亲节点的启发式信息是形如Powerij=[min(rj,s)]/(dij+Di)的函数，其中rj为节点j的剩余可用带宽，s为该子流的平均码率，dij为从节点i到节点j的距离（一般以连接时延来衡量，也可以是关于RTT和packet_loss的表示连接性、吞吐率的函数），Di为从源到节点i的最长距离，m和n为用以调节量纲的正实数，每次选择此值最大的节点作为
父节点。
[0045] 根据业务场景需要，一般对于Web页面等资源，重定向后采用HTTP或HTTPS协议，而对于流媒体等资源，中间节点的传输一般使用基于UDP的协议，而最后服务用户的一段，可以使用基于HTTP的DASH如HLS协议。
[0046] 在静态资源和动态加速服务场景中，为进一步节省流量，边缘处理模组有对内容进行压缩的功能，可以针对具体业务时间局部性特征使用动态字典压缩；在信令加速场景中，边缘处理模组有对传输数据进行压缩及SSL加密的功能；在流媒体服务场景中，边缘处理模组有对
媒体流或媒体文件进行复用/解复用、转码、转封装、合并子流/分片/
帧/GoP的功能。
[0047] 当所服务的业务是静态资源时，采用DHT（分布式哈希表）的方法索引，hash值一般是文件的某种全文哈希，或者URL（全局资源
定位符）的某种字符串哈希，在索引方法层面，一个可行的实施例是采用基于异或距离的Kademlia方法。
[0048] 对时间不敏感的场景中的资源查找，可以使用DHT方式；而对时间敏感场景中的资源查找，则可使用本地和邻居索引、DHT、中心索引并行的方式。
[0049] 102、104部署有在连接中用RTT和丢包率等估计端对端可用带宽的模组，以及周期性检测和向106上报CPU使用率、CPU负载、可用内存存储、可用磁盘存储等信息的模组。
[0050] 在运营中，101的边缘模组中会引入一定概率的随机节点选择策略，在每次完成端对端的内容分发之后，统计该次传输的连接性并上报106。106含有对在线边缘节点进行自动聚类、分裂的子模组，参考包含全球IP段—地理位置—ISP的IP库，依据
三元组作为初始信息，在运营服务中根据101所上报连接性数据按E-M（期望最大化）算法不断迭代重聚类，并引入自动分裂机制，维护一个动态的节点组数据库，并合理使用MDS、GeoHash、基于Peano 或Hibert曲线的 Z-ordering方法，形成一个较佳的可进行快速高并发kNN查询的虚拟网络位置系统。[0051] 上述虚拟网络位置系统为构建智能/动态DNS子模组108、ALTO服务
端子模组110的一个重要
基础。其中110主要供边缘节点查询其邻居列表，用以让101等边缘节点用GOSSIP协议构建Membership表；而108一方面可请求重定向到临近或任一节点，另一方面提供信息给其上的GLB模组109，用以在保证服务质量的前提下，尽量使全局负载均衡。
[0052] 在每次节点上线时，101的边缘ALTO模组向106中的107子模组请求获取网络位置和其临近节点信息，获得后讲其索引进其GOSSIP Membership表，和/或DHT表的优先保留项，部分情况下，与其邻居节点通信，再获得邻居节点的相应索引表，一般限制信息所代表的节点距离其跳数为3以内。
[0053] 索引/路由子模组111为缩选出或所统计出的超级节点或稳定节点索引资源信息和维护这些节点相互连接的最佳路由表，以及某些服务如流媒体直播所构造的分发网。
[0054] 为提高资源预取的效率，提高命中率，以及加速资源和节点的查找，111子模组还维护有对用户域、兴趣域、资源域、网络拓扑域等多个域的索引，101边缘设备或模组上维护有对不同类型资源、不同上述域的分布式哈希子表，采用Heterogeneous Hashing的方法为不同数据类型汉明空间，以支持不同域之间的相似性查询(similarity search across different domains)，优化资源分布与查找路径。在查找时，使用HmSearch的方法加速。
[0055] 在某边缘设备或模组101预取资源或对某一资源或节点进行模糊查找时，可根据111模组的负载、服务优先级等情况，决定通过跨域的DHT查找，还是请求中心查找。
[0056] 对于预取资源，在另一实施例中，通过对用户历史时间序列数据的分析，以及用户之间的协同过滤来实现。此外，还可以由内容提供商(Content Provider)来显式地提供。
[0057] 在一个较佳的实施例中，如有社交网络服务商配合，则可根据社交关系链/关系图谱，或社交媒体传播模型，按资源所有者/先行传播者的1-2度关系，或预测的传播抵达节点，将特定的资源预先分发到距离可能访问该资源最近的边缘设备或模组，并同步111的中心索引子模组。这个方法会大大提高UGC等类型社交媒体资源的分发性能。
[0058] 对于缓存和预取资源的存储，102、104设备可采用共享内存缓存、NTFS或ext等本地文件系统，并且在以地理位置、ISP、兴趣域、资源属性域等划分的组中，可组成分布式、多份、冗余编码的文件系统以加速查询，提供服务可用率；103、105模组可采用内存对象、LocalStorage、Indexed DB、WebSQL。
[0059] 当101为浏览器页面，调用使WebRTC等协议在浏览器后台静默运行的API，以防连接和/或缓存资源丢失；当发生资源新进/置换/淘汰时，向其邻居广播相应的信令。。
[0060] 对于协助边缘设备或模组之间建立P2P连接，优选包含STUN和UPnP的Trickle ICE方法，107模组边收集101边缘模组的<内外网IP,端口,协议类型>三元组SDP信息，边进行连接性探测，如果都不能连通则采用TURN方法，建立中转连接，在一种较佳的实施例中，中转的边缘节点或服务器的选择需要根据ALTO子模组110和/或Smart DNS子模组108的启发信息来定，以减少连接延迟、增大吞吐速率、减少跨地域、跨ISP和经过ISP骨干网的流量。
[0061] 为提高P2P联通率，102、104等设备周期性探测所有1024—65535之间的所有可用端口，并存储维护起来。
[0062] 102、104设备如果有可用的内网到外网内网的映射，则向Coordinator模组注册，用以使更多节点可从外部建立P2P连接。当HTTP协议类型可用时，则向Smart DNS/DDNS子模组108注册，如有任何变化重新注册或上报，用以使尽量多的HTTP的CDN请求能够直接在应用层直接重定向到存有所请求资源的设备处理模组上。
[0063] 102、104设备有守护
进程(daemon)同时监听内网的a端口和外网的b端口。如为192.168.0.1:8888和123.456.789.123:9999，以使1跳之内能够命中的资源能够快速地重定向。
[0064] 服务中，可以用HTTP 302之类的的重定向，还可以嵌入crowd-mining的tagging等任务，帮助更有效的资源分发。
[0065] 在一个较佳的实施例中，102、104如果是含有附加存储且内存较大的设备，则其不仅管理自己缓存资源的索引或元数据，而且存储该区域其它设备和模组活跃页面对应资源（可以内存对象、LocalStorage、Indexed DB、WebSQL等形式来存储）的索引。
[0066] 102、103设备还部署有检测IP Multicast Land的模组，周期性向互联网中广播用于IP多播检测信息，讲收集到有回应的节点信息上报Coordinator模组106的可扩展IP多播协调子模组，协调子模组维护所有的IP Multicast Land以及每个包含的所有节点信息。
[0067] 在流媒体直播、超热资源预取等需要对众多可能处于一个IP Multicast Land的不同节点传输数据的场景中，在Coordinator模组106中合并所有处于同一IP Multicast Island的节点形成一个个多播域，对于入域只需要选出一个代表节点即可，这样大大压缩了内容分发树。
[0068] 请结合图1和图2，图1所示102、103设备包含分布式存储模组。用户贡献一部分存储空间，用以存储其他用户的资源和图2所示内容提供商(Content Provider, CP)分发的资源。这里需要使用加密存储，并将用户自己的资源与其他资源逻辑隔离，或使用所维护的帐号系统将访问权限分开—使用DDNS或DHT加上中心索引使得用户自己的资源在全网可用该帐号访问。
[0069] 图3示出了本发明用于在局部网络故障时提高内容分发可用性这个简单但特殊场景中的一个实施例。边缘模组（又可称为雾模组）A所对应的用户访问某Web服务器（一般是本发明实施例的CP客户的），但因为局部网络故障，连接无法抵达服务器或所请求资源无法返回，在重试无效后，A向协调者模组请求其他节点协助获取资源，协调者根据连通性、负载等信息返回可与A与Web服务器都联通且距离A和/或Web服务器较近的雾模组B，分布在A与B即协调者上的STUN等客户端与服务器模组帮助两者建立P2P连接，B构造相应的请求帮助A获取所需资源而后通过此连接返回给A，此过程可分段、渐进或异步进行，中转也可以多跳。图3中英文示出了相干各方交互的信令传输描述。
[0070] 对于多数规模较大的CP，CDN和ISP往往采用以特定周期
采样的总带宽峰值或九五分位来计价。但多数CP的服务用户都具有地域性，而特定地域人之间具有访问时间的高度重叠性，这样往往造成晚10-11点的峰值比其余时间显著得高的情况。这时，106模组根据场景特性，采用预取手段，为特定CP提供
削峰填谷的附加服务，用以帮助CP削减成本。
[0071] 请结合图3和图4，在维护用户账户系统的情况下，每月根据用户带宽贡献峰值、总分发带宽、以及存储空间贡献，给出一个合理的计价公式，将本系统服务的内容分发收益的一部分回馈给用户。形式可以是现金、支票、代金券、优惠券，或者其他增值服务。
[0072] 在获得用户同意后，向101中部署兴趣挖掘模组，用从非加密通信数据中挖掘用户兴趣的关键词等信息，可采用传统
数据挖掘方法也可采用Crowd-mining的方法。获得信息一方面提供兴趣域信息以优化资源分发，另一方面在代金券或优惠券场景中做到精准推送，再一方面可形成中间服务，帮助希望推广自身产品或服务的厂商快速把试用产品或广告信息（可以印在上述账单的背面）
送达目标用户或潜在用户。
[0073] 本发明的说明书及图式能够被相关领域技术人员理解并可根据公开实例作出多种
修改及变化。描述的诸多细节是用来提供对本公开的彻底理解。比如，上述多数场景以互联网上最常见、占比最多的应用层协议HTTP的情况来描述，并不妨碍此方案经简单的字段标识的修改，应用于其他的应用层甚至传输层的协议，如FTP、RTP、SRTP、SCTP、UDP。然而，在某些实施例中，为了避免使说明书含糊不清或过于冗长，并未描述领域内人员公知或常见的细节。
[0074] 需要说明的是，本发明的众包内容分发网络的系统、方法与设备的范畴包括但不限于上述各部分之间任意组合。
[0075] 以上所述，仅是本发明的较佳实施例而已，并非对本发明作任何形式上的限制，虽然本发明已以较佳实施例揭露如上，然而并非用以限定本发明，任何熟悉本专业的技术人员，在不脱离本发明技术方案范围内，当可利用上述揭示的技术内容作出些许更动或修饰为等同变化的等效实施例，但凡是未脱离本发明技术方案内容，依据本发明的技术实质对以上实施例所作的任何简单修改、等同变化与修饰，均仍属于本发明技术方案的范围内。
