一種眾包的內(nèi)容分發(fā)網(wǎng)絡系統(tǒng)、方法與裝置的制造方法
【技術(shù)領(lǐng)域】
[0001]本發(fā)明涉及網(wǎng)絡通信領(lǐng)域，尤其一種眾包的內(nèi)容分發(fā)網(wǎng)絡的系統(tǒng)、方法與設(shè)備。
【背景技術(shù)】
[0002]互聯(lián)網(wǎng)(Internet)商業(yè)化運營中，由于多數(shù)服務均采用C/S (客戶端/服務器)模式，少數(shù)的中心服務器一方面由于自身的帶寬、存儲容量有限，在服務成千上萬的用戶特別是有大量用戶請求瞬間擁入時，很容易成為整個網(wǎng)絡服務的瓶頸；另一方面由于距離用戶的地理距離、網(wǎng)絡拓撲距離可能較遠，且可能跨越多個ISP (Internet Service Provider,互聯(lián)網(wǎng)服務提供商或運營商)，傳輸路徑中很容易遭受網(wǎng)絡擁塞和抖動，以及運營商的限速坐寸ο
[0003]在上述情況下,用戶得不到較好的QoE(Quality of Experience,服務體驗質(zhì)量)。
[0004]20世紀90年代后期,各大Web站點的hot spot (熱點)和flash crowd (突發(fā)訪問)的現(xiàn)象越來越突出，造成的瓶頸問題不僅可以擊垮一個網(wǎng)站，甚至會帶來多米諾效應一站點附近的網(wǎng)絡都將受災。
[0005]為了解決前述各現(xiàn)象越來越突出，造成Web內(nèi)容傳送越來越慢、服務越來越不可靠的問題，萬維網(wǎng)(World Wide Web)之父Tim Berners-Lee在MIT (麻省理工學院)內(nèi)部發(fā)起了一個旨在改進互聯(lián)網(wǎng)內(nèi)容傳送方式的競賽，參與此競賽的研究生Daniel Lewin和其導師Tom Leighton基于參與此競賽的成果在不久之后創(chuàng)辦了后來世界上最大的⑶N(ContentDelivery Network,內(nèi)容分發(fā)網(wǎng)絡)公司一Akamai。
[0006]⑶N的基本思路即是在網(wǎng)絡中，跨地域、跨ISP地部署一系列服務器，并且以特定算法把特定內(nèi)容多副本地分發(fā)到不同服務器上，重定向用戶請求，使得用戶能夠從距離自己較近的服務器上獲取內(nèi)容。但是，拓撲上來講，即使花費巨大成本，這個距離還可能不是足夠近。
[0007]大約2005年之后，P2P (peer-to-peer,點對點即對等節(jié)點)網(wǎng)絡的應用開始流行并且持續(xù)了一段時間。在P2P網(wǎng)絡中，節(jié)點沒有了明顯的C/S的區(qū)別，而每個節(jié)點都可以在獲取數(shù)據(jù)的同時服務其他節(jié)點。由于當時用戶的設(shè)備內(nèi)外存的存儲空間有限，P2P主要用于流媒體直播場景一在此場景中，特定時刻不同用戶需求數(shù)據(jù)的重疊度較高。然而，由于深受spyware (間謀軟件或流飯軟件)的影響，多數(shù)用戶并不情愿安裝單獨(standalone)的客戶端，P2P應用逐漸失去了魅力。
[0008]2010年后，隨著云計算技術(shù)的成熟和大規(guī)模部署，⑶N廠商開始融合云技術(shù)，并且應用多層的架構(gòu)，從ISP的數(shù)據(jù)中心和/或邊緣機房“批發(fā)”帶寬和存儲，把服務“零售”給云的使用者即內(nèi)容提供商(Content Provider, CP)。Cloud Q)N似乎贏得了和P2P這場網(wǎng)絡戰(zhàn)爭的勝利。
[0009]然而，構(gòu)建一整套⑶N體系的開支不菲，而且其包括帶寬和存儲的運營成本也較高。這導致了在多數(shù)發(fā)展中國家只有極少數(shù)規(guī)模最大、盈利能力較好的內(nèi)容提供商才能夠承擔得起自建或租借CDN服務的費用。
[0010]再者，隨著W1-F1、3G/4G/5G網(wǎng)絡的應用與普及，移動設(shè)備數(shù)量的指數(shù)級增長，以及富媒體應用的流行，用戶對內(nèi)容(包括并不限于HTML網(wǎng)頁、JS腳本、圖片、音視頻、流及動態(tài)內(nèi)容)等的帶寬需求越來越大。而上述技術(shù)改善的是終端到基站或者網(wǎng)關(guān)這一段的網(wǎng)絡速度，而運營商(ISP)的骨干傳輸網(wǎng)絡(backbone network)并沒有因此而本質(zhì)上變寬,這些技術(shù)部署后，面向用戶的“最后一公里瓶頸”得到緩解，但隨之而來的是用戶更大的流量或帶寬需求，中間的傳輸骨干網(wǎng)面臨更大的沖擊，內(nèi)容提供商對CDN需求會明顯增加。
[0011]此外，CDN本質(zhì)上是通過減輕用戶數(shù)/用戶請求量與邊緣節(jié)點一用戶的可用帶寬之間的逆線性關(guān)系而工作的。其結(jié)果是，給定CDN服務的用戶數(shù)如果持續(xù)增加，其整體用戶體驗必定會下滑。
[0012]近年來，為了縮減成本，一些廠商開始嘗試采用⑶N和P2P混合的模式。融合的技術(shù)可分為兩種:一種是在CDN服務器節(jié)點之間使用P2P傳輸技術(shù)來進行內(nèi)容的分發(fā)、交換，并互相備份，以提高中心服務器(內(nèi)容的源點)向CDN末端服務器(邊緣節(jié)點)進行內(nèi)容分發(fā)的效率。二是在傳統(tǒng)P2P網(wǎng)絡中加入⑶N的管理機制和服務能力，形成一個以內(nèi)容分發(fā)網(wǎng)絡為中心，對等傳輸為邊緣的傳輸架構(gòu)，使原對等傳輸網(wǎng)絡具有更強的內(nèi)容及用戶的可管理性，同時使整個網(wǎng)絡的流量更加有序。
[0013]美國專利US 2008/0155061A1描述了一個混合⑶N和P2P的系統(tǒng)，用戶對資源的請求最終到底是由CDN還是P2P網(wǎng)絡來提供取決于兩者的負載和帶寬情況。
[0014]中國專利CN 200710086556.7則具體描述了在這種混合架構(gòu)中的一種承載和調(diào)度策略:當CDN某一邊緣節(jié)點服務的區(qū)域用戶超過某一閾值時，原有客戶端變?yōu)镻2P節(jié)點，來服務后加入的用戶。
[0015]但是，以上的方法中，一者CDN邊緣節(jié)點仍是構(gòu)建在服務一個到數(shù)個省級行政區(qū)域的ISP機房的服務器上，對網(wǎng)絡的邊緣并不能很好地覆蓋，事實上用戶距所服務的CDN邊緣的平均距離遠大于一跳，例如大多數(shù)CDN對于中國西部超過五省的服務僅用成都的一個CDN機房覆蓋；二者P2P模塊構(gòu)建在了用戶直接使用服務的PC、PDA、智能手機、平板電腦等設(shè)備上，這樣幾乎不可避免會讓用戶感知其對用戶設(shè)備I/O和CPU的使用，消耗移動設(shè)備電池電量，從而傷害用戶體驗；三者CDN和P2P的使用都有次序的，并不是真正意義上融合了CDN和P2P技術(shù)的方案；四者CDN和P2P之間的帶寬調(diào)度太粗糙，事實上在真實的商業(yè)系統(tǒng)中根本不可能采用這么簡單而模糊的方式來調(diào)度二者流量。

