個(gè)人云存儲(chǔ)體驗(yàn)質(zhì)量測(cè)量工具的設(shè)計(jì)與實(shí)現(xiàn)

袁斌　黎文偉

摘要：

隨著用戶日益增長(zhǎng)的網(wǎng)絡(luò)存儲(chǔ)需求，涌現(xiàn)出了大量個(gè)人云存儲(chǔ)（PCS）服務(wù)平臺(tái)。個(gè)人云存儲(chǔ)終端用戶使用過程中體驗(yàn)質(zhì)量（QoE）的測(cè)量是終端用戶和服務(wù)提供商所共同關(guān)注的問題。通過從控制流與數(shù)據(jù)流之間的不同特性方面分析了影響個(gè)人云存儲(chǔ)體驗(yàn)質(zhì)量的因素，從終端用戶的角度提出了能合理評(píng)估個(gè)人云存儲(chǔ)體驗(yàn)質(zhì)量的指標(biāo)，設(shè)計(jì)了精確測(cè)量體驗(yàn)質(zhì)量評(píng)估指標(biāo)的方法。利用被動(dòng)測(cè)量技術(shù)，實(shí)現(xiàn)了一個(gè)面向終端用戶的個(gè)人云存儲(chǔ)服務(wù)體驗(yàn)質(zhì)量測(cè)量工具，同時(shí)給出了工具實(shí)現(xiàn)中的進(jìn)程抓包、網(wǎng)絡(luò)流分類等問題的解決方案。實(shí)驗(yàn)結(jié)果表明，測(cè)量工具運(yùn)行健壯，測(cè)量數(shù)據(jù)準(zhǔn)確，可以用于從用戶終端測(cè)量個(gè)人云存儲(chǔ)服務(wù)QoE。

關(guān)鍵詞：

個(gè)人云存儲(chǔ)；被動(dòng)測(cè)量；體驗(yàn)質(zhì)量；測(cè)量工具

中圖分類號(hào)：

TP393.06

文獻(xiàn)標(biāo)志碼：A

Abstract：

With the growing requirements of users in network storage， a large number of Personal Cloud Storage （PCS） service platforms are emerging. The Quality of Experience （QoE） perceived by the end users has become the common concerned issues of both end users and service providers. The factors that affect QoE in personal cloud storage were analyzed from the aspects of the different features between control flows and data flows. Several indicators were proposed from the end users perspectives which can reasonably evaluate the QoE of personal cloud storage. The accurate measurement method of the QoE indicators was designed. The measuring tool for QoE of personal cloud services was implemented based on passive measurement； at the same time， the solution was given to solve the issues in tool implementation like special process capture packets and network flow classification. The experimental result shows that the measuring tool can run robust and obtain accurate results， it can be used to measure the QoE of personal cloud services in terminals.

英文關(guān)鍵詞Key words：

Personal Cloud Storage （PCS）； passive measurement； Quality of Experience （QoE）； measuring tool

0引言

個(gè)人云存儲(chǔ)服務(wù)（Personal Cloud Storage， PCS）作為互聯(lián)網(wǎng)中的一種數(shù)據(jù)密集型應(yīng)用程序，能為用戶提供在云中的服務(wù)器存儲(chǔ)文件和不同設(shè)備間同步文件的服務(wù)[1]。對(duì)于用戶，越來(lái)越多的人被這些服務(wù)所吸引，因?yàn)榭梢院?jiǎn)單地用來(lái)保存文件，同步設(shè)備。而服務(wù)繁多的市場(chǎng)使得用戶選擇一款合適的服務(wù)來(lái)滿足他們的需求也變得愈發(fā)困難。在樂觀的市場(chǎng)推動(dòng)下，多個(gè)新的服務(wù)提供商悄然進(jìn)入了市場(chǎng)。新的提供商必須與傳統(tǒng)的提供商，比如Dropbox，還有Google、Microsoft、Apple這些IT巨頭競(jìng)爭(zhēng)，他們?cè)谟脩羧汉蛢r(jià)格方面有著更大的優(yōu)勢(shì)[2]。與此同時(shí)，國(guó)內(nèi)也興起了云存儲(chǔ)熱潮，以百度云、快盤、360為首的各大提供商迅速占領(lǐng)了國(guó)內(nèi)大部分的市場(chǎng)。所以，不管是終端用戶還是服務(wù)提供商都需要從理解個(gè)人云存儲(chǔ)中獲益。

用戶體驗(yàn)質(zhì)量（Quality of Experience， QoE）能夠衡量不同服務(wù)所提供的體驗(yàn)差異，能為用戶和服務(wù)提供商在選擇和優(yōu)化服務(wù)方面提供很大的幫助。如果服務(wù)的體驗(yàn)質(zhì)量水平?jīng)]有達(dá)到預(yù)期的期望，用戶可能就會(huì)拒絕繼續(xù)使用[3]。比如說(shuō)，云游戲[4]和虛擬桌面[5]作為兩個(gè)高交互性的云服務(wù)就有著很高的響應(yīng)需求，當(dāng)出現(xiàn)由高延遲引起的體驗(yàn)質(zhì)量下降時(shí)，該服務(wù)對(duì)于用戶的價(jià)值也就會(huì)降低。這個(gè)問題對(duì)于服務(wù)的提供商也變得越來(lái)越具有挑戰(zhàn)性，他們需要知道哪些因素影響著用戶的體驗(yàn)質(zhì)量，進(jìn)而能優(yōu)化自身的服務(wù)。

近年來(lái)對(duì)個(gè)人云存儲(chǔ)已經(jīng)有了很多方面的研究[6-10]：文獻(xiàn)[6]中提出了一個(gè)個(gè)人云存儲(chǔ)的主動(dòng)測(cè)量方法，通過一個(gè)長(zhǎng)期的測(cè)量實(shí)驗(yàn)，分析了三個(gè)流行服務(wù)的傳輸性能，但該方法依賴于提供商的公共API，測(cè)量不同的服務(wù)需要開發(fā)不同的測(cè)量工具；文獻(xiàn)[7]也提出了一種主動(dòng)測(cè)量方法并比較了5個(gè)主流的服務(wù)；文獻(xiàn)[1，8]都通過網(wǎng)絡(luò)中的被動(dòng)測(cè)量研究了特定云服務(wù)和不同用戶的特征。另一方面，當(dāng)前對(duì)個(gè)人云存儲(chǔ)的體驗(yàn)質(zhì)量還只有一些初步的研究：文獻(xiàn)[9]第一次研究了個(gè)人云存儲(chǔ)中的QoE問題，通過用戶的主觀評(píng)價(jià)，研究了網(wǎng)絡(luò)QoS和個(gè)人云存儲(chǔ)QoE之間的相互影響，網(wǎng)絡(luò)時(shí)延和帶寬被認(rèn)為是QoE的兩個(gè)主要影響因素；文獻(xiàn)[3]根據(jù)云服務(wù)的交互程度，分析了不同云服務(wù)體驗(yàn)質(zhì)量的影響因素；文獻(xiàn)[10]通過在線調(diào)查分析出一系列QoE影響因素，同步時(shí)延被認(rèn)為是用戶體驗(yàn)質(zhì)量的一個(gè)重要來(lái)源。但是，除了研究體驗(yàn)質(zhì)量的影響因素，終端用戶所能感知的體驗(yàn)質(zhì)量的測(cè)量也至關(guān)重要，因?yàn)橛脩羲@得的體驗(yàn)質(zhì)量才能真正反映服務(wù)的實(shí)際優(yōu)劣。所以，我們迫切需要開發(fā)出一個(gè)新的方法，使之能夠在終端用戶真實(shí)的使用壞境中來(lái)測(cè)量比較個(gè)人云存儲(chǔ)服務(wù)。

