融合P2P技術(shù)的云平臺(tái)快速內(nèi)容分發(fā)方法

劉 靖，趙文舉

(內(nèi)蒙古大學(xué) 計(jì)算機(jī)學(xué)院，呼和浩特 010021)

(*通信作者電子郵箱liujing@imu.edu.cn)

融合P2P技術(shù)的云平臺(tái)快速內(nèi)容分發(fā)方法

劉 靖*，趙文舉

(內(nèi)蒙古大學(xué) 計(jì)算機(jī)學(xué)院，呼和浩特 010021)

(*通信作者電子郵箱liujing@imu.edu.cn)

云存儲(chǔ)服務(wù)在內(nèi)容分發(fā)過(guò)程中的數(shù)據(jù)傳遞協(xié)議通常采用超文本傳輸協(xié)議(HTTP)，當(dāng)大量客戶(hù)端在短時(shí)間內(nèi)向云存儲(chǔ)服務(wù)器發(fā)出下載同一文件的請(qǐng)求時(shí)，會(huì)造成云服務(wù)端帶寬壓力過(guò)大以及客戶(hù)端下載過(guò)慢的問(wèn)題。為有效解決該問(wèn)題，提出了一種融合Peer-to-Peer(P2P)技術(shù)的云平臺(tái)快速內(nèi)容分發(fā)方法，在內(nèi)容分發(fā)過(guò)程中構(gòu)建動(dòng)態(tài)的HTTP和P2P協(xié)議轉(zhuǎn)換機(jī)制，實(shí)現(xiàn)快速內(nèi)容分發(fā)。選取用戶(hù)類(lèi)型、服務(wù)質(zhì)量、時(shí)間收益、帶寬收益等四種協(xié)議轉(zhuǎn)換度量指標(biāo)，并基于OpenStack云平臺(tái)實(shí)現(xiàn)了所提出的動(dòng)態(tài)協(xié)議轉(zhuǎn)換方法。實(shí)驗(yàn)結(jié)果表明，與僅使用HTTP或P2P協(xié)議的內(nèi)容分發(fā)方式相比，動(dòng)態(tài)協(xié)議轉(zhuǎn)換方法能夠保證客戶(hù)端用戶(hù)總是獲得較短的內(nèi)容下載時(shí)間，同時(shí)，當(dāng)P2P客戶(hù)端數(shù)量較大時(shí)能夠有效節(jié)約服務(wù)提供商的帶寬資源。

內(nèi)容分發(fā)；Peer-to-Peer；服務(wù)質(zhì)量；OpenStack；云存儲(chǔ)

0 引言

隨著云計(jì)算技術(shù)的發(fā)展，云存儲(chǔ)服務(wù)在商業(yè)應(yīng)用及個(gè)人應(yīng)用方面都成為普遍適用的存儲(chǔ)解決方案，出現(xiàn)了Dropbox、SugarSync、Google Drive等國(guó)外云存儲(chǔ)軟件及百度云盤(pán)、360云盤(pán)等國(guó)內(nèi)云存儲(chǔ)服務(wù)。由于云存儲(chǔ)服務(wù)具有共享和協(xié)作的特性，故云存儲(chǔ)服務(wù)用戶(hù)進(jìn)行文件共享的應(yīng)用場(chǎng)景非常普遍。例如，教師在課堂上通過(guò)校園云存儲(chǔ)平臺(tái)向?qū)W生共享實(shí)驗(yàn)數(shù)據(jù)集文件，學(xué)生通過(guò)該平臺(tái)提供的鏈接進(jìn)行下載。這時(shí)，學(xué)生作為客戶(hù)端會(huì)向云存儲(chǔ)服務(wù)器發(fā)出下載同一文件的請(qǐng)求，服務(wù)端收到請(qǐng)求后開(kāi)始提供下載服務(wù)，這種數(shù)據(jù)內(nèi)容分發(fā)過(guò)程中的數(shù)據(jù)傳輸協(xié)議一般采用超文本傳輸協(xié)議(HyperText Transfer Protocol, HTTP)。同時(shí)，數(shù)據(jù)分發(fā)過(guò)程中可能會(huì)出現(xiàn)如下問(wèn)題：大量客戶(hù)端短時(shí)間內(nèi)向云存儲(chǔ)服務(wù)器發(fā)出下載同一文件的請(qǐng)求，造成云服務(wù)端帶寬壓力過(guò)大，及客戶(hù)端下載過(guò)慢。為了有效解決這一問(wèn)題，在云平臺(tái)內(nèi)容分發(fā)過(guò)程中融合Peer-to-Peer (P2P)傳輸技術(shù)，利用P2P分發(fā)系統(tǒng)中節(jié)點(diǎn)之間能夠分享數(shù)據(jù)的特性，來(lái)降低服務(wù)端帶寬消耗，減少用戶(hù)的數(shù)據(jù)文件下載時(shí)間[1-4]。

在融合P2P技術(shù)到云平臺(tái)數(shù)據(jù)分發(fā)過(guò)程的相關(guān)研究中，文獻(xiàn)[5-7]分別闡述了BitTorrent(BT)協(xié)議等P2P類(lèi)傳輸協(xié)議不僅對(duì)于普通文件同步和分發(fā)是非常有效的，而且對(duì)于云環(huán)境的內(nèi)部虛擬機(jī)的鏡像傳輸也能降低其傳輸時(shí)間。例如文獻(xiàn)[6]中，作者論證了使用他們的BT協(xié)議解決方案后，虛擬機(jī)鏡像的傳輸相對(duì)于傳統(tǒng)的遠(yuǎn)程文件傳輸速度提高了超過(guò)30倍。文獻(xiàn)[8]中作者提出了利用時(shí)間收益比較來(lái)確定選用哪種分發(fā)協(xié)議，并討論了小文件對(duì)P2P協(xié)議分發(fā)的影響。上述相關(guān)研究工作，一方面討論使用BT等協(xié)議對(duì)云平臺(tái)內(nèi)容大文件分發(fā)的好處，另一方面利用分發(fā)時(shí)間等指標(biāo)簡(jiǎn)單地比較了兩種協(xié)議的效率。但事實(shí)上，具體討論如何在云平臺(tái)(尤其是在普遍采用的OpenStack云平臺(tái))中同時(shí)融合HTTP和BT兩種協(xié)議，并進(jìn)行動(dòng)態(tài)協(xié)議轉(zhuǎn)換來(lái)提高數(shù)據(jù)分發(fā)效率的研究非常少。

