劉 靖，趙文舉

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

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

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

劉 靖*，趙文舉

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

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

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

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

0 引言

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

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

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

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

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

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

1.1 時間收益

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

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

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

(1)

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

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

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

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

下載階段 下載節(jié)點會向其他節(jié)點上傳數(shù)據(jù)，即下載者只擁有部分數(shù)據(jù)。一旦上傳者沒有新的數(shù)據(jù)片提供給其他節(jié)點，就會導致上傳中斷，其他節(jié)點會再次請求另外擁有此數(shù)據(jù)塊的節(jié)點，從而導致的額外開銷。

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

(2)

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

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

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

(3)

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

1.1.2 時間收益

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

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

(4)

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

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

(5)

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

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

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

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

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

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

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

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

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

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

(6)

1.2 帶寬收益的計算

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

(7)

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

(8)

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

(9)

1.3 用戶類型與服務質(zhì)量

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

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

2 動態(tài)協(xié)議轉(zhuǎn)換方法的設計

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

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

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

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

輸出：集群用戶的時間收益。

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

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

步驟3 如果當前用戶包括付費用戶，判斷其當前服務質(zhì)量是否低于付費用戶的最低服務質(zhì)量，如果小于預設的約束條件，執(zhí)行步驟4→步驟5，否則執(zhí)行步驟6→步驟7；如果沒有付費用戶，計算平均服務質(zhì)量是否低于免費用戶最低服務質(zhì)量，如果達到約束條件，執(zhí)行步驟4→步驟5，否則執(zhí)行步驟6→步驟7。

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

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

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

步驟7 所有用戶完成下載文件，傳輸結束。

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

if(user_type=Pay_user)

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

//生成種子文件launchaBTseedinthecloud

//啟動云種子節(jié)點forallusersrequestingdoleechersgetthe.torrentfilefromthecloudstartBTtransferring

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

else download file via HTTP

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

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

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

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

else download file via HTTP

}

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

3 動態(tài)協(xié)議轉(zhuǎn)換方法的實現(xiàn)及對比實驗

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

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

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

2)基礎軟件配置。數(shù)據(jù)庫為MySQL 5.1，消息隊列組件為RabbitMQ，種子服務器為BitTorrent軟件，客戶端軟件為utorrent、myBT，應用服務器為Tomcat6.0客戶端軟件使用，其他軟件為hfs服務器，vmware workstation12.2。

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

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

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

3.2 實現(xiàn)關鍵技術

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

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

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

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

3.3 對比實驗結果與分析

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

1)首先對BT協(xié)議下的額外開銷時間數(shù)值和BT文件分發(fā)時間的準確性進行驗證。

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

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

圖1 開銷時間αBT散點圖

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

圖2 下載時間對比

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

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

針對大文件的對比實驗結果如表2所示。

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

表2 大文件下載實驗結果

針對小文件的對比實驗結果如表3所示。

表3 小文件下載實驗結果

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

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

4 結語

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

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。 基金項目:國家自然科學基金資助項目(61262017)。

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

1001-9081(2017)01-0031-06

10.11772/j.issn.1001-9081.2017.01.0031

TP393.02

A