針對(duì)上述問題，本文使用被動(dòng)測(cè)量技術(shù)，設(shè)計(jì)并實(shí)現(xiàn)了一個(gè)面向終端用戶的個(gè)人云存儲(chǔ)QoE測(cè)量工具PCSMeasure。通過分析個(gè)人云存儲(chǔ)的典型傳輸過程，并結(jié)合了個(gè)人云存儲(chǔ)控制流和數(shù)據(jù)流的特征，確定了一系列QoE的測(cè)量指標(biāo)，這些指標(biāo)能很直觀地反映出終端用戶所能獲得的體驗(yàn)質(zhì)量。測(cè)量工具易于使用且具有通用性，測(cè)量過程具有獨(dú)立性。

1個(gè)人云存儲(chǔ)

1.1基本概念和功能

個(gè)人云存儲(chǔ)的主要功能是網(wǎng)絡(luò)存儲(chǔ)，是網(wǎng)絡(luò)技術(shù)與存儲(chǔ)技術(shù)結(jié)合的產(chǎn)物。其實(shí)現(xiàn)原理就是在云中的服務(wù)器硬盤上為每個(gè)用戶開辟一塊空間，然后用戶能夠在此空間上實(shí)現(xiàn)對(duì)文件和目錄的自主管理，從而實(shí)現(xiàn)網(wǎng)絡(luò)環(huán)境下，用戶通過網(wǎng)站或者客戶端軟件對(duì)文件的異地存儲(chǔ)和管理。

個(gè)人云存儲(chǔ)有兩個(gè)常見的模式：Web模式和客戶端模式。這兩種模式所產(chǎn)生的流量有很大的差異，其中Web模式所產(chǎn)生的流量在網(wǎng)絡(luò)中個(gè)人云存儲(chǔ)流量總量中所占的比例非常低。根據(jù)文獻(xiàn)[1]中的研究可知，在四種不同的網(wǎng)絡(luò)環(huán)境中通過Web模式產(chǎn)生的Dropbox流量約占測(cè)量期間捕獲Dropbox總流量的8%～15%。因此，本文選擇對(duì)客戶端模式進(jìn)行QoE測(cè)量方法的研究。

個(gè)人云存儲(chǔ)服務(wù)作為一個(gè)網(wǎng)絡(luò)存儲(chǔ)服務(wù)，給用戶提供了方便的文件存儲(chǔ)和管理，用戶能夠?qū)⑽募w移到云中實(shí)現(xiàn)數(shù)據(jù)的存儲(chǔ)和多設(shè)備共享，還能滿足多用戶的協(xié)作。但是，用戶在使用不同操作時(shí)，會(huì)有著不同的體驗(yàn)需求，當(dāng)服務(wù)無(wú)法滿足用戶的期望時(shí)，就會(huì)降低用戶的體驗(yàn)質(zhì)量。

1.2體系結(jié)構(gòu)

云存儲(chǔ)系統(tǒng)依賴于成千上萬(wàn)的服務(wù)器，核心構(gòu)架由存儲(chǔ)服務(wù)器或者磁盤陣列、文件或者元數(shù)據(jù)服務(wù)器集群、通知服務(wù)器以及Web服務(wù)器集群組成[11]。Web服務(wù)器主要提供身份驗(yàn)證；文件服務(wù)器主要存儲(chǔ)文件的元數(shù)據(jù)、文件位置等信息；通知服務(wù)器用于與客戶端進(jìn)行文件改變的消息通信；云存儲(chǔ)系統(tǒng)存儲(chǔ)設(shè)備包括存儲(chǔ)服務(wù)器、磁盤陣列等設(shè)備。用戶可以通過互聯(lián)網(wǎng)或者局域網(wǎng)對(duì)云存儲(chǔ)系統(tǒng)進(jìn)行訪問。

根據(jù)功能的不同，我們把通知服務(wù)器、Web服務(wù)器和文件服務(wù)器統(tǒng)稱為控制服務(wù)器，存儲(chǔ)服務(wù)器稱為數(shù)據(jù)服務(wù)器。在眾多不同的服務(wù)提供商中，服務(wù)器的部署策略也存在差異，而不同部署策略會(huì)給用戶的體驗(yàn)質(zhì)量帶來(lái)不同的影響。比如分布式部署方式減少了用戶服務(wù)器之間的往返時(shí)延（RoundTrip Time， RTT），能夠更快地完成短鏈接數(shù)據(jù)流的傳輸。

1.3客戶端功能及協(xié)議

為了分析個(gè)人云存儲(chǔ)的QoE影響因素，首先需要了解個(gè)人云存儲(chǔ)的通信協(xié)議。通過捕獲分析不同服務(wù)的數(shù)據(jù)包，結(jié)果顯示大部分國(guó)外服務(wù)提供商會(huì)采用HTTPS協(xié)議即加密傳輸數(shù)據(jù)，只有極少數(shù)服務(wù)的控制信息是通過沒有加密的HTTP協(xié)議來(lái)交換的；而國(guó)內(nèi)多數(shù)的提供商都是使用HTTP協(xié)議來(lái)傳輸數(shù)據(jù)，除了重要的賬號(hào)登錄信息采用的是HTTPS。

個(gè)人云存儲(chǔ)服務(wù)客戶端軟件也會(huì)采用一些高級(jí)功能來(lái)處理用戶數(shù)據(jù)，這些功能能夠優(yōu)化網(wǎng)絡(luò)的使用和提高用戶的體驗(yàn)。這些功能主要包括：

捆綁在同時(shí)操作多個(gè)小文件時(shí)，將多個(gè)小文件作為一個(gè)單獨(dú)的對(duì)象來(lái)傳輸。