本文為了有效解決大量云服務(wù)客戶(hù)端在短時(shí)間內(nèi)向云存儲(chǔ)服務(wù)器發(fā)出并發(fā)文件數(shù)據(jù)傳輸?shù)恼?qǐng)求，造成云服務(wù)端帶寬壓力過(guò)大、客戶(hù)端下載過(guò)慢的問(wèn)題，提出了一種融合BT協(xié)議與傳統(tǒng)HTTP傳輸技術(shù)的云平臺(tái)快速內(nèi)容分發(fā)方法，主要內(nèi)容包括：綜合選取多種協(xié)議轉(zhuǎn)換度量指標(biāo)并給出其具體計(jì)算方法，在此基礎(chǔ)上，給出云平臺(tái)中數(shù)據(jù)內(nèi)容分發(fā)時(shí)HTTP和BitTorrent協(xié)議之間的協(xié)議動(dòng)態(tài)轉(zhuǎn)換方法，用來(lái)實(shí)現(xiàn)高效的內(nèi)容下載分發(fā)過(guò)程，并基于OpenStack云平臺(tái)實(shí)現(xiàn)了上述動(dòng)態(tài)協(xié)議轉(zhuǎn)換方法。通過(guò)實(shí)驗(yàn)將本文所提方法與純使用HTTP或BT協(xié)議下載方式對(duì)比，論證本文所提方法能夠保證客戶(hù)端用戶(hù)獲得較短的文件下載時(shí)間，同時(shí)有效降低了云服務(wù)商帶寬消耗。

1 快速內(nèi)容分發(fā)參考度量指標(biāo)選取及定義

融合BT協(xié)議實(shí)現(xiàn)云平臺(tái)快速內(nèi)容分發(fā)的主要思想是，當(dāng)服務(wù)端發(fā)現(xiàn)客戶(hù)端文件請(qǐng)求量大量增長(zhǎng)時(shí)，其所使用的文件分發(fā)協(xié)議會(huì)從原有的HTTP轉(zhuǎn)換為BT協(xié)議，并隨情況進(jìn)行動(dòng)態(tài)調(diào)整?；贐T協(xié)議的分發(fā)過(guò)程對(duì)于大文件數(shù)據(jù)傳輸是非常有效的，但是對(duì)于小文件數(shù)據(jù)傳輸，使用BT協(xié)議效果則不佳，可能造成用戶(hù)下載時(shí)間的增加。因此，動(dòng)態(tài)協(xié)議轉(zhuǎn)換機(jī)制的設(shè)計(jì)難點(diǎn)包括以下兩個(gè)方面：一方面是確定協(xié)議轉(zhuǎn)換的時(shí)間點(diǎn)，即達(dá)到什么樣的條件進(jìn)行協(xié)議轉(zhuǎn)換；另一方面是轉(zhuǎn)換后的效果如何衡量，即衡量服務(wù)提供商的帶寬節(jié)約量和用戶(hù)的下載時(shí)間的減少或提高程度。為此，本文要選取合適的參考度量指標(biāo)，并進(jìn)行一定的建模和計(jì)算來(lái)確定協(xié)議的轉(zhuǎn)換時(shí)間點(diǎn)及衡量協(xié)議轉(zhuǎn)換后的效果，然后，根據(jù)轉(zhuǎn)換效果來(lái)確定后續(xù)操作。

鑒于云快速內(nèi)容分發(fā)機(jī)制涉及到兩個(gè)利益主體，分別為云存儲(chǔ)服務(wù)提供商(即服務(wù)端)和云存儲(chǔ)訪問(wèn)用戶(hù)(及客戶(hù)端)，基于這兩個(gè)利益主體的利益考慮，本文選取了時(shí)間收益、寬帶收益、服務(wù)質(zhì)量、用戶(hù)類(lèi)型等四個(gè)度量指標(biāo)，作為動(dòng)態(tài)協(xié)議轉(zhuǎn)換方法中的核心考量指標(biāo)。其中，時(shí)間收益(即客戶(hù)端用戶(hù)下載時(shí)間收益)和服務(wù)質(zhì)量(即客戶(hù)端用戶(hù)獲得的服務(wù)水平)度量指標(biāo)側(cè)重于對(duì)用戶(hù)利益的綜合考慮，而寬帶收益(即服務(wù)端可節(jié)約的帶寬資源量)與用戶(hù)類(lèi)型(及區(qū)分付費(fèi)和免費(fèi)用戶(hù))度量指標(biāo)側(cè)重于對(duì)云服務(wù)提供商利益的綜合考慮。為了方便下文描述協(xié)議轉(zhuǎn)換指標(biāo)的具體含義，表1定義了用到的系統(tǒng)參數(shù)符號(hào)。

1.1 時(shí)間收益

為確定協(xié)議轉(zhuǎn)換后使用BT協(xié)議與HTTP的收益情況，需要對(duì)兩種下載協(xié)議下文件分發(fā)時(shí)間進(jìn)行估算。

文獻(xiàn)[9]提出一種BT時(shí)間估算方法，如式(1)：

TBT=F/min{dmin,u(I)/L,u(S)}

(1)

其中：TBT表示大小為F的文件分發(fā)到L個(gè)下載節(jié)點(diǎn)所需要的最小時(shí)間，最小下載時(shí)間依賴(lài)于最慢節(jié)點(diǎn)的下載速度dmin、平分到L個(gè)下載節(jié)點(diǎn)的混合上傳帶寬的平均值以及云平臺(tái)中種子節(jié)點(diǎn)的上傳帶寬。

1.1.1BT協(xié)議下小文件分發(fā)時(shí)間的估算

式(1)中沒(méi)有考慮到BT協(xié)議下載的額外時(shí)間開(kāi)銷(xiāo)，對(duì)于小文件，該時(shí)間會(huì)對(duì)文件下載時(shí)間有較大影響。文獻(xiàn)[8]對(duì)小文件的額外開(kāi)銷(xiāo)進(jìn)行了實(shí)驗(yàn)證明和討論。實(shí)驗(yàn)證明，BT協(xié)議分時(shí)，下載小文件的額外開(kāi)銷(xiāo)時(shí)間對(duì)其總分發(fā)時(shí)間影響較大，該文作者分析額外開(kāi)銷(xiāo)的原因有以下兩個(gè)方面：

啟動(dòng)階段 下載節(jié)點(diǎn)對(duì)種子文件的預(yù)處理及分塊時(shí)間(大約是分發(fā)時(shí)間的0.1%)，之后定位和聯(lián)系同伴節(jié)點(diǎn)開(kāi)始傳輸數(shù)據(jù)。此項(xiàng)開(kāi)銷(xiāo)根據(jù)系統(tǒng)負(fù)載一般可以被檢測(cè)并量化，且變化不大，可簡(jiǎn)單地把這種額外開(kāi)銷(xiāo)設(shè)定為一個(gè)常量αBT。

下載階段 下載節(jié)點(diǎn)會(huì)向其他節(jié)點(diǎn)上傳數(shù)據(jù)，即下載者只擁有部分?jǐn)?shù)據(jù)。一旦上傳者沒(méi)有新的數(shù)據(jù)片提供給其他節(jié)點(diǎn)，就會(huì)導(dǎo)致上傳中斷，其他節(jié)點(diǎn)會(huì)再次請(qǐng)求另外擁有此數(shù)據(jù)塊的節(jié)點(diǎn)，從而導(dǎo)致的額外開(kāi)銷(xiāo)。