【發(fā)明內(nèi)容】

[0016]為解決內(nèi)容提供商中心服務器帶寬和處理能力瓶頸，ISP骨干網(wǎng)壓力大，⑶N運營和使用成本高，CDN和P2P系統(tǒng)不能無縫融合、靈活調(diào)度等問題，本發(fā)明在距離終端用戶最近的“零跳”設(shè)備如智能路由器和網(wǎng)頁瀏覽器上構(gòu)建分層、眾包的內(nèi)容分發(fā)網(wǎng)絡，并且設(shè)計出一整套使各方都獲益的商業(yè)運營方法。
[0017]本發(fā)明的第一個方面提出一種眾包的內(nèi)容分發(fā)網(wǎng)絡系統(tǒng)，包括中心和邊緣兩大部分，其中，
中心包含對邊緣節(jié)點的管理模組，用于部署、更新、配置邊緣節(jié)點的服務器或處理模組，索引邊緣節(jié)點的資源信息和當前狀態(tài)，對邊緣部分提供統(tǒng)一或分層的管理；
邊緣部分包含邊緣服務器或邊緣處理模組，全部或部分地直接部署在與所有者網(wǎng)絡拓撲距離為零跳(Zero Hop)的具有局域網(wǎng)-廣域網(wǎng)接入(LAN-WAN Access)功能的設(shè)備或模組上。
[0018]本發(fā)明的第二個方面提出一種內(nèi)容分發(fā)網(wǎng)絡方法，包括:
管理與所有者網(wǎng)絡拓撲距離為零跳的具有局域網(wǎng)-廣域網(wǎng)接入功能的設(shè)備或模組，以及部署在其上的功能模組；
根據(jù)所述設(shè)備或模組的物理特性和歷史在線時長分布特定決定所述部署在其上的功能模組的工作方式，以及對哪些位置的資源進行索引；
根據(jù)所服務業(yè)務和/或用戶當前使用的業(yè)務/資源特征決定對資源的索引、查找和傳輸?shù)姆绞剑?br> 根據(jù)所述設(shè)備或模組所在的網(wǎng)絡位置、連接性、負載、服務容量、資源量、資源特征、所有者或頻繁訪問者在社交網(wǎng)絡或興趣域上的距離之中一個或多個信息決定加速節(jié)點選擇/資源查找的方式；根據(jù)場景需要在數(shù)據(jù)傳輸之前嘗試協(xié)助邊緣設(shè)備或模組之間建立P2P連接。
[0019]本發(fā)明的第三個方面還提出一種內(nèi)容分發(fā)網(wǎng)絡裝置，其為前述邊緣部分的組成要素或元節(jié)點，并使用前述的方法來工作。
[0020]本發(fā)明的第四個方面還提出一種眾包的內(nèi)容分發(fā)網(wǎng)絡的商業(yè)方法，以類傳統(tǒng)⑶N的方式從內(nèi)容提供商處獲得流量收益，并按用戶所貢獻的峰值帶寬和/或總分發(fā)數(shù)據(jù)量，將一部分收益回饋用戶。
[0021 ] 相對于現(xiàn)有技術(shù)，本發(fā)明的有益效果如下。
[0022]相對傳統(tǒng)P2P應用，因為工作在用戶路由器等網(wǎng)絡設(shè)備，而不是PC、PDA、智能移動電話等用戶可直接感知的計算設(shè)備上，本發(fā)明的諸多服務對用戶來說幾乎透明，對用戶使用其他服務的QoE的影響幾乎可以忽略不計。
[0023]優(yōu)化了整個網(wǎng)絡中的流量，使大部分的數(shù)據(jù)傳輸僅發(fā)生在距用戶0-2跳處，緩解了對ISP骨干網(wǎng)的壓力和對CP中心服務器的壓力。
[0024]重新規(guī)劃非時間敏感(time insensitive)的任務與數(shù)據(jù)傳輸,宏觀上為CP縮減運營成本。
[0025]減少對資源和能源的浪費。本發(fā)明一方面充分利用了近用戶端的空閑帶寬。另一方面，絕大多數(shù)用戶有持續(xù)長的時間，甚至7天X24小時不間斷保持路由器等網(wǎng)絡接入設(shè)備開啟的習慣，而這些設(shè)備的空閑功耗還滿載功耗仍在一個數(shù)量級，本發(fā)明已較低的額外功耗，使得用戶端的任務運行和流量傳輸盡量發(fā)生在“一公里”之內(nèi)，減少了中心服務器的能耗。
[0026]本發(fā)明是構(gòu)建在數(shù)據(jù)中心里高可靠性的“云計算”的一種有力補充，可以定義為“霧”(Fog)、“本地云” (Local Cloud)或“朵云” (Crowd Cloud)的一種應用形式或補充。
[0027]當然，實施本發(fā)明的任一產(chǎn)品、提供的任一商業(yè)服務并不一定需要同時具備以上所有特征或達到以上所述的