累計(jì)編碼只傳輸文件中被修改的部分。

分塊將單個(gè)大體積文件分成多個(gè)最大數(shù)據(jù)單元來(lái)處理。

重復(fù)刪除避免重新上傳已經(jīng)在服務(wù)器可用的內(nèi)容。

壓縮在數(shù)據(jù)傳輸之前進(jìn)行壓縮。

負(fù)載均衡將同一個(gè)文件傳輸?shù)讲煌姆?wù)器。

每個(gè)不同的服務(wù)提供商都可以選擇實(shí)現(xiàn)不同的客戶端功能，這也是造成不同服務(wù)體驗(yàn)質(zhì)量差異的重要來(lái)源。

2測(cè)量方法及指標(biāo)

2.1測(cè)量方法

網(wǎng)絡(luò)測(cè)量根據(jù)是否通過測(cè)量設(shè)備向網(wǎng)絡(luò)中注入額外的測(cè)量流量可以分為主動(dòng)測(cè)量和被動(dòng)測(cè)量。被動(dòng)測(cè)量方法是從網(wǎng)絡(luò)中的某一點(diǎn)收集流量，統(tǒng)計(jì)數(shù)據(jù)包大小分布、組成的協(xié)議分布、數(shù)據(jù)包數(shù)量、字節(jié)數(shù)等信息，據(jù)此計(jì)算出測(cè)量指標(biāo)。被動(dòng)測(cè)量又可以通過三種方式來(lái)實(shí)現(xiàn)：服務(wù)器端測(cè)量、用戶端測(cè)量和利用網(wǎng)絡(luò)探測(cè)。

本文采用的是用戶端的被動(dòng)測(cè)量方式來(lái)完成個(gè)人云存儲(chǔ)QoE的測(cè)量：通過將具有監(jiān)測(cè)功能的工具安裝到用戶終端，從用戶的角度監(jiān)測(cè)待測(cè)服務(wù)。選擇被動(dòng)測(cè)量有以下幾個(gè)優(yōu)點(diǎn)：1）通用性。通過API開發(fā)的云存儲(chǔ)主動(dòng)測(cè)量工具，在測(cè)量不同的服務(wù)時(shí)需要開發(fā)多個(gè)工具，而通過被動(dòng)的捕獲數(shù)據(jù)包來(lái)測(cè)量時(shí)，對(duì)于所有的服務(wù)都是通用的。2）基于數(shù)據(jù)包捕獲的被動(dòng)測(cè)量可以提供不同粒度層次的信息。3）能夠在用戶的實(shí)際使用過程中測(cè)量真實(shí)的結(jié)果。

2.2QoE評(píng)估方法

體驗(yàn)質(zhì)量的評(píng)估方法根據(jù)用戶的參與度可以分為三類：主觀評(píng)價(jià)方法、客觀評(píng)價(jià)方法以及偽主觀評(píng)價(jià)方法。而其中偽主觀評(píng)價(jià)方法結(jié)合了主觀和客觀評(píng)價(jià)方法的優(yōu)點(diǎn)。偽主觀評(píng)價(jià)方法的基本過程是：1）分析業(yè)務(wù)特征，確定QoE相應(yīng)的指標(biāo)；2）確定這些QoE指標(biāo)的影響因素；3）準(zhǔn)備測(cè)試的環(huán)境以及測(cè)試的樣本；4）選擇測(cè)試用戶，進(jìn)行服務(wù)的評(píng)價(jià)，獲取數(shù)據(jù)；5）利用數(shù)據(jù)，選擇合適的數(shù)據(jù)模型將QoE與指標(biāo)關(guān)聯(lián)，得到合理的評(píng)估模型。

本文的工作就是在完成1）、2）步，并為后續(xù)模型的研究設(shè)計(jì)一個(gè)測(cè)量工具。偽主觀的評(píng)價(jià)方法因?yàn)橛兄y(tǒng)計(jì)學(xué)和人工智能等學(xué)科的理論支持，而且有著很高的準(zhǔn)確度，目前越來(lái)越受到研究人員的關(guān)注。

2.3典型傳輸過程分析

在被動(dòng)測(cè)量方法中如何選擇QoE測(cè)量指標(biāo)非常重要。而終端用戶的不同操作或傳輸?shù)牟煌A段都有著不同的影響因素，用戶也有著不同的體驗(yàn)要求，需要使用不同的測(cè)量指標(biāo)。因此，接下來(lái)對(duì)個(gè)人云存儲(chǔ)的典型傳輸過程進(jìn)行分析。

如圖1所示，描述了典型個(gè)人云存儲(chǔ)的傳輸過程。個(gè)人云存儲(chǔ)的典型同步過程可以分為兩部分：客戶端啟動(dòng)過程和文件同步過程?？蛻舳藛?dòng)過程是指在用戶啟動(dòng)客戶端到云存儲(chǔ)中的文件夾實(shí)際顯示，文件同步過程是指當(dāng)用戶發(fā)起對(duì)文件操作到操作完成。具體的過程可以分為三步：

1）客戶端與控制服務(wù)器交換文件的元數(shù)據(jù)信息。

2）觸發(fā)文件的存儲(chǔ)操作，客戶端與數(shù)據(jù)服務(wù)器通過數(shù)據(jù)流直接完成數(shù)據(jù)的傳輸。

3）當(dāng)數(shù)據(jù)成功傳輸完畢后，客戶端再次與控制服務(wù)器交換控制信息，來(lái)完成此次傳輸事務(wù)。

另外，在空閑階段（即沒有任何操作時(shí)）客戶端會(huì)與通知服務(wù)器保持信息的交換，用于通知客戶端存儲(chǔ)在服務(wù)器中的文件是否變化。

2.4QoE的影響因素

全面研究QoE的影響因素對(duì)于測(cè)量指標(biāo)的確定非常重要，因?yàn)镼oE測(cè)量的根本目的就是根據(jù)不同方面的影響因素來(lái)得到用戶的QoE。本文將QoE的影響因素分為三個(gè)方面：網(wǎng)絡(luò)方面、客戶端方面以及系統(tǒng)平臺(tái)方面。

如圖2所示，描述了個(gè)人云存儲(chǔ)的體驗(yàn)質(zhì)量被多方面的客觀因素所影響。網(wǎng)絡(luò)方面的參數(shù)主要反映網(wǎng)絡(luò)傳輸?shù)臓顩r，如網(wǎng)絡(luò)帶寬、延遲；客戶端方面反映的是沒有經(jīng)過網(wǎng)絡(luò)傳輸?shù)姆?wù)體驗(yàn)，包括一系列的優(yōu)化機(jī)制；系統(tǒng)設(shè)計(jì)方面，主要包括傳輸協(xié)議、帶寬控制及服務(wù)器的部署方式等。