對(duì)于下載階段的額外開(kāi)銷(xiāo)，文獻(xiàn)[8]中提出了一種解決方案，討論了BT協(xié)議下文件共享的有效性問(wèn)題，引入了一個(gè)參數(shù)η，按比例縮小下載節(jié)點(diǎn)的上傳速度，參數(shù)η衡量文件分享的效果，表達(dá)式如式(2)所示：

(2)

其中：參數(shù)N是請(qǐng)求文件被分割的片數(shù)，參數(shù)k表示下載節(jié)點(diǎn)擁有的連接數(shù)，該文指出對(duì)于大文件，η接近于1，但對(duì)于如1 MB的小文件(被分割4塊且每塊等于256 KB)，當(dāng)連接數(shù)等于2時(shí)，由公式得出η等于0.706 9，說(shuō)明一個(gè)節(jié)點(diǎn)從那些對(duì)其非阻塞的節(jié)點(diǎn)中沒(méi)有想下載的數(shù)據(jù)片的概率大約為30%，這就造成了節(jié)點(diǎn)下載時(shí)間的提高。

根據(jù)上述討論，考慮既適用于小文件又適用于大文件的BT協(xié)議分發(fā)時(shí)間估算方程如式(3)所示：

TBT=F/min{dmin,u(I)′/L,u(S)}+αBT

(3)

其中u′(I)=u(S)+ηu(L)表示所有節(jié)點(diǎn)混合上傳帶寬。

1.1.2 時(shí)間收益

時(shí)間收益用來(lái)比較BT協(xié)議和HTTP的下載效果，根據(jù)文獻(xiàn)[6]，定義時(shí)間收益Gain(T)如式(4)所示：

Gain(T)=(TCS-TBT)/TCS

(4)

其中：TCS表示使用HTTP的文件分發(fā)的最小時(shí)間，TBT表示BT協(xié)議下文件的最下分發(fā)時(shí)間?？紤]到客戶(hù)端下載節(jié)點(diǎn)不同，TCS主要受限于下載節(jié)點(diǎn)中速度最慢的一個(gè)，或者受限于種子節(jié)點(diǎn)平分到L個(gè)客戶(hù)端的上傳帶寬，所以TCS可用式(5)表示：

TCS=F/min{dmin,u(S)/L}

(5)

為了推導(dǎo)出收益的表達(dá)式，結(jié)合式(1)依據(jù)min{u(I)′/L,u(S),dmin}和min{u(S)/L,dmin}來(lái)區(qū)分幾種情況分別得到HTTP和BT協(xié)議的最小分發(fā)時(shí)間，經(jīng)過(guò)推導(dǎo)或?qū)嶋H分發(fā)情形只有以下4種情況合理，其他情況不存在。

情況1dmin≤u(S)/L且dmin≤min{u(I)′/L,u(S)}。

不論使用HTTP下載協(xié)議還是BT協(xié)議其最小分發(fā)時(shí)間都取決于速度最慢的節(jié)點(diǎn)。此時(shí)兩種分發(fā)協(xié)議對(duì)應(yīng)的下載時(shí)間為：

情況2u(S)/L≤dmin且dmin≤min{u(I)′/L,u(S)}。

使用HTTP的傳輸瓶頸是服務(wù)端為文件分配的帶寬和下載用戶(hù)數(shù)，而使用BT下載協(xié)議其傳輸瓶頸取決于下載節(jié)點(diǎn)最慢的節(jié)點(diǎn)，此時(shí)兩種分發(fā)協(xié)議對(duì)應(yīng)的下載時(shí)間為：

情況3u(I)′/L≤min{dmin,u(S)}。

使用BT下載協(xié)議的傳輸瓶頸受限于所有節(jié)點(diǎn)的混合上傳帶寬分配到L個(gè)下載節(jié)點(diǎn)的平均值，由于種子節(jié)點(diǎn)的混合上傳帶寬小于所有節(jié)點(diǎn)的混合帶寬且u(I)′/L≤dmin，所以總有u(S)/L≤dmin。此時(shí)，對(duì)于使用HTTP下載協(xié)議來(lái)講，其傳輸瓶頸受限于云服務(wù)端分配到所有節(jié)點(diǎn)的帶寬的平均值，此時(shí)兩種分發(fā)協(xié)議對(duì)應(yīng)的下載時(shí)間為：

情況4u(S)≤min{dmin,u(I)′/L}。

由于種子節(jié)點(diǎn)混合上傳帶寬小于最慢下載節(jié)點(diǎn)的下載速度，且總有種子節(jié)點(diǎn)混合帶寬分配到下載節(jié)點(diǎn)的平均值小于種子的節(jié)點(diǎn)混合帶寬，即u(S)/L≤u(S)且u(S)≤dmin，所以，對(duì)于使用HTTP下載協(xié)議，云服務(wù)端文件的帶寬分配到所有下載節(jié)點(diǎn)的平均值總是小于最慢節(jié)點(diǎn)的下載速度，此時(shí)兩種分發(fā)協(xié)議對(duì)應(yīng)的下載時(shí)間為：

對(duì)于上述每種情況，把得出的時(shí)間TCS和TBT代入時(shí)間收益的計(jì)算式(4)得出：

(6)

1.2 帶寬收益的計(jì)算

帶寬收益代表服務(wù)提供商的利益，表示使用BT協(xié)議進(jìn)行文件分發(fā)時(shí)，下載節(jié)點(diǎn)從其他下載節(jié)點(diǎn)獲得的下載數(shù)據(jù)量。帶寬收益的數(shù)量對(duì)于服務(wù)提供商來(lái)說(shuō)就是其帶寬的節(jié)約量，由其他下載節(jié)點(diǎn)數(shù)據(jù)交換量決定。為了估算帶寬收益，定義式(7)來(lái)計(jì)算：

(7)

其中Si(t)為云種子節(jié)點(diǎn)的播種速率，表示在時(shí)間t內(nèi)云種子節(jié)點(diǎn)向下載節(jié)點(diǎn)傳送的比特率。文獻(xiàn)[9]構(gòu)造了播種速率Si(t)，并給出了每種情況的表達(dá)式。播種速率依賴(lài)時(shí)間t、文件大小F、種子節(jié)點(diǎn)的上傳速度u(S)和所有下載節(jié)點(diǎn)上傳速度和下載速度的集合Cf。對(duì)于上述每種情況，式(8)給出了播種速率的表達(dá)式如下：

(8)

把求出的播種速率的表達(dá)式(8)代入帶寬收益公式(7)中，得到如下帶寬收益的具體估算公式(9)：

