融合P2P技術的云平臺快速內容分發方法

劉 靖，趙文舉

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

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

融合P2P技術的云平臺快速內容分發方法

劉 靖*，趙文舉

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

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

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

內容分發；Peer-to-Peer；服務質量；OpenStack；云存儲

0 引言

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

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

本文為了有效解決大量云服務客戶端在短時間內向云存儲服務器發出并發文件數據傳輸的請求，造成云服務端帶寬壓力過大、客戶端下載過慢的問題，提出了一種融合BT協議與傳統HTTP傳輸技術的云平臺快速內容分發方法，主要內容包括：綜合選取多種協議轉換度量指標并給出其具體計算方法，在此基礎上，給出云平臺中數據內容分發時HTTP和BitTorrent協議之間的協議動態轉換方法，用來實現高效的內容下載分發過程，并基于OpenStack云平臺實現了上述動態協議轉換方法。通過實驗將本文所提方法與純使用HTTP或BT協議下載方式對比，論證本文所提方法能夠保證客戶端用戶獲得較短的文件下載時間，同時有效降低了云服務商帶寬消耗。

1 快速內容分發參考度量指標選取及定義

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

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

1.1 時間收益

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

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

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

(1)

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

1.1.1BT協議下小文件分發時間的估算

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

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

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

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

(2)

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

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

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

(3)

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

1.1.2 時間收益

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

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

(4)

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

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

(5)

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

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

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

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

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

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

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

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

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

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

(6)

1.2 帶寬收益的計算

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

(7)

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

(8)

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

(9)

1.3 用戶類型與服務質量

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

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

2 動態協議轉換方法的設計

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

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

動態協議轉換算法具體實現步驟如下。

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

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

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

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

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

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

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

步驟6 繼續以HTTP進行文件傳輸。

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

協議轉化算法中關鍵步驟的偽代碼描述如下：

if(user_type=Pay_user)

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

//生成種子文件launchaBTseedinthecloud

//啟動云種子節點forallusersrequestingdoleechersgetthe.torrentfilefromthecloudstartBTtransferring

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

else download file via HTTP

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

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

//啟動云種子節點 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

}

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

3 動態協議轉換方法的實現及對比實驗

3.1 實現環境配置

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

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

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

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

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

至此所有的環境和開發部署工具已經準備好，將實驗代碼編寫到Ecliplise中進行調試，便可對動態協議轉換算法進行實現和分析。

3.2 實現關鍵技術

融合P2P協議的云平臺分發機制實現關鍵技術主要有三點：1)系統各參數的收集及傳遞；2)Swift組件代理節點Proxy請求轉發的改變；3)云平臺中BT傳輸的實現。下文分別對這3點關鍵技術進行闡述。

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

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

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

3.3 對比實驗結果與分析

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

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

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

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

圖1 開銷時間αBT散點圖

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

圖2 下載時間對比

2)動態協議轉換方法有效性的驗證。

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

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

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

表2 大文件下載實驗結果

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

表3 小文件下載實驗結果

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

綜上，無論分發大文件還是小文件，本文提出動態協議轉換方法總是選擇最優的數據傳輸協議進行分發，能夠有效降低用戶的下載時間，并且獲得很好的帶寬收益。

4 結語

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

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—)，男，內蒙古呼和浩特人，副教授，博士，CCF高級會員，主要研究方向：云計算、軟件測試； 趙文舉(1990—)，男，河南永城人，碩士研究生，主要研究方向：云計算、網絡協議。

1001-9081(2017)01-0031-06

10.11772/j.issn.1001-9081.2017.01.0031

TP393.02

A