其中，每一種影響因素都以一種復(fù)雜的方式影響著服務(wù)的體驗(yàn)質(zhì)量。比如說(shuō)，用戶所感受到的數(shù)據(jù)傳輸體驗(yàn)很可能是由于網(wǎng)絡(luò)的帶寬過小或者客戶端服務(wù)器往返時(shí)延太大造成數(shù)據(jù)流吞吐量很小，也可能是因?yàn)榉?wù)客戶端并沒有采用優(yōu)化傳輸?shù)墓δ?。另外，操作的響?yīng)體驗(yàn)也是由網(wǎng)絡(luò)環(huán)境、客戶端功能、系統(tǒng)設(shè)計(jì)等多種客觀因素所影響的。

2.5主要測(cè)量指標(biāo)

由于個(gè)人云存儲(chǔ)QoE的客觀影響因素的多方面性，使得在被動(dòng)測(cè)量中準(zhǔn)確測(cè)量并量化所有客觀因素非常困難。所以，本文通過結(jié)合個(gè)人云存儲(chǔ)的不同影響因素和不同網(wǎng)絡(luò)流的特征，分析出多個(gè)能夠準(zhǔn)確評(píng)估終端用戶QoE的指標(biāo)。下面各指標(biāo)計(jì)算公式中的時(shí)間戳，如2.3節(jié)中的圖1所示。

1）客戶端啟動(dòng)時(shí)延。

客戶端啟動(dòng)時(shí)延Dc是指云存儲(chǔ)客戶端啟動(dòng)到客戶端的文件夾完全顯示之間的時(shí)延。計(jì)算公式如（1）所示：

Dc=T1-T0（1）

其中：T0表示服務(wù)進(jìn)程出現(xiàn)的時(shí)間；T1表示最后一個(gè)數(shù)據(jù)包到達(dá)的時(shí)延。

2）同步初始化時(shí)延。

同步初始化時(shí)延Ds是指在同步操作執(zhí)行到文件數(shù)據(jù)流正式開始傳輸之間的時(shí)延。Ds在有些使用場(chǎng)景下對(duì)用戶的體驗(yàn)非常重要，比如單獨(dú)傳輸小體積文件時(shí)。同步初始化時(shí)延通過式（2）計(jì)算：

Ds=T3-T2（2）

其中：T2為第一條控制流的建立時(shí)間；T3為第一條數(shù)據(jù)流的建立時(shí)間。

3）傳輸數(shù)據(jù)總量。

傳輸數(shù)據(jù)總量St是指整個(gè)同步過程中所有網(wǎng)絡(luò)流的體積總和。對(duì)于流量敏感的用戶而言，能夠用盡可能少的流量完成文件的傳輸能提升體驗(yàn)質(zhì)量。傳輸數(shù)據(jù)總量的計(jì)算方法如式（3）所示：

St=∑ni=1Di+∑mj=1Cj（3）

其中：Di和Cj分別表示每條數(shù)據(jù)流和控制流的大小，n和m分別表示數(shù)據(jù)流和控制流的數(shù)目。

4）數(shù)據(jù)傳輸速率。

數(shù)據(jù)傳輸速率DTS是指同步過程中傳輸?shù)臄?shù)據(jù)流總量與數(shù)據(jù)流的持續(xù)總時(shí)間之間的比值。它是描述個(gè)人云存儲(chǔ)體驗(yàn)質(zhì)量的重要參數(shù)，也是評(píng)估長(zhǎng)期體驗(yàn)傳輸變化性的一個(gè)基礎(chǔ)。數(shù)據(jù)傳輸速率的計(jì)算方法如式（4）所示：

DTS=∑ni=1Di/（T4-T3）（4）

其中：Di表示數(shù)據(jù)流的大?。籘3表示第一條數(shù)據(jù)流的建立時(shí)間；T4表示最后一個(gè)數(shù)據(jù)流數(shù)據(jù)包的捕獲時(shí)間，我們忽略了數(shù)據(jù)流斷開和最后的控制信息交換時(shí)間。

5）控制開銷率。

控制開銷率COR是用于衡量傳輸一定大小的文件所需控制流開銷的指標(biāo)。值越大說(shuō)明傳輸相同體積的數(shù)據(jù)需要更多的控制開銷。計(jì)算方法如式（5）所示：

COR=St/∑ni=1Di（5）

其中：St表示指標(biāo)（3）中的傳輸數(shù)據(jù)總量，Di表示數(shù)據(jù)流的大小。

3測(cè)量工具的實(shí)現(xiàn)

3.1工具設(shè)計(jì)

在選擇了QoE的測(cè)量指標(biāo)、確定了被動(dòng)測(cè)量方法后，接

下來(lái)進(jìn)行工具PCSMeasure的設(shè)計(jì)和實(shí)現(xiàn)。工具PCSMeasure的結(jié)構(gòu)如圖3所示，主要由三個(gè)模塊組成：第一個(gè)模塊是數(shù)據(jù)包捕捉模塊Packets Sniffer，通過調(diào)用數(shù)據(jù)包處理驅(qū)動(dòng)WinPcap捕獲待測(cè)服務(wù)的所有數(shù)據(jù)包；第二個(gè)模塊是網(wǎng)絡(luò)流分析模塊Traffic Analysis，根據(jù)已有的數(shù)據(jù)包完成控制流和數(shù)據(jù)流的分類；最后一個(gè)模塊是指標(biāo)計(jì)算模塊Metrics Computation。

PCSMeasure工具主要模塊的功能如下：

1）Packets Sniffer：獨(dú)立的網(wǎng)絡(luò)抓包模塊。接收WinPcap捕獲的數(shù)據(jù)包，進(jìn)行逐層解碼，完成協(xié)議分析統(tǒng)計(jì)和數(shù)據(jù)包的本地化。該模塊是被動(dòng)測(cè)量工具的主體。

2）Traffic Analysis：網(wǎng)絡(luò)流分析模塊。分析上層模塊捕獲的數(shù)據(jù)包，根據(jù)五元組信息，統(tǒng)計(jì)所有的網(wǎng)絡(luò)流信息，包括網(wǎng)絡(luò)流的開始時(shí)間、持續(xù)時(shí)間、數(shù)據(jù)包個(gè)數(shù)和網(wǎng)絡(luò)流大小等。根據(jù)網(wǎng)絡(luò)流的特征信息，使用聚類算法將網(wǎng)絡(luò)流分為數(shù)據(jù)流和控制流。