(9)

1.3 用戶(hù)類(lèi)型與服務(wù)質(zhì)量

本文服務(wù)質(zhì)量(QualityofService,QoS)主要是指云服務(wù)提供商提供的云平臺(tái)文件分發(fā)服務(wù)的質(zhì)量，而云服務(wù)商提供服務(wù)能力主要是根據(jù)用戶(hù)類(lèi)型來(lái)提供的，故本文首先從服務(wù)商的視角對(duì)用戶(hù)進(jìn)行類(lèi)型劃分?？紤]到現(xiàn)實(shí)中服務(wù)商提供的產(chǎn)品類(lèi)型以及內(nèi)容分發(fā)機(jī)制中的參考指標(biāo)，本文根據(jù)用戶(hù)對(duì)服務(wù)的付費(fèi)情況把用戶(hù)劃分成付費(fèi)用戶(hù)(Pay_user)和免費(fèi)用戶(hù)(Free_user)兩類(lèi)。對(duì)于付費(fèi)用戶(hù)，云服務(wù)商提供的服務(wù)能力質(zhì)量較高，而對(duì)于免費(fèi)用戶(hù)提供的服務(wù)能力質(zhì)量不如付費(fèi)用戶(hù)。在實(shí)際云平臺(tái)內(nèi)容分發(fā)中，用戶(hù)對(duì)服務(wù)質(zhì)量的最明顯感知是數(shù)據(jù)文件的下載時(shí)間，下載時(shí)間越低用戶(hù)對(duì)服務(wù)商提供的能力滿(mǎn)意度越高，反之用戶(hù)對(duì)其提供的服務(wù)容忍度越低。本文對(duì)用戶(hù)服務(wù)質(zhì)量參數(shù)值的具體定義為：服務(wù)質(zhì)量與服務(wù)商分配給文件的帶寬和請(qǐng)求下載文件的用戶(hù)數(shù)相關(guān)，服務(wù)質(zhì)量的參數(shù)值等于文件分配帶寬除以用戶(hù)數(shù)，即QoSmin=U/L。

在本文所提的云平臺(tái)快速內(nèi)容分發(fā)機(jī)制中，用戶(hù)的協(xié)議轉(zhuǎn)換條件與用戶(hù)的最低服務(wù)質(zhì)量相關(guān)，而對(duì)于不同類(lèi)型的用戶(hù)，其最低服務(wù)質(zhì)量參數(shù)值也不一樣。例如，云服務(wù)提供商定義云平臺(tái)中的免費(fèi)用戶(hù)的最低服務(wù)質(zhì)量參數(shù)值為1Mb/s，付費(fèi)用戶(hù)的最低服務(wù)質(zhì)量參數(shù)值為2Mb/s，免費(fèi)用戶(hù)的最低服務(wù)質(zhì)量數(shù)值總是低于付費(fèi)用戶(hù)的最低服務(wù)質(zhì)量的數(shù)值。而協(xié)議轉(zhuǎn)換時(shí)，如果請(qǐng)求用戶(hù)只有免費(fèi)用戶(hù)，達(dá)到或低于免費(fèi)用戶(hù)的最低服務(wù)質(zhì)量則開(kāi)始進(jìn)行協(xié)議轉(zhuǎn)換，例如：當(dāng)前服務(wù)商分配的文件帶寬為10Mb/s，用戶(hù)請(qǐng)求數(shù)為5，達(dá)到免費(fèi)用戶(hù)的最低服務(wù)質(zhì)量限制，協(xié)議進(jìn)行轉(zhuǎn)換。如果請(qǐng)求用戶(hù)中既包括免費(fèi)用戶(hù)又包括付費(fèi)用戶(hù)或者都是付費(fèi)用戶(hù)，則協(xié)議轉(zhuǎn)換的條件是達(dá)到或低于付費(fèi)用戶(hù)的最低服務(wù)質(zhì)量，例如：服務(wù)商分配給文件的帶寬為10Mb/s，當(dāng)前文件的用戶(hù)請(qǐng)求數(shù)為8，此時(shí)服務(wù)質(zhì)量低于付費(fèi)用戶(hù)的最低服務(wù)質(zhì)量，下載協(xié)議開(kāi)始進(jìn)行轉(zhuǎn)換。

2 動(dòng)態(tài)協(xié)議轉(zhuǎn)換方法的設(shè)計(jì)

第1章分別從云服務(wù)的兩個(gè)利益主體的角度描述了四種參考指標(biāo)來(lái)衡量HTTP和BT協(xié)議的轉(zhuǎn)換條件及效果，其中用戶(hù)類(lèi)型和最低服務(wù)質(zhì)量用來(lái)衡量HTTP和BT下載協(xié)議轉(zhuǎn)換的條件和時(shí)間點(diǎn)；時(shí)間收益用來(lái)衡量文件分發(fā)時(shí)，下載協(xié)議從HTTP轉(zhuǎn)換后BT時(shí)間的損益情況；帶寬收益用來(lái)衡量使用BT協(xié)議時(shí)，下載節(jié)點(diǎn)從其他下載節(jié)點(diǎn)數(shù)據(jù)量交換情況，也是衡量服務(wù)提供商的帶寬節(jié)約情況。

本章給出基于上述參考指標(biāo)計(jì)算值的動(dòng)態(tài)協(xié)議轉(zhuǎn)換算法，且基本思想可概述為：同時(shí)對(duì)評(píng)價(jià)指標(biāo)中的用戶(hù)類(lèi)型、服務(wù)質(zhì)量和時(shí)間收益三種指標(biāo)作出條件約束。首先考慮用戶(hù)類(lèi)型和服務(wù)質(zhì)量，大量用戶(hù)發(fā)送下載統(tǒng)一文件請(qǐng)求時(shí)，系統(tǒng)根據(jù)用戶(hù)類(lèi)型、用戶(hù)數(shù)及文件分配帶寬等條件，計(jì)算此時(shí)用戶(hù)服務(wù)質(zhì)量的參數(shù)值，并與服務(wù)商根據(jù)用戶(hù)類(lèi)型設(shè)定的最低服務(wù)質(zhì)量進(jìn)行比較，若小于預(yù)設(shè)的最低服務(wù)質(zhì)量參數(shù)值，文件分發(fā)從初始默認(rèn)的HTTP轉(zhuǎn)化為使用BT協(xié)議。協(xié)議轉(zhuǎn)換后，算法將分別預(yù)估后續(xù)使用HTTP和BT協(xié)議時(shí)，用戶(hù)的下載時(shí)間并計(jì)算時(shí)間收益，當(dāng)時(shí)間收益低于服務(wù)商設(shè)定的時(shí)間收益值時(shí)，下載協(xié)議進(jìn)行逆轉(zhuǎn)換，即再次轉(zhuǎn)換為使用HTTP進(jìn)行數(shù)據(jù)傳輸。其中，邊界條件即時(shí)間收益閾值作為第二次協(xié)議轉(zhuǎn)換判定條件，其參數(shù)值由服務(wù)提供商根據(jù)用戶(hù)類(lèi)型進(jìn)行預(yù)設(shè)定。

動(dòng)態(tài)協(xié)議轉(zhuǎn)換算法具體實(shí)現(xiàn)步驟如下。

輸入：系統(tǒng)參數(shù)集{文件大小F、節(jié)點(diǎn)上傳速度u及下載速度d、文件請(qǐng)求用戶(hù)的數(shù)量L、文件分配帶寬U、用戶(hù)類(lèi)型user_type、最低服務(wù)服務(wù)質(zhì)量QoSmin、云種子節(jié)點(diǎn)上傳速度u(S)、時(shí)間收益閾值CP}。

輸出：集群用戶(hù)的時(shí)間收益。

步驟1 算法開(kāi)始，實(shí)時(shí)收集文件分配帶寬、用戶(hù)類(lèi)型及請(qǐng)求用戶(hù)數(shù)、文件大小等系統(tǒng)參數(shù)。

步驟2 判斷當(dāng)前用戶(hù)是否包括付費(fèi)用戶(hù)，并根據(jù)服務(wù)質(zhì)量定義計(jì)算當(dāng)前的用戶(hù)平均服務(wù)質(zhì)量。

步驟3 如果當(dāng)前用戶(hù)包括付費(fèi)用戶(hù)，判斷其當(dāng)前服務(wù)質(zhì)量是否低于付費(fèi)用戶(hù)的最低服務(wù)質(zhì)量，如果小于預(yù)設(shè)的約束條件，執(zhí)行步驟4→步驟5，否則執(zhí)行步驟6→步驟7；如果沒(méi)有付費(fèi)用戶(hù)，計(jì)算平均服務(wù)質(zhì)量是否低于免費(fèi)用戶(hù)最低服務(wù)質(zhì)量，如果達(dá)到約束條件，執(zhí)行步驟4→步驟5，否則執(zhí)行步驟6→步驟7。

步驟4 云服務(wù)器生成種子文件并傳輸種子文件。

步驟5 用戶(hù)接收種子文件，解析種子文件后啟動(dòng)BT服務(wù)下載開(kāi)始進(jìn)行BT傳輸。利用式(6)計(jì)算用戶(hù)下載時(shí)間收益Gain(T)，如果用戶(hù)時(shí)間收益大于給定值T則執(zhí)行步驟7，否則執(zhí)行步驟6→步驟7。

步驟6 繼續(xù)以HTTP進(jìn)行文件傳輸。

步驟7 所有用戶(hù)完成下載文件，傳輸結(jié)束。

協(xié)議轉(zhuǎn)化算法中關(guān)鍵步驟的偽代碼描述如下：

if(user_type=Pay_user)

//判斷用戶(hù)類(lèi)型 { //判斷是否低于付費(fèi)用戶(hù)最低服務(wù)質(zhì)量 if (QoS<=QoSmin(Pay_user))producea“.torrent”file

//生成種子文件launchaBTseedinthecloud

//啟動(dòng)云種子節(jié)點(diǎn)forallusersrequestingdoleechersgetthe.torrentfilefromthecloudstartBTtransferring

//啟動(dòng)BT傳輸if(Gain(T)>CP(Pay)) continuing BT transferring else download file via HTTP

else download file via HTTP

} else { //判斷是否低于免費(fèi)用戶(hù)最低服務(wù)質(zhì)量 if (QoS<=QoSmin(Pay_free)) produce a “.torrent” file

//生成種子文件 launch a BT seed in the cloud

//啟動(dòng)云種子節(jié)點(diǎn) for all users requesting do leechers get the .torrent file from the cloud start BT transferring

//啟動(dòng)BT傳輸 if (Gain(T)>CP(Free)) continuing BT transferring else download file via HTTP

else download file via HTTP

}

上述動(dòng)態(tài)協(xié)議轉(zhuǎn)換方法中的時(shí)間收益閾值參數(shù)CP的取值依賴(lài)于用戶(hù)類(lèi)型的設(shè)定。對(duì)于付費(fèi)用戶(hù)，服務(wù)商要嚴(yán)格保證的用戶(hù)的下載時(shí)間，收益閾值設(shè)置始終大于等于0(總是選擇時(shí)間花費(fèi)最少的協(xié)議作為分發(fā)協(xié)議)；而對(duì)于免費(fèi)用戶(hù)，時(shí)間收益閾值可設(shè)置小于0(優(yōu)先使用BT協(xié)議進(jìn)行分發(fā)，節(jié)約服務(wù)提供商帶寬)。

3 動(dòng)態(tài)協(xié)議轉(zhuǎn)換方法的實(shí)現(xiàn)及對(duì)比實(shí)驗(yàn)

3.1 實(shí)現(xiàn)環(huán)境配置

本文使用OpenStack云平臺(tái)的Swif組件來(lái)提供存儲(chǔ)分發(fā)服務(wù)。參數(shù)收集工具使用高級(jí)消息隊(duì)列組件Rabbitmq，由于OpenStack及Swift都是使用Python語(yǔ)言進(jìn)行開(kāi)發(fā)的[11]，且Python語(yǔ)言具有易讀、易維護(hù)和豐富強(qiáng)大的類(lèi)庫(kù)，故本文在實(shí)現(xiàn)動(dòng)態(tài)協(xié)議轉(zhuǎn)換方法時(shí)，采用腳本語(yǔ)言Python。實(shí)現(xiàn)相關(guān)的軟硬件環(huán)境具體如下。

1)基礎(chǔ)硬件配置。CPU為Intel Core i3-2120 3.30 GHz；內(nèi)存為8 GB，1 TB存儲(chǔ)，操作系統(tǒng)為CentOS 6.5 64位。

2)基礎(chǔ)軟件配置。數(shù)據(jù)庫(kù)為MySQL 5.1，消息隊(duì)列組件為RabbitMQ，種子服務(wù)器為BitTorrent軟件，客戶(hù)端軟件為utorrent、myBT，應(yīng)用服務(wù)器為T(mén)omcat6.0客戶(hù)端軟件使用，其他軟件為hfs服務(wù)器，vmware workstation12.2。

實(shí)驗(yàn)環(huán)境首先部署Swift組件，Swift的部署上本文按照OpenStack官網(wǎng)上Swift開(kāi)發(fā)版本的部署方式“Swift All In One”進(jìn)行部署，即在單臺(tái)服務(wù)器上安裝運(yùn)行所有Swift服務(wù)，并模擬運(yùn)行4個(gè)節(jié)點(diǎn)的集群，首先安裝依賴(lài)包，主要包括url、gcc、git-core、memcached、python-coverage、python-dev、python-nose、python-setuptool等類(lèi)庫(kù)，安裝之后依次對(duì)Swfit各個(gè)服務(wù)進(jìn)行配置，如為設(shè)置副本管理工具，創(chuàng)建配置文件/etc/rsyncd.conf，所有服務(wù)配置完畢后，啟動(dòng)服務(wù)[12]。