3）Metrics Computation：指標(biāo)計(jì)算模塊。根據(jù)上層的網(wǎng)絡(luò)流分析結(jié)果結(jié)合個(gè)人云存儲(chǔ)的傳輸過程，計(jì)算出測(cè)量指標(biāo)；同時(shí)，將計(jì)算出的結(jié)果反饋給用戶并完成本地化。

在三個(gè)模塊中，Packets Sniffer模塊和Traffic Analysis模塊是Metrics Compute模塊的基礎(chǔ)，測(cè)量結(jié)果的準(zhǔn)確性也完全取決于這兩個(gè)模塊。如果Packets Sniffer模塊中沒有正確捕捉到服務(wù)的數(shù)據(jù)包就會(huì)給測(cè)量結(jié)果帶來(lái)誤差；而Traffic Analysis模塊中的網(wǎng)絡(luò)流分類不準(zhǔn)確時(shí)，甚至?xí)苯訉?dǎo)致測(cè)量結(jié)果錯(cuò)誤。

下面分別來(lái)討論這兩個(gè)問題的解決方法。

3.2服務(wù)進(jìn)程抓包

在Packets Sniffer模塊中進(jìn)行網(wǎng)絡(luò)數(shù)據(jù)包捕獲時(shí)，通過調(diào)用數(shù)據(jù)包處理驅(qū)動(dòng)WinPcap的接口函數(shù)，將網(wǎng)卡設(shè)置為混雜模式，數(shù)據(jù)包經(jīng)過兩次內(nèi)存拷貝和系統(tǒng)調(diào)用，到達(dá)用戶空間[12]。但是在終端用戶使用環(huán)境中，存在著不同網(wǎng)絡(luò)進(jìn)程的數(shù)據(jù)包。準(zhǔn)確捕捉到待測(cè)服務(wù)進(jìn)程的數(shù)據(jù)包對(duì)于計(jì)算測(cè)量指標(biāo)就變得非常重要。

雖然Winpcap并沒有直接提供捕捉不同進(jìn)程數(shù)據(jù)包的函數(shù)接口，但是Winpcap的一個(gè)強(qiáng)大特性是提供了過濾引擎。通過將相關(guān)的過濾器應(yīng)用到所有來(lái)自網(wǎng)絡(luò)的數(shù)據(jù)包上，所有與過濾器特性一致的數(shù)據(jù)包將被復(fù)制給應(yīng)用程序。因此，提出了一種基于Winpcap過濾機(jī)制的雙緩存進(jìn)程抓包方法。該方法的有效性基于所有個(gè)人云存儲(chǔ)的傳輸層都是使用TCP協(xié)議這一假設(shè)。

捕獲特定進(jìn)程的數(shù)據(jù)包最為直接的方法是能獲取目標(biāo)進(jìn)程所有網(wǎng)絡(luò)連接的端口，然后將Winpcap的過濾器設(shè)置為特定進(jìn)程的端口號(hào)。但是，這個(gè)方法存在兩個(gè)問題：

1）在實(shí)際的服務(wù)傳輸過程中TCP連接的建立是隨機(jī)的，所以，需要?jiǎng)討B(tài)地查詢目標(biāo)進(jìn)程的端口列表，當(dāng)發(fā)現(xiàn)出現(xiàn)新的連接時(shí)，動(dòng)態(tài)更新過濾器。

2）在動(dòng)態(tài)更新過濾器的過程中，又可能在兩次更新過濾器期間出現(xiàn)新的TCP連接，導(dǎo)致漏包現(xiàn)象。針對(duì)這個(gè)問題，提出了一種雙緩存機(jī)制。雙緩存機(jī)制是指，通過開啟兩個(gè)抓包線程，創(chuàng)建兩個(gè)數(shù)據(jù)包緩存區(qū)，分別對(duì)應(yīng)不同的過濾規(guī)則。在每次更新過濾器前，通過綜合兩個(gè)線程緩存區(qū)中的數(shù)據(jù)包來(lái)完整地捕獲到進(jìn)程在這個(gè)周期內(nèi)的數(shù)據(jù)包。

根據(jù)以上分析，PCSMeasure進(jìn)程抓包的具體步驟如下：

1）獲取網(wǎng)卡接口和目標(biāo)進(jìn)程信息。開始測(cè)量后，首先創(chuàng)建兩個(gè)抓包線程C1和C2，同時(shí)都調(diào)用Winpcap所提供的pcap_open_live（）方法，用于打開網(wǎng)絡(luò)設(shè)備準(zhǔn)備捕捉網(wǎng)絡(luò)數(shù)據(jù)，分別返回adhandle1和adhandle2兩個(gè)用于捕獲網(wǎng)絡(luò)數(shù)據(jù)包的數(shù)據(jù)包捕獲描述字。對(duì)于這個(gè)網(wǎng)絡(luò)接口的操作都要基于此描述字。

2）分別調(diào)用Winpcap所提供的函數(shù)pcap_setfilter（）給C1、C2設(shè)置過濾規(guī)則。其中C1的過濾器filter1設(shè)置為“TCP”。在C2中使用輪詢機(jī)制，通過定時(shí)查詢目標(biāo)進(jìn)程所有連接的端口號(hào)集合，根據(jù)端口號(hào)集合動(dòng)態(tài)地更新過濾器filter2。

3）當(dāng)在ti更新filter2時(shí)，首先調(diào)用自定義的函數(shù)GetAllPortsByID（）根據(jù)進(jìn)程ID查詢目標(biāo)進(jìn)程最新連接的端口集合，將結(jié)果與ti-1查詢的端口集合比較。當(dāng)出現(xiàn)了新的端口號(hào)時(shí)，表示在ti-1～ti周期內(nèi)出現(xiàn)了新的連接并且C2漏掉了這些新連接在ti-1～ti周期內(nèi)傳輸?shù)臄?shù)據(jù)包。所以，根據(jù)新的端口號(hào)在C1的緩沖區(qū)中找出新連接的所有數(shù)據(jù)包，加上C2緩沖區(qū)內(nèi)的數(shù)據(jù)包就是目標(biāo)進(jìn)程在ti-1～ti周期內(nèi)完整的數(shù)據(jù)包。最后清空C1與C2緩沖區(qū)，更新C2的過濾器。

4）接下來(lái)討論C2的過濾器更新周期Ti。通過分析TCP的連接可知，一個(gè)最簡(jiǎn)單的網(wǎng)絡(luò)流是由三次握手、POST+ACK、DATA+ACK和RST組成。因此Ti的最大值Tmax不能大于2RTT，才能保證在過濾器更新期間不會(huì)漏掉整個(gè)網(wǎng)絡(luò)流的所有數(shù)據(jù)包。而出于對(duì)進(jìn)程端口查詢開銷的考慮，將Tmin設(shè)置為30ms。