Swift服務(wù)集群搭建完成之后，下一步配置開(kāi)發(fā)工具。本文使用Ecliplise開(kāi)發(fā)環(huán)境，并下載Python開(kāi)發(fā)插件PyDev集成到Ecliplise中。開(kāi)發(fā)工具配置之后，在Ecliplise中添加Swift和Python-swiftclient的源代碼，其中Swift的源代碼存放在～/swift/swift_1.7.6目錄下，Swift客戶(hù)端的源代碼存放在～/swift/python-swiftclient_1.2.0目錄下。

至此所有的環(huán)境和開(kāi)發(fā)部署工具已經(jīng)準(zhǔn)備好，將實(shí)驗(yàn)代碼編寫(xiě)到Ecliplise中進(jìn)行調(diào)試，便可對(duì)動(dòng)態(tài)協(xié)議轉(zhuǎn)換算法進(jìn)行實(shí)現(xiàn)和分析。

3.2 實(shí)現(xiàn)關(guān)鍵技術(shù)

融合P2P協(xié)議的云平臺(tái)分發(fā)機(jī)制實(shí)現(xiàn)關(guān)鍵技術(shù)主要有三點(diǎn)：1)系統(tǒng)各參數(shù)的收集及傳遞；2)Swift組件代理節(jié)點(diǎn)Proxy請(qǐng)求轉(zhuǎn)發(fā)的改變；3)云平臺(tái)中BT傳輸?shù)膶?shí)現(xiàn)。下文分別對(duì)這3點(diǎn)關(guān)鍵技術(shù)進(jìn)行闡述。

1)系統(tǒng)各參數(shù)的收集及傳遞。本文收集的參數(shù)為動(dòng)態(tài)協(xié)議轉(zhuǎn)換算法中的輸入?yún)?shù)集合。其中，動(dòng)態(tài)協(xié)議轉(zhuǎn)換算法主要在代理組件swift-proxy中實(shí)現(xiàn)，所以代理組件需要收集的參數(shù)包括用戶(hù)類(lèi)型、文件分配帶寬、副本數(shù)即云種子節(jié)點(diǎn)數(shù)、用戶(hù)請(qǐng)求數(shù)、及所有下載節(jié)點(diǎn)和種子節(jié)點(diǎn)的帶寬信息。對(duì)于種子服務(wù)器，為了創(chuàng)建被請(qǐng)求文件的種子，需要收集的參數(shù)包括所有文件的存儲(chǔ)位置及數(shù)量。參數(shù)的收集及傳遞主要是利用消息隊(duì)列組件RabbitMQ進(jìn)行實(shí)現(xiàn)，其收集器的toCollection方法負(fù)責(zé)收集系統(tǒng)實(shí)時(shí)參數(shù)，而其中的消息傳遞機(jī)制“生產(chǎn)者消費(fèi)者模型”負(fù)責(zé)系統(tǒng)各參數(shù)的傳遞。

2)Swift組件代理節(jié)點(diǎn)Proxy請(qǐng)求轉(zhuǎn)發(fā)的改變。在Swift中所有的請(qǐng)求都要經(jīng)過(guò)swift-proxy組件，作為請(qǐng)求的入口和處理點(diǎn)，其中主方法handle_request作為swift-proxy代理服務(wù)的入口點(diǎn)，負(fù)責(zé)對(duì)用戶(hù)的請(qǐng)求進(jìn)行處理和執(zhí)行，故本文在handle_request中作了以下改變：handle_request方法獲取用戶(hù)請(qǐng)求后首先執(zhí)行self.get_controller(req.path) 進(jìn)行預(yù)處理，得到控制器的請(qǐng)求路徑，預(yù)處理過(guò)程由協(xié)議轉(zhuǎn)換算法進(jìn)行實(shí)現(xiàn)，如果達(dá)到轉(zhuǎn)換條件則獲取種子服務(wù)器Tracker的控制路徑，如果未達(dá)到則獲取對(duì)象服務(wù)器Object的路徑。接下來(lái)獲取控制器類(lèi)的實(shí)例化對(duì)像controller(self, **path_parts)，并在環(huán)境變量req.environ[‘swift.trans_id’]中設(shè)置對(duì)象實(shí)例id。最后執(zhí)行控制類(lèi)方法getattr(controller, req.method)，其中req.method標(biāo)識(shí)具體操作，如Upload、Get等操作。

3)云平臺(tái)中基于BT協(xié)議的傳輸。為了在Swfit云平臺(tái)進(jìn)行BT數(shù)據(jù)傳輸，一方面需要在云平臺(tái)中部署Tracker服務(wù)器，另一方面要對(duì)被請(qǐng)求文件進(jìn)行做種處理。 本文對(duì)文件進(jìn)行做種時(shí)，首先安裝libtorrent庫(kù)，且在編譯時(shí)需要增加./configure-enable-python-binding，然后進(jìn)入binding目錄，make install運(yùn)行，接著編寫(xiě)代碼利用Rabbitmq獲取文件路徑path，然后調(diào)用方法lt.create_torrent(path)進(jìn)行做種，并利用方法t.add_tracker把種子相關(guān)信息上傳到Tracker 服務(wù)器中進(jìn)行發(fā)布即可。BT客戶(hù)端之間一般要通過(guò)Tracker服務(wù)器來(lái)進(jìn)行信息交換才能知道彼此的存在，本文選用xbt Tracker。

3.3 對(duì)比實(shí)驗(yàn)結(jié)果與分析

本文針對(duì)小文件分發(fā)的特殊性，對(duì)BT協(xié)議傳輸產(chǎn)生的額外開(kāi)銷(xiāo)進(jìn)行了分析，并結(jié)合額外開(kāi)銷(xiāo)對(duì)文件分發(fā)時(shí)間進(jìn)行了適應(yīng)性的改變，所以本節(jié)通過(guò)實(shí)驗(yàn)首先計(jì)算額外開(kāi)銷(xiāo)和文件分發(fā)時(shí)間，然后對(duì)協(xié)議動(dòng)態(tài)轉(zhuǎn)換機(jī)制的效果進(jìn)行分析和評(píng)價(jià)。

1)首先對(duì)BT協(xié)議下的額外開(kāi)銷(xiāo)時(shí)間數(shù)值和BT文件分發(fā)時(shí)間的準(zhǔn)確性進(jìn)行驗(yàn)證。

本文實(shí)驗(yàn)選取的文件大小為1 MB，分配給該文件的上傳帶寬為2 Mb/s，客戶(hù)端數(shù)量集合{2，3，4，5，6}且每個(gè)客戶(hù)端的上傳帶寬為512 Kb/s，下載帶寬為1 Mb/s。本文重復(fù)5次實(shí)驗(yàn)并測(cè)量客戶(hù)端的平均下載時(shí)間和額外開(kāi)銷(xiāo)αBT。

額外開(kāi)銷(xiāo)時(shí)間的實(shí)驗(yàn)結(jié)果如圖1所示。分析可知，BT協(xié)議下，每個(gè)集群所產(chǎn)生的額外開(kāi)銷(xiāo)都圍繞2.5 s進(jìn)行散布，所以計(jì)算BT協(xié)議下文件的分發(fā)時(shí)間時(shí)，可以把額外開(kāi)銷(xiāo)時(shí)間設(shè)置成固定值2.5 s。

圖1 開(kāi)銷(xiāo)時(shí)間αBT散點(diǎn)圖

實(shí)驗(yàn)中，觀察到每個(gè)集群的文件分發(fā)時(shí)間，并利用式(3)能夠計(jì)算出預(yù)估文件分發(fā)時(shí)間，故圖2給出預(yù)估文件分發(fā)時(shí)間和實(shí)際分發(fā)時(shí)間對(duì)比曲線。分析可知，利用式(3)預(yù)估的文件分發(fā)時(shí)間與實(shí)際的BT文件分發(fā)時(shí)間比較近似錯(cuò)誤率在10%之內(nèi)，而利用式(1)由于沒(méi)有考慮文件的額外開(kāi)銷(xiāo)，文件分發(fā)時(shí)間與實(shí)際分發(fā)時(shí)間錯(cuò)誤率在30%左右。所以在計(jì)算小文件的最少分發(fā)時(shí)間時(shí)一定考慮分發(fā)過(guò)程中的額外開(kāi)銷(xiāo)。

圖2 下載時(shí)間對(duì)比

2)動(dòng)態(tài)協(xié)議轉(zhuǎn)換方法有效性的驗(yàn)證。

為了驗(yàn)證動(dòng)態(tài)協(xié)議轉(zhuǎn)換算法的對(duì)云平臺(tái)文件分發(fā)的有效性，本文設(shè)置了兩組實(shí)驗(yàn)：大文件分發(fā)實(shí)驗(yàn)和小文件分發(fā)實(shí)驗(yàn)。為了使分發(fā)效果對(duì)比明顯，本文使用大小為1 GB的大文件和大小為1 MB的小文件作為典型被請(qǐng)求文件。兩組實(shí)驗(yàn)中集群客戶(hù)端數(shù)量為{2，3，4，5，6}，免費(fèi)用戶(hù)最低服務(wù)質(zhì)量設(shè)置為512 Kb/s，付費(fèi)用戶(hù)的最低服務(wù)質(zhì)量為1 Mb/s，時(shí)間收益閾值參數(shù)設(shè)置為0，文件分配帶寬設(shè)置為2 Mb/s?？蛻?hù)端的上傳帶寬是512 Kb/s，下載帶寬是1 Mb/s，BT的額外開(kāi)銷(xiāo)設(shè)置成固定值2.5 s。為防止協(xié)議轉(zhuǎn)換時(shí)做種時(shí)間消耗的干擾，本文在實(shí)驗(yàn)前提前制作好種子文件。可通過(guò)修改客戶(hù)端配置文件來(lái)模擬純HTTP、純BT協(xié)議的下載場(chǎng)景，并與本文提出的動(dòng)態(tài)協(xié)議轉(zhuǎn)換方法進(jìn)行對(duì)比實(shí)驗(yàn)。

針對(duì)大文件的對(duì)比實(shí)驗(yàn)結(jié)果如表2所示。

分析表2數(shù)據(jù)可知，當(dāng)集群客戶(hù)端數(shù)量為2時(shí)，最低服務(wù)質(zhì)量還未達(dá)到動(dòng)態(tài)協(xié)議轉(zhuǎn)換的條件，所以純HTTP下載時(shí)間與動(dòng)態(tài)協(xié)議轉(zhuǎn)換方法下載時(shí)間近似相同。而使用純BT進(jìn)行下載，節(jié)點(diǎn)互相可以分享數(shù)據(jù)，故下載時(shí)間低于兩者，此時(shí)使用動(dòng)態(tài)協(xié)議轉(zhuǎn)換方法帶寬收益為0。隨著集群客戶(hù)端數(shù)量的增加，HTTP下載時(shí)間逐漸增加，并且服務(wù)端帶寬被完全占用，而純BT下載與動(dòng)態(tài)協(xié)議轉(zhuǎn)換方法的下載時(shí)間隨著下載節(jié)點(diǎn)的增多而逐漸降低，并且開(kāi)始產(chǎn)生帶寬收益，降低了服務(wù)提供商的帶寬開(kāi)銷(xiāo)。

表2 大文件下載實(shí)驗(yàn)結(jié)果

針對(duì)小文件的對(duì)比實(shí)驗(yàn)結(jié)果如表3所示。

表3 小文件下載實(shí)驗(yàn)結(jié)果

分析表3數(shù)據(jù)可知，進(jìn)行小文件分發(fā)時(shí)，當(dāng)集群客戶(hù)端數(shù)量較少時(shí)未達(dá)到其最低服務(wù)質(zhì)量，此時(shí)HTTP分發(fā)時(shí)間與動(dòng)態(tài)協(xié)議分發(fā)時(shí)間近似，而B(niǎo)T分發(fā)時(shí)間由于額外開(kāi)銷(xiāo)導(dǎo)致花費(fèi)時(shí)間較長(zhǎng)。隨著客戶(hù)端數(shù)量增加，三者文件分發(fā)時(shí)間都逐漸增加，由于此時(shí)動(dòng)態(tài)協(xié)議轉(zhuǎn)換的時(shí)間收益小于0，所以動(dòng)態(tài)協(xié)議使用的還是HTTP時(shí)間，故近似等于HTTP時(shí)間。當(dāng)客戶(hù)端數(shù)量進(jìn)一步增加時(shí)，用戶(hù)時(shí)間收益開(kāi)始減小，文件分發(fā)協(xié)議繼續(xù)使用BT協(xié)議，此時(shí)動(dòng)態(tài)協(xié)議轉(zhuǎn)換時(shí)間近似于BT協(xié)議的分發(fā)時(shí)間，并且產(chǎn)生一定的帶寬收益。

綜上，無(wú)論分發(fā)大文件還是小文件，本文提出動(dòng)態(tài)協(xié)議轉(zhuǎn)換方法總是選擇最優(yōu)的數(shù)據(jù)傳輸協(xié)議進(jìn)行分發(fā)，能夠有效降低用戶(hù)的下載時(shí)間，并且獲得很好的帶寬收益。

4 結(jié)語(yǔ)