5）最后討論Ti的變化策略。根據(jù)人工分析云存儲(chǔ)的網(wǎng)絡(luò)流變化發(fā)現(xiàn)，網(wǎng)絡(luò)連接的建立都是具有突發(fā)性的，即會(huì)在短時(shí)間同時(shí)建立多條新的連接，當(dāng)數(shù)據(jù)傳輸穩(wěn)定后，就會(huì)很少有新的連接建立。所以根據(jù)兩次端口查詢結(jié)果之間的差異來(lái)決定Ti的變化：當(dāng)兩次端口查詢期間ti-1～ti沒有出現(xiàn)新的連接時(shí)，Ti以線性增長(zhǎng)直至Tmax；當(dāng)在ti-1～ti出現(xiàn)新的連接時(shí)，Ti賦值為Max（Ti / 2， Tmin）。

3.3個(gè)人云存儲(chǔ)流量分析

個(gè)人云存儲(chǔ)的控制流和數(shù)據(jù)流作為計(jì)算測(cè)量指標(biāo)的基礎(chǔ)。在Traffic Analysis模塊中，區(qū)分出測(cè)量過程中的所有控制流和數(shù)據(jù)流也是一個(gè)重點(diǎn)。數(shù)據(jù)流和控制流的主要不同就是傳輸數(shù)據(jù)內(nèi)容的不同，可是無(wú)法通過捕獲的數(shù)據(jù)包直接區(qū)分出不同服務(wù)的數(shù)據(jù)流和控制流。因此，我們基于個(gè)人云存儲(chǔ)數(shù)據(jù)流和控制流的特征差異，提出了一個(gè)改進(jìn)初始聚類中心的kmeans聚類方法。

首先，主動(dòng)通過分析捕獲到的不同個(gè)人云存儲(chǔ)服務(wù)的數(shù)據(jù)包，發(fā)現(xiàn)數(shù)據(jù)流與控制流存在兩個(gè)重要的差異特征：有效數(shù)據(jù)包（除ACK）的平均載荷和數(shù)據(jù)包的個(gè)數(shù)。1）數(shù)據(jù)流平均載荷大部分會(huì)大于當(dāng)前網(wǎng)絡(luò)的最大傳輸單元（Maximum Transmission Unit， MTU），比如以太網(wǎng)中是1514字節(jié)，而控制流通常會(huì)小于1000字節(jié)；2）由于控制流通常傳遞的信息量較少，常常只是幾個(gè)或者幾十個(gè)數(shù)據(jù)包，而數(shù)據(jù)流的數(shù)據(jù)包個(gè)數(shù)則和文件的大小有關(guān)，一般都有幾百個(gè)。

如圖4所示，例舉了百度云和Google Drive在上傳10個(gè)100KB文件時(shí)網(wǎng)絡(luò)流的特征分布，所以我們可以采用聚類方法實(shí)現(xiàn)網(wǎng)絡(luò)流的分類。

其次，傳統(tǒng)的kmeans聚類方法采用隨機(jī)選擇初始聚類中心的方式，當(dāng)結(jié)果簇是密集的而且簇之間的區(qū)分明顯時(shí)，它的效果較好。但是個(gè)人云存儲(chǔ)的網(wǎng)絡(luò)流分布呈現(xiàn)兩極現(xiàn)象：數(shù)據(jù)流多分布較為密集；而控制流因?yàn)樽饔玫牟町?，不同控制流的?shù)據(jù)包個(gè)數(shù)和平均載荷都各不相同，造成控制流的分布相對(duì)較為分散。所以采用隨機(jī)選擇初始聚類中心可能會(huì)導(dǎo)致聚類收斂速度慢、聚類效果差的問題。

針對(duì)這個(gè)問題，本文改進(jìn)了kmeans 聚類算法初始中心的選擇方法。

1）針對(duì)數(shù)據(jù)流的密集分布特征，并且根據(jù)控制流應(yīng)該離數(shù)據(jù)流中心盡可能遠(yuǎn)這一原則，選擇數(shù)據(jù)包個(gè)數(shù)與有效大小乘積最大的流作為數(shù)據(jù)流的初始中心，從而盡可能避免可能出現(xiàn)的控制流距離數(shù)據(jù)流初始中心更近的情況。

2）根據(jù)控制流分布分散的特點(diǎn)，控制流的初始中心根據(jù)最小相似度方法來(lái)確定。首先給出網(wǎng)絡(luò)流相似度的定義，

S（xi，xj）=1/∑2t=1（xit-xjt）2（6）

其中：xi， xj分別為網(wǎng)絡(luò)流樣本，xit表示樣本的兩個(gè)特征分量?？刂屏鞒跏贾行牡倪x擇方法如下：

步驟1新建鏈表L。以數(shù)據(jù)流初始中心為起點(diǎn)，找出與它相似度最高的樣本對(duì)象xtemp，存入鏈表L，并記住該相似度Smin和該樣本xmin。

步驟2找出其他剩下的樣本中（鏈表外的）與xtemp最相似的，同樣賦值給xtemp，并加入鏈表L，當(dāng)它們的相似度Stemp小于Smin時(shí)，將Stemp、xtemp分別賦值Smin、xmin。

步驟3重復(fù)步驟2，直到遍歷完所有樣本對(duì)象。

至此，從數(shù)據(jù)流初始中心開始，找出了最小的樣本間相似度Smin及該樣本xmin。所以，鏈表L中排在xmin后的樣本就是最有可能為控制流的，因此控制流初始中心設(shè)置為這些樣本的平均值。

3.4測(cè)量流程

圖5描述了PCSMeasure被動(dòng)測(cè)量個(gè)人云存儲(chǔ)QoE指標(biāo)的流程。首先開啟測(cè)量工具，選擇需要測(cè)量的服務(wù)進(jìn)程；當(dāng)執(zhí)行相關(guān)操作時(shí)，工具就會(huì)捕獲該進(jìn)程的數(shù)據(jù)包，同時(shí)分析捕獲到的數(shù)據(jù)包；當(dāng)數(shù)據(jù)傳輸完畢，工具會(huì)通過分析捕獲的數(shù)據(jù)包，統(tǒng)計(jì)網(wǎng)絡(luò)流的信息并完成網(wǎng)絡(luò)流的分類；最后，計(jì)算出測(cè)量指標(biāo)并將結(jié)果反饋給用戶。

在測(cè)量完成后，結(jié)果被保存在一個(gè)以服務(wù)進(jìn)程名和時(shí)間命名的文本文件中。文件中不僅記錄了相關(guān)的指標(biāo)數(shù)據(jù)，還包括所有的流信息，可以用于分析及優(yōu)化個(gè)人云存儲(chǔ)的QoE。