本文提出了一種融合BitTorrent協(xié)議技術(shù)的云平臺(tái)內(nèi)容快速分發(fā)方法，主要貢獻(xiàn)為選取并計(jì)算了用戶(hù)類(lèi)型、服務(wù)質(zhì)量、時(shí)間收益、帶寬收益等四種度量指標(biāo)，在此基礎(chǔ)上提出了一種在HTTP和BitTorrent協(xié)議之間的動(dòng)態(tài)協(xié)議轉(zhuǎn)換算法，用來(lái)實(shí)現(xiàn)高效的內(nèi)容下載分發(fā)過(guò)程。此外，本文基于OpenStack云平臺(tái)實(shí)現(xiàn)了上述動(dòng)態(tài)協(xié)議轉(zhuǎn)換方法。在該實(shí)際內(nèi)容分發(fā)平臺(tái)上，將本文所提方法與純使用HTTP或BT協(xié)議下載方式對(duì)比，分析實(shí)驗(yàn)結(jié)果可知，基于協(xié)議動(dòng)態(tài)轉(zhuǎn)換方法的云平臺(tái)內(nèi)容分發(fā)過(guò)程無(wú)論在分發(fā)大文件還是小文件時(shí)，都能夠保證客戶(hù)端用戶(hù)獲得較短的文件下載時(shí)間，同時(shí)，服務(wù)商的帶寬資源得到了進(jìn)一步節(jié)省，提供商的帶寬收益較好。后續(xù)工作將重點(diǎn)解決本文所提方法存在的一些局限性問(wèn)題，如用戶(hù)量數(shù)量較少時(shí)，其分發(fā)效率不如使用純BT協(xié)議的效率；以及由于對(duì)已分配的下載帶寬作動(dòng)態(tài)改變，可能導(dǎo)致服務(wù)商存在一定的帶寬浪費(fèi)等問(wèn)題。

References)

[1] LEON X, CHAABOUNI R, SANCHEZ-ARTIGAS M, et al.Smart cloud seeding for BitTorrent in datacenters [J].IEEE Internet Computing, 2014, 18(4): 47-54.

[2] CHEN G, HU T, JIANG D, et al.BestPeer++: a peer-to-peer base large-scale data processing platform [J].IEEE Transactions on Knowledge and Data Engineering, 2014, 26(6): 1316-1331.

[3] PETERSON R S, SIRER E G.Antfarm: efficient content distribution with managed swarms [C]// NSDI 2009: Proceedings of the 6th USENIX Symposium on Networked Systems Design and Implementation.Piscataway, NJ: IEEE, 2009: 107-122.

[4] SHARMA A, VENKATARAMANI A, ROCHA A A.Pros & Cons of model-based bandwidth control for client-assisted content delivery [C]// COMSNETS 2014: Proceedings of the 2014 Sixth International Conference on Communication Systems and Networks.Piscataway, NJ: IEEE, 2014: 1-8.

[5] PRIYANKA S, KALPANA R, HEMALATHA M.Reducing upload and download time on cloud using content distribution algorithm [J].International Journal on Recent and Innovation Trends in Computing and Communication, 2013, 1(3): 101-105.

[6] WARTEL R, CASS T, MOREIRA B, et al.Image distribution mechanisms in large scale cloud providers [C]// CloudCom 2010: Proceedings of the IEEE 5th International Conference on Cloud Computing Technology and Science.Piscataway, NJ: IEEE, 2010: 112-117.

[7] CARBUNARU C, TEO Y M, LEONG B.A performance study of peer-assisted file distribution with heterogeneous swarms [C]// LCN 2011: Proceedings of the 38th Annual IEEE Conference on Local Computer Networks.Piscataway, NJ: IEEE, 2011: 341-349.

[8] CHAABOUNI R, SANCHEZ-ARTIGAS M, GARCIA-LOPEZ P.Reducing costs in the personal cloud is BitTorrent a better bet? [C]// P2P 2014: Proceedings of the 14th IEEE International Conference on Peer-to-Peer Computing.Piscataway, NJ: IEEE, 2014: 1-10.

[9] LIU S, HUANG X, FU H.Understanding data characteristics and access patterns in a cloud storage system [C]// CCGrid 2013: Proceedings of the 13th IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing.Piscataway, NJ: IEEE, 2013: 15-19.

[10] SCHMIDT M, FALLENBECK N, SMITH M.Efficient distribution of virtual machines for cloud computing [C]// PDP 2010: Proceedings of the 18th Euromicro International Conference on Parallel, Distributed and Network-Based Processing.Washington, DC: IEEE Computer Society, 2010: 567-574.

[11] OPENSTACK PROJECT.OpenStack API guide [EB/OL].[2016-04-15].http://developer.openstack.org/api-guide/quick-start/.

[12] OPENSTACK PROJECT.Object Storage service [EB/OL].[2016-03-30].http://docs.openstack.org/mitaka/config-reference/ object-storage.html.

This work is supported by the National Natural Science Foundation of China (61262017).

LIU Jing, born in 1981, Ph.D., associate professor.His research interests include cloud computing, software testing.

ZHAO Wenju, born in 1990, M.S.candidate.His research interests include cloud computing, network protocol.

Fast content distribution method of integrating P2P technology in cloud platform

LIU Jing*, ZHAO Wenju

(CollegeofComputerScience,InnerMongoliaUniversity,HohhotNeiMongol010021,China)

The HyperText Transfer Protocol (HTTP) is usually adopted in the content distribution process for data transferring in cloud storage service.When large number of users request to download the same file from the cloud storage server in a short time, the cloud server bandwidth pressure becomes so large, and further the download becomes very slow.Aiming at this problem, the P2P technology was integrated into fast content distribution for cloud platform, and a dynamic protocol conversion mechanism was proposed to achieve fast and better content distribution process.Four protocol conversion metrics, including user type, service quality, time yield and bandwidth gains, were selected, and OpenStack cloud platform was utilized to realize the proposed protocol conversion method.Compared with the pure HTTP protocol or P2P downloading method, the experimental results show that the proposed method can guarantee client users obtaining less download time, and the bandwidth of service provider is saved effectively as there are many P2P clients.

content distribution; Peer-to-Peer (P2P); Quality of Service (QoS); OpenStack; cloud storage

2016-07-30;

2016-08-05。 基金項(xiàng)目:國(guó)家自然科學(xué)基金資助項(xiàng)目(61262017)。

劉靖(1981—)，男，內(nèi)蒙古呼和浩特人，副教授，博士，CCF高級(jí)會(huì)員，主要研究方向：云計(jì)算、軟件測(cè)試； 趙文舉(1990—)，男，河南永城人，碩士研究生，主要研究方向：云計(jì)算、網(wǎng)絡(luò)協(xié)議。

1001-9081(2017)01-0031-06

10.11772/j.issn.1001-9081.2017.01.0031

TP393.02

A