4測(cè)量工具的應(yīng)用

百度云已經(jīng)發(fā)展成為國(guó)內(nèi)用戶最多的服務(wù)提供商，而Google Drive是全球最流行的個(gè)人云存儲(chǔ)服務(wù)提供商，故本文的實(shí)驗(yàn)選擇百度云和Drive Google作為測(cè)量對(duì)象。

4.1實(shí)驗(yàn)方案

為了驗(yàn)證工具的有效性和比較工具的測(cè)量結(jié)果，設(shè)計(jì)了一個(gè)實(shí)驗(yàn)方案，實(shí)驗(yàn)平臺(tái)如圖6所示。實(shí)驗(yàn)平臺(tái)搭建在一臺(tái)普通的PC上，并在其中安裝有多個(gè)待測(cè)服務(wù)客戶端、測(cè)量工具PCSMeasure和常用的數(shù)據(jù)包捕獲分析軟件Wireshark。

在實(shí)驗(yàn)中，當(dāng)用戶在待測(cè)服務(wù)客戶端執(zhí)行某個(gè)操作后，測(cè)量工具PCSMeasure和Wireshark能夠同時(shí)捕捉到待測(cè)服務(wù)的

數(shù)據(jù)包。通過比較PCSMeasure的測(cè)量結(jié)果和Wireshark的手動(dòng)分析結(jié)果來(lái)驗(yàn)證工具的有效性，然后分別測(cè)量不同的個(gè)人云存儲(chǔ)服務(wù)，通過使用我們的工具測(cè)量比較了不同云存儲(chǔ)服務(wù)的并對(duì)比測(cè)量結(jié)果，對(duì)測(cè)量結(jié)果進(jìn)行簡(jiǎn)要的分析。

4.2工具的有效性

在測(cè)量工具PCSMeasure的指標(biāo)計(jì)算中，最后測(cè)量結(jié)果的有效性取決于兩個(gè)方面，分別是完整地抓取待測(cè)服務(wù)進(jìn)程的數(shù)據(jù)包和正確的網(wǎng)絡(luò)流分類結(jié)果，因此分別從這兩個(gè)方面比較了測(cè)量工具PCSMeasure和Wireshark。

如圖7所示，分別描述百度云和Google Drive在傳輸不同大小的文件時(shí)PCSMeasure和Wireshark捕獲到的數(shù)據(jù)包個(gè)數(shù)。Google Drive的數(shù)據(jù)包漏包率相對(duì)比較小，主要集中在2%～3%；而百度云就相對(duì)要高一些，尤其在傳輸更大（如5MB）文件時(shí)漏包率達(dá)到了7%。

出現(xiàn)這種情況的原因可能是因?yàn)閃inpcap在捕獲數(shù)據(jù)包時(shí)，需要經(jīng)過兩次拷貝將數(shù)據(jù)包從內(nèi)核緩存中轉(zhuǎn)移到用戶空間的緩存區(qū)，當(dāng)執(zhí)行一次過濾器更新周期后，從用戶緩沖區(qū)獲取數(shù)據(jù)包時(shí)，內(nèi)核緩存中還存在少量數(shù)據(jù)包沒有拷貝到用戶空間。這將會(huì)降低測(cè)量結(jié)果的準(zhǔn)確性，也是我們下一步改進(jìn)的主要工作。

4.3個(gè)人云存儲(chǔ)QoE測(cè)量結(jié)果

最后，使用PCSMeasure測(cè)量比較了百度云和Google Drive在傳輸不同類型文件時(shí)的QoE指標(biāo)結(jié)果。表2總結(jié)了我們測(cè)量實(shí)驗(yàn)的全部結(jié)果。

由表2中的數(shù)據(jù)可以知道兩種個(gè)人云存儲(chǔ)服務(wù)在QoE上有很大的差異。首先，由于Google的控制服務(wù)器都部署在國(guó)外，造成Google Drive控制流的平均RTT是百度云的近十倍。這也就使得Google Drive的客戶端啟動(dòng)時(shí)延和同步控制時(shí)延都比百度云要大很多。其中同步控制時(shí)延中出現(xiàn)一個(gè)特殊值，Google Drive在上傳單個(gè)5MB的文件時(shí)同步控制時(shí)延為0。這是因?yàn)镚oogle Drive在傳輸大體積文件時(shí)將文件分割成每單位8MB傳輸，而且當(dāng)Google Drive傳輸單個(gè)小于8MB的文件傳輸時(shí)，文件的控制信息是直接通過數(shù)據(jù)流傳輸?shù)椒?wù)器，因此出現(xiàn)了控制時(shí)延為0的情況；而百度云是以4MB為單位傳輸，所以傳輸單個(gè)5MB文件時(shí)分割成兩個(gè)數(shù)據(jù)單元傳輸。上傳過程和下載也有差異，當(dāng)下載批次文件時(shí)明顯需要更多控制信息，所以需要更長(zhǎng)的同步控制時(shí)延。

其次，百度云在傳輸表2中后三種類型的文件時(shí)，上傳的數(shù)據(jù)總量總是大于Google Drive，這主要是由于Google Drive在上傳文件前會(huì)進(jìn)行壓縮以減少流量的消耗，這對(duì)于流量敏感的用戶而言是能提高體驗(yàn)質(zhì)量的。但是由于Google Drive沒有使用捆綁機(jī)制，當(dāng)上傳大量小文件時(shí)會(huì)為每個(gè)文件開啟一條控制流交換文件元數(shù)據(jù)，所以在上傳100個(gè)10KB的文件時(shí)，Google Drive最后傳輸?shù)臄?shù)據(jù)總量反而大于百度云的數(shù)據(jù)總量。而下載過程中，由于兩個(gè)云存儲(chǔ)的服務(wù)器在傳輸文件之前都沒有使用壓縮處理，使得下載時(shí)傳輸?shù)臄?shù)據(jù)總量都大于文件本身的大小。

在全部四種文件類型中，不管是上傳還是下載百度云的數(shù)據(jù)傳輸速率都比Google Drive的大，這也是由于Google Drive數(shù)據(jù)流的平均RTT比百度云數(shù)據(jù)流的RTT更大，使得Google Drive每條數(shù)據(jù)流的平均吞吐量很小。

最后我們觀察到，當(dāng)上傳100個(gè)10KB的文件時(shí)，兩個(gè)服務(wù)都有較高的控制開銷率。 Google Drive的控制開銷率為1.13，這是由于Google Drive沒有采用捆綁機(jī)制，使得每個(gè)文件都需要有與控制服務(wù)器交換信息。但是，百度云即使采用了捆綁機(jī)制，控制開銷也達(dá)到了1.44。通過分析百度云的控制流發(fā)現(xiàn)，雖然傳輸過程只有5條控制流，但是每條控制流都會(huì)與服務(wù)器進(jìn)行多次數(shù)據(jù)交換，為每個(gè)文件提交元數(shù)據(jù)。同樣情況也出現(xiàn)在百度云的下載過程中，使得百度云在下載時(shí)控制開銷也達(dá)到了1.46。因此，百度云可以通過優(yōu)化控制信息的交換策略來(lái)降低控制信息的開銷，以提高用戶的體驗(yàn)質(zhì)量。

PCSMeasure可以被動(dòng)測(cè)量個(gè)人云存儲(chǔ)服務(wù)，在下一步研究中，可以選擇測(cè)試用戶，使用PCSMeasure進(jìn)行服務(wù)的評(píng)價(jià)，獲取數(shù)據(jù)。利用這些數(shù)據(jù)，選擇合適的數(shù)據(jù)模型將QoE與指標(biāo)關(guān)聯(lián)，得到合理的評(píng)估模型。同時(shí)，當(dāng)特殊情況下服務(wù)出現(xiàn)體驗(yàn)質(zhì)量下降時(shí)，用戶能夠通過測(cè)量比較給用戶提供了更多的選擇性，并且對(duì)于服務(wù)提供商進(jìn)一步改善自身服務(wù)也具有重要的指導(dǎo)意義。

5結(jié)語(yǔ)

本文提出了一種基于被動(dòng)測(cè)量的個(gè)人云存儲(chǔ)QoE測(cè)量工具PCSMeasure。在工具的實(shí)現(xiàn)中，解決了待測(cè)服務(wù)進(jìn)程數(shù)據(jù)包捕獲和個(gè)人云存儲(chǔ)網(wǎng)絡(luò)流分類等問題，實(shí)現(xiàn)了在用戶終端進(jìn)行個(gè)人云存儲(chǔ)QoE測(cè)量的目的。工具的有效性在實(shí)驗(yàn)中得到驗(yàn)證，并且能夠測(cè)量得到較為準(zhǔn)確的結(jié)果。

測(cè)量工具PCSMeasure在用戶的使用過程中通過被動(dòng)抓捕數(shù)據(jù)包來(lái)完成測(cè)量，但是真實(shí)測(cè)量環(huán)境中存在其他進(jìn)程數(shù)據(jù)包的影響，使得測(cè)量工具存在少量漏包現(xiàn)象。因此，怎樣在測(cè)量過程中捕獲到待測(cè)服務(wù)進(jìn)程更為完整的數(shù)據(jù)包，以降低測(cè)量結(jié)果的誤差，將成為今后下一步研究的重點(diǎn)。而且，除了網(wǎng)絡(luò)、系統(tǒng)和客戶端功能方面，其他的因素，如安全、隱私、價(jià)格、客戶端界面等相關(guān)的問題對(duì)于用戶QoE也是非常重要的。我們的測(cè)量工具為下一步正確完整地提出個(gè)人云存儲(chǔ)QoE評(píng)估模型，打下了基礎(chǔ)。

參考文獻(xiàn)：

[1]

DRAGO I， MELLIA M， MUNAFO M M， et al. Inside dropbox： understanding personal cloud storage service [C]// IMC 12： Proceedings of the 2012 ACM Conference on Internet Measurement Conference. New York： ACM， 2012： 481-494.

[2]

NALDI M， MASTROENI L. Cloud storage pricing： a comparison of current practices [C]// Proceedings of the 2013 International Workshop on Hot Topics in Cloud Services. New York： ACM， 2013： 27-34.

[3]

CASAS P， SCHATZ R. Quality of experience in cloud services： survey and measurements [J]. Computer Networks， 2014， 68（11）： 149-165.

[4]

JARSCHEL M， SCHLOSSER D， SCHEURING S， et al. An evaluation of QoE in cloud gaming based on subjective tests [C]// IMIS 11： Proceedings of the 2011 5th International Conference on Innovative Mobile and Internet Services in Ubiquitous Computing. Washington， DC： IEEE Computer Society， 2011： 330-335.

[5]

CASAS P， SEUFERT M， EGGER S， et al. Quality of experience in remote virtual desktop services [C]// Proceedings of the 2013 IFIP/IEEE International Symposium on Integrated Network Management. Piscataway， NJ： IEEE， 2013： 1352-1357.

[6]

GRACIATINEDO R， ARTIGAS M S， MORENOMARTINEZ A， et al. Activity measuring personal cloud storage [C]// Proceedings of the 2013 IEEE Sixth International Conference on Cloud Computing. Piscataway， NJ： IEEE， 2013： 301-308.查不到

[7]

DRAGO I， BOCCHI E， MELLIA M， et al. Benchmarking personal cloud storage [C]// IMC 13： Proceedings of the 2013 Conference on Internet Measurement Conference. New York： ACM， 2013： 205-212.

[8]

BOCCHI E， DRAGO I， MELLIA M. Personal cloud storage： usage， performance and impact of terminals [C]// Proceedings of the 2015 IEEE 4th International Conference on Cloud Networking. Piscataway， NJ： IEEE， 2015： 106-111.

[9]

CASAS P， FISCHER H R， SUETTE S， et al. A first look at quality of experience in personal cloud storage services [C]// Proceedings of the 2013 IEEE International Conference on Communications Workshops. Piscataway， NJ： IEEE， 2013： 733-737.

[10]

AMREHN P， VANDENBROUCKE K， HOBFELD T， et al. Need for speed？： on quality of experience for cloudbased file storage services [C]// Proceedings of the 4th International Workshop on Perceptual Quality of Systems. Vienna： [s.n.]， 2013： 184-190.

[11]

齊嬋穎，李戰(zhàn)懷，張曉，等.云存儲(chǔ)系統(tǒng)性能評(píng)測(cè)技術(shù)研究[J].計(jì)算機(jī)研究與發(fā)展，2014，51（S1）：223-228.（QI C Y， LI Z H， ZHANG X， et al. Research on performance evolution technology in cloud storage System[J]. Journal of Computer Research and Development， 2014， 51（S1）： 223-228.）

[12]

謝鯤，張大方，文吉?jiǎng)?，? 基于WinPcap的實(shí)時(shí)網(wǎng)絡(luò)監(jiān)測(cè)系統(tǒng)[J]. 湖南大學(xué)學(xué)報(bào)（自然科學(xué)版），2006，33（2）：118-121.（XIE K， ZHANG D F， WEN J G， et al. The realtime network monitoring system based on WinPcap[J]. Journal of Hunan University （Natural Sciences）， 2006， 33（2）： 118-121.）