0 引言

个人云存储服务(Personal Cloud Storage, PCS)作为互联网中的一种数据密集型应用程序，能为用户提供在云中的服务器存储文件和不同设备间同步文件的服务^[1]。对于用户, 越来越多的人被这些服务所吸引，因为可以简单地用来保存文件，同步设备。而服务繁多的市场使得用户选择一款合适的服务来满足他们的需求也变得愈发困难。在乐观的市场推动下，多个新的服务提供商悄然进入了市场。新的提供商必须与传统的提供商，比如Dropbox，还有Google、Microsoft、Apple这些IT巨头竞争，他们在用户群和价格方面有着更大的优势^[2]。与此同时，国内也兴起了云存储热潮，以百度云、快盘、360为首的各大提供商迅速占领了国内大部分的市场。所以，不管是终端用户还是服务提供商都需要从理解个人云存储中获益。

用户体验质量(Quality of Experience, QoE)能够衡量不同服务所提供的体验差异，能为用户和服务提供商在选择和优化服务方面提供很大的帮助。如果服务的体验质量水平没有达到预期的期望，用户可能就会拒绝继续使用^[3]。比如说，云游戏^[4]和虚拟桌面^[5]作为两个高交互性的云服务就有着很高的响应需求，当出现由高延迟引起的体验质量下降时，该服务对于用户的价值也就会降低。这个问题对于服务的提供商也变得越来越具有挑战性，他们需要知道哪些因素影响着用户的体验质量，进而能优化自身的服务。

近年来对个人云存储已经有了很多方面的研究^[6-10]：文献[6]中提出了一个个人云存储的主动测量方法，通过一个长期的测量实验，分析了三个流行服务的传输性能，但该方法依赖于提供商的公共API，测量不同的服务需要开发不同的测量工具；文献[7]也提出了一种主动测量方法并比较了5个主流的服务；文献[1, 8]都通过网络中的被动测量研究了特定云服务和不同用户的特征。另一方面，当前对个人云存储的体验质量还只有一些初步的研究：文献[9]第一次研究了个人云存储中的QoE问题，通过用户的主观评价，研究了网络QoS和个人云存储QoE之间的相互影响，网络时延和带宽被认为是QoE的两个主要影响因素；文献[3]根据云服务的交互程度，分析了不同云服务体验质量的影响因素；文献[10]通过在线调查分析出一系列QoE影响因素，同步时延被认为是用户体验质量的一个重要来源。但是，除了研究体验质量的影响因素，终端用户所能感知的体验质量的测量也至关重要，因为用户所获得的体验质量才能真正反映服务的实际优劣。所以，我们迫切需要开发出一个新的方法，使之能够在终端用户真实的使用坏境中来测量比较个人云存储服务。

针对上述问题，本文使用被动测量技术，设计并实现了一个面向终端用户的个人云存储QoE测量工具PCSMeasure。通过分析个人云存储的典型传输过程，并结合了个人云存储控制流和数据流的特征，确定了一系列QoE的测量指标，这些指标能很直观地反映出终端用户所能获得的体验质量。测量工具易于使用且具有通用性，测量过程具有独立性。

1 个人云存储 1.1 基本概念和功能

个人云存储的主要功能是网络存储，是网络技术与存储技术结合的产物。其实现原理就是在云中的服务器硬盘上为每个用户开辟一块空间，然后用户能够在此空间上实现对文件和目录的自主管理，从而实现网络环境下，用户通过网站或者客户端软件对文件的异地存储和管理。

个人云存储有两个常见的模式：Web模式和客户端模式。这两种模式所产生的流量有很大的差异，其中Web模式所产生的流量在网络中个人云存储流量总量中所占的比例非常低。根据文献[1]中的研究可知，在四种不同的网络环境中通过Web模式产生的Dropbox流量约占测量期间捕获Dropbox总流量的8%~15%。因此，本文选择对客户端模式进行QoE测量方法的研究。

个人云存储服务作为一个网络存储服务，给用户提供了方便的文件存储和管理，用户能够将文件迁移到云中实现数据的存储和多设备共享，还能满足多用户的协作。但是，用户在使用不同操作时，会有着不同的体验需求，当服务无法满足用户的期望时，就会降低用户的体验质量。

1.2 体系结构

云存储系统依赖于成千上万的服务器，核心构架由存储服务器或者磁盘阵列、文件或者元数据服务器集群、通知服务器以及Web服务器集群组成^[11]。Web服务器主要提供身份验证；文件服务器主要存储文件的元数据、文件位置等信息；通知服务器用于与客户端进行文件改变的消息通信；云存储系统存储设备包括存储服务器、磁盘阵列等设备。用户可以通过互联网或者局域网对云存储系统进行访问。

根据功能的不同，我们把通知服务器、Web服务器和文件服务器统称为控制服务器，存储服务器称为数据服务器。在众多不同的服务提供商中，服务器的部署策略也存在差异，而不同部署策略会给用户的体验质量带来不同的影响。比如分布式部署方式减少了用户-服务器之间的往返时延(Round-Trip Time, RTT)，能够更快地完成短链接数据流的传输。

1.3 客户端功能及协议

为了分析个人云存储的QoE影响因素，首先需要了解个人云存储的通信协议。通过捕获分析不同服务的数据包，结果显示大部分国外服务提供商会采用HTTPS协议即加密传输数据，只有极少数服务的控制信息是通过没有加密的HTTP协议来交换的；而国内多数的提供商都是使用HTTP协议来传输数据，除了重要的账号登录信息采用的是HTTPS。

个人云存储服务客户端软件也会采用一些高级功能来处理用户数据，这些功能能够优化网络的使用和提高用户的体验。这些功能主要包括：

捆绑  在同时操作多个小文件时，将多个小文件作为一个单独的对象来传输。

累计编码  只传输文件中被修改的部分。

分块  将单个大体积文件分成多个最大数据单元来处理。

重复删除  避免重新上传已经在服务器可用的内容。

压缩  在数据传输之前进行压缩。

负载均衡  将同一个文件传输到不同的服务器。

每个不同的服务提供商都可以选择实现不同的客户端功能，这也是造成不同服务体验质量差异的重要来源。

2 测量方法及指标 2.1 测量方法

网络测量根据是否通过测量设备向网络中注入额外的测量流量可以分为主动测量和被动测量。被动测量方法是从网络中的某一点收集流量，统计数据包大小分布、组成的协议分布、数据包数量、字节数等信息，据此计算出测量指标。被动测量又可以通过三种方式来实现：服务器端测量、用户端测量和利用网络探测。

本文采用的是用户端的被动测量方式来完成个人云存储QoE的测量：通过将具有监测功能的工具安装到用户终端，从用户的角度监测待测服务。选择被动测量有以下几个优点：1)通用性。通过API开发的云存储主动测量工具，在测量不同的服务时需要开发多个工具，而通过被动的捕获数据包来测量时，对于所有的服务都是通用的。2)基于数据包捕获的被动测量可以提供不同粒度层次的信息。3)能够在用户的实际使用过程中测量真实的结果。

2.2 QoE评估方法

体验质量的评估方法根据用户的参与度可以分为三类：主观评价方法、客观评价方法以及伪主观评价方法。而其中伪主观评价方法结合了主观和客观评价方法的优点。伪主观评价方法的基本过程是：1)分析业务特征，确定QoE相应的指标；2)确定这些QoE指标的影响因素；3)准备测试的环境以及测试的样本；4)选择测试用户，进行服务的评价，获取数据；5)利用数据，选择合适的数据模型将QoE与指标关联，得到合理的评估模型。

本文的工作就是在完成1)、2)步，并为后续模型的研究设计一个测量工具。伪主观的评价方法因为有着统计学和人工智能等学科的理论支持，而且有着很高的准确度，目前越来越受到研究人员的关注。

2.3 典型传输过程分析

在被动测量方法中如何选择QoE测量指标非常重要。而终端用户的不同操作或传输的不同阶段都有着不同的影响因素，用户也有着不同的体验要求，需要使用不同的测量指标。因此，接下来对个人云存储的典型传输过程进行分析。

如图 1所示，描述了典型个人云存储的传输过程。个人云存储的典型同步过程可以分为两部分：客户端启动过程和文件同步过程。客户端启动过程是指在用户启动客户端到云存储中的文件夹实际显示，文件同步过程是指当用户发起对文件操作到操作完成。具体的过程可以分为三步：

1)客户端与控制服务器交换文件的元数据信息。

2)触发文件的存储操作，客户端与数据服务器通过数据流直接完成数据的传输。

3)当数据成功传输完毕后，客户端再次与控制服务器交换控制信息，来完成此次传输事务。

另外，在空闲阶段(即没有任何操作时)客户端会与通知服务器保持信息的交换，用于通知客户端存储在服务器中的文件是否变化。

2.4 QoE的影响因素

全面研究QoE的影响因素对于测量指标的确定非常重要，因为QoE测量的根本目的就是根据不同方面的影响因素来得到用户的QoE。本文将QoE的影响因素分为三个方面：网络方面、客户端方面以及系统平台方面。

如图 2所示，描述了个人云存储的体验质量被多方面的客观因素所影响。网络方面的参数主要反映网络传输的状况，如网络带宽、延迟；客户端方面反映的是没有经过网络传输的服务体验，包括一系列的优化机制；系统设计方面，主要包括传输协议、带宽控制及服务器的部署方式等。

其中，每一种影响因素都以一种复杂的方式影响着服务的体验质量。比如说，用户所感受到的数据传输体验很可能是由于网络的带宽过小或者客户端-服务器往返时延太大造成数据流吞吐量很小，也可能是因为服务客户端并没有采用优化传输的功能。另外，操作的响应体验也是由网络环境、客户端功能、系统设计等多种客观因素所影响的。

2.5 主要测量指标

由于个人云存储QoE的客观影响因素的多方面性，使得在被动测量中准确测量并量化所有客观因素非常困难。所以，本文通过结合个人云存储的不同影响因素和不同网络流的特征，分析出多个能够准确评估终端用户QoE的指标。下面各指标计算公式中的时间戳，如2.3节中的图 1所示。

1)客户端启动时延。

客户端启动时延D_c是指云存储客户端启动到客户端的文件夹完全显示之间的时延。计算公式如(1)所示：

${D_{\rm{c}}} = {T_1} - {T_0}$

(1)

其中：T₀表示服务进程出现的时间；T₁表示最后一个数据包到达的时延。

2)同步初始化时延。

同步初始化时延D_s是指在同步操作执行到文件数据流正式开始传输之间的时延。D_s在有些使用场景下对用户的体验非常重要，比如单独传输小体积文件时。同步初始化时延通过式(2)计算：

${D_{\rm{s}}} = {T_3} - {T_2}$

(2)

其中：T₂为第一条控制流的建立时间；T₃为第一条数据流的建立时间。

3)传输数据总量。

传输数据总量S_t是指整个同步过程中所有网络流的体积总和。对于流量敏感的用户而言，能够用尽可能少的流量完成文件的传输能提升体验质量。传输数据总量的计算方法如式(3)所示：

${S_{\rm{t}}} = \sum\limits_{i = 0}^n {{D_i} + \sum\limits_{j = 1}^m {{C_j}} } $

(3)

其中：D_i和C_j分别表示每条数据流和控制流的大小，n和m分别表示数据流和控制流的数目。

4)数据传输速率。

数据传输速率DTS是指同步过程中传输的数据流总量与数据流的持续总时间之间的比值。它是描述个人云存储体验质量的重要参数，也是评估长期体验传输变化性的一个基础。数据传输速率的计算方法如式(4)所示：

$DTS = \sum\limits_{i = 1}^n {{D_i}/\left( {{T_4} - {T_3}} \right)} $

(4)

其中：D_i表示数据流的大小；T₃表示第一条数据流的建立时间；T₄表示最后一个数据流数据包的捕获时间，我们忽略了数据流断开和最后的控制信息交换时间。

5)控制开销率。

控制开销率COR是用于衡量传输一定大小的文件所需控制流开销的指标。值越大说明传输相同体积的数据需要更多的控制开销。计算方法如式(5)所示:

$COR = {S_{\rm{t}}}/\sum\limits_{i = 1}^n {{D_i}} $

(5)

其中:S_t表示指标(3)中的传输数据总量，D_i表示数据流的大小。

3 测量工具的实现 3.1 工具设计

在选择了QoE的测量指标、确定了被动测量方法后，接下来进行工具PCSMeasure的设计和实现。工具PCSMeasure的结构如图 3所示，主要由三个模块组成：第一个模块是数据包捕捉模块Packets Sniffer，通过调用数据包处理驱动WinPcap捕获待测服务的所有数据包；第二个模块是网络流分析模块Traffic Analysis，根据已有的数据包完成控制流和数据流的分类；最后一个模块是指标计算模块Metrics Computation。

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

1)Packets Sniffer:独立的网络抓包模块。接收WinPcap捕获的数据包，进行逐层解码，完成协议分析统计和数据包的本地化。该模块是被动测量工具的主体。

2)Traffic Analysis:网络流分析模块。分析上层模块捕获的数据包，根据五元组信息，统计所有的网络流信息，包括网络流的开始时间、持续时间、数据包个数和网络流大小等。根据网络流的特征信息，使用聚类算法将网络流分为数据流和控制流。

3)Metrics Computation:指标计算模块。根据上层的网络流分析结果结合个人云存储的传输过程，计算出测量指标；同时，将计算出的结果反馈给用户并完成本地化。

在三个模块中，Packets Sniffer模块和Traffic Analysis模块是Metrics Compute模块的基础，测量结果的准确性也完全取决于这两个模块。如果Packets Sniffer模块中没有正确捕捉到服务的数据包就会给测量结果带来误差；而Traffic Analysis模块中的网络流分类不准确时，甚至会直接导致测量结果错误。

下面分别来讨论这两个问题的解决方法。

3.2 服务进程抓包

在Packets Sniffer模块中进行网络数据包捕获时，通过调用数据包处理驱动WinPcap的接口函数，将网卡设置为混杂模式，数据包经过两次内存拷贝和系统调用，到达用户空间^[12]。但是在终端用户使用环境中，存在着不同网络进程的数据包。准确捕捉到待测服务进程的数据包对于计算测量指标就变得非常重要。

虽然Winpcap并没有直接提供捕捉不同进程数据包的函数接口，但是Winpcap的一个强大特性是提供了过滤引擎。通过将相关的过滤器应用到所有来自网络的数据包上，所有与过滤器特性一致的数据包将被复制给应用程序。因此，提出了一种基于Winpcap过滤机制的双缓存进程抓包方法。该方法的有效性基于所有个人云存储的传输层都是使用TCP协议这一假设。

捕获特定进程的数据包最为直接的方法是能获取目标进程所有网络连接的端口，然后将Winpcap的过滤器设置为特定进程的端口号。但是，这个方法存在两个问题：

1)在实际的服务传输过程中TCP连接的建立是随机的，所以，需要动态地查询目标进程的端口列表，当发现出现新的连接时，动态更新过滤器。

2)在动态更新过滤器的过程中，又可能在两次更新过滤器期间出现新的TCP连接，导致漏包现象。针对这个问题，提出了一种双缓存机制。双缓存机制是指，通过开启两个抓包线程，创建两个数据包缓存区，分别对应不同的过滤规则。在每次更新过滤器前，通过综合两个线程缓存区中的数据包来完整地捕获到进程在这个周期内的数据包。

根据以上分析，PCSMeasure进程抓包的具体步骤如下：

1)获取网卡接口和目标进程信息。开始测量后，首先创建两个抓包线程C1和C2，同时都调用Winpcap所提供的pcap_open_live()方法，用于打开网络设备准备捕捉网络数据，分别返回adhandle1和adhandle2两个用于捕获网络数据包的数据包捕获描述字。对于这个网络接口的操作都要基于此描述字。

2)分别调用Winpcap所提供的函数pcap_setfilter()给C1、C2设置过滤规则。其中C1的过滤器filter1设置为“TCP”。在C2中使用轮询机制，通过定时查询目标进程所有连接的端口号集合，根据端口号集合动态地更新过滤器filter2。

3)当在t_i更新filter2时，首先调用自定义的函数GetAllPortsByID()根据进程ID查询目标进程最新连接的端口集合，将结果与t_i-1查询的端口集合比较。当出现了新的端口号时，表示在t_i-1~t_i周期内出现了新的连接并且C2漏掉了这些新连接在t_i-1~t_i周期内传输的数据包。所以，根据新的端口号在C1的缓冲区中找出新连接的所有数据包，加上C2缓冲区内的数据包就是目标进程在t_i-1~t_i周期内完整的数据包。最后清空C1与C2缓冲区，更新C2的过滤器。

4)接下来讨论C2的过滤器更新周期T_i。通过分析TCP的连接可知，一个最简单的网络流是由三次握手、POST+ACK、DATA+ACK和RST组成。因此T_i的最大值T_max不能大于2RTT，才能保证在过滤器更新期间不会漏掉整个网络流的所有数据包。而出于对进程端口查询开销的考虑，将T_min设置为30ms。

5)最后讨论T_i的变化策略。根据人工分析云存储的网络流变化发现，网络连接的建立都是具有突发性的，即会在短时间同时建立多条新的连接，当数据传输稳定后，就会很少有新的连接建立。所以根据两次端口查询结果之间的差异来决定T_i的变化：当两次端口查询期间t_i-1~t_i没有出现新的连接时，T_i以线性增长直至T_max；当在t_i-1~t_i出现新的连接时，T_i赋值为Max(T_i/ 2, T_min)。

3.3 个人云存储流量分析

个人云存储的控制流和数据流作为计算测量指标的基础。在Traffic Analysis模块中，区分出测量过程中的所有控制流和数据流也是一个重点。数据流和控制流的主要不同就是传输数据内容的不同，可是无法通过捕获的数据包直接区分出不同服务的数据流和控制流。因此，我们基于个人云存储数据流和控制流的特征差异，提出了一个改进初始聚类中心的k-means聚类方法。

首先，主动通过分析捕获到的不同个人云存储服务的数据包，发现数据流与控制流存在两个重要的差异特征：有效数据包(除ACK)的平均载荷和数据包的个数。1)数据流平均载荷大部分会大于当前网络的最大传输单元(Maximum Transmission Unit, MTU), 比如以太网中是1514字节，而控制流通常会小于1000字节；2)由于控制流通常传递的信息量较少，常常只是几个或者几十个数据包，而数据流的数据包个数则和文件的大小有关，一般都有几百个。

如图 4所示，例举了百度云和Google Drive在上传10个100KB文件时网络流的特征分布，所以我们可以采用聚类方法实现网络流的分类。

其次，传统的k-means聚类方法采用随机选择初始聚类中心的方式，当结果簇是密集的而且簇之间的区分明显时，它的效果较好。但是个人云存储的网络流分布呈现两极现象：数据流多分布较为密集；而控制流因为作用的差异，不同控制流的数据包个数和平均载荷都各不相同，造成控制流的分布相对较为分散。所以采用随机选择初始聚类中心可能会导致聚类收敛速度慢、聚类效果差的问题。

针对这个问题，本文改进了k-means聚类算法初始中心的选择方法。

1)针对数据流的密集分布特征，并且根据控制流应该离数据流中心尽可能远这一原则，选择数据包个数与有效大小乘积最大的流作为数据流的初始中心，从而尽可能避免可能出现的控制流距离数据流初始中心更近的情况。

2)根据控制流分布分散的特点，控制流的初始中心根据最小相似度方法来确定。首先给出网络流相似度的定义，

$S\left( {{x_i},{x_j}} \right) = 1/\sqrt {\sum\limits_{t = 1}^2 {{{\left( {{x_{it}} - {x_{jt}}} \right)}^2}} } $

(6)

其中：x_i, x_j分别为网络流样本，x_it表示样本的两个特征分量。控制流初始中心的选择方法如下：

步骤1   新建链表L。以数据流初始中心为起点，找出与它相似度最高的样本对象x_temp，存入链表L，并记住该相似度S_min和该样本x_min。

步骤2   找出其他剩下的样本中(链表外的)与x_temp最相似的，同样赋值给x_temp，并加入链表L，当它们的相似度S_temp小于S_min时，将S_temp、x_temp分别赋值S_min、x_min。

步骤3   重复步骤2，直到遍历完所有样本对象。

至此，从数据流初始中心开始，找出了最小的样本间相似度S_min及该样本x_min。所以，链表L中排在x_min后的样本就是最有可能为控制流的，因此控制流初始中心设置为这些样本的平均值。

3.4 测量流程

图 5描述了PCSMeasure被动测量个人云存储QoE指标的流程。首先开启测量工具，选择需要测量的服务进程；当执行相关操作时，工具就会捕获该进程的数据包，同时分析捕获到的数据包；当数据传输完毕，工具会通过分析捕获的数据包，统计网络流的信息并完成网络流的分类；最后，计算出测量指标并将结果反馈给用户。

在测量完成后，结果被保存在一个以服务进程名和时间命名的文本文件中。文件中不仅记录了相关的指标数据，还包括所有的流信息，可以用于分析及优化个人云存储的QoE。

4 测量工具的应用

百度云已经发展成为国内用户最多的服务提供商，而Google Drive是全球最流行的个人云存储服务提供商，故本文的实验选择百度云和Drive Google作为测量对象。

4.1 实验方案

为了验证工具的有效性和比较工具的测量结果，设计了一个实验方案，实验平台如图 6所示。实验平台搭建在一台普通的PC上，并在其中安装有多个待测服务客户端、测量工具PCSMeasure和常用的数据包捕获分析软件Wireshark。

在实验中，当用户在待测服务客户端执行某个操作后，测量工具PCSMeasure和Wireshark能够同时捕捉到待测服务的数据包。通过比较PCSMeasure的测量结果和Wireshark的手动分析结果来验证工具的有效性，然后分别测量不同的个人云存储服务，并对比测量结果，对测量结果进行简要的分析。

4.2 工具的有效性

在测量工具PCSMeasure的指标计算中，最后测量结果的有效性取决于两个方面，分别是完整地抓取待测服务进程的数据包和正确的网络流分类结果，因此分别从这两个方面比较了测量工具PCSMeasure和Wireshark。

如图 7所示，分别描述百度云和Google Drive在传输不同大小的文件时PCSMeasure和Wireshark捕获到的数据包个数。Google Drive的数据包漏包率相对比较小，主要集中在2%~3%；而百度云就相对要高一些，尤其在传输更大(如5MB)文件时漏包率达到了7%。

出现这种情况的原因可能是因为Winpcap在捕获数据包时，需要经过两次拷贝将数据包从内核缓存中转移到用户空间的缓存区，当执行一次过滤器更新周期后，从用户缓冲区获取数据包时，内核缓存中还存在少量数据包没有拷贝到用户空间。这将会降低测量结果的准确性，也是我们下一步改进的主要工作。

表 1描述了PCSMeasure在测量过程中进行网络流分类时的初始化中心和分类准确率，由于篇幅的原因只列出了两种文件类型的结果。结果显示在一般情况下数据流和控制流的初始中心差异明显，而且本文的分类方法也能够获得很高的准确率。

4.3 个人云存储QoE测量结果

最后，使用PCSMeasure测量比较了百度云和Google Drive在传输不同类型文件时的QoE指标结果。表 2总结了我们测量实验的全部结果。

由表 2中的数据可以知道两种个人云存储服务在QoE上有很大的差异。首先，由于Google的控制服务器都部署在国外，造成Google Drive控制流的平均RTT是百度云的近十倍。这也就使得Google Drive的客户端启动时延和同步控制时延都比百度云要大很多。其中同步控制时延中出现一个特殊值，Google Drive在上传单个5MB的文件时同步控制时延为0。这是因为Google Drive在传输大体积文件时将文件分割成每单位8MB传输，而且当Google Drive传输单个小于8MB的文件传输时，文件的控制信息是直接通过数据流传输到服务器，因此出现了控制时延为0的情况；而百度云是以4MB为单位传输，所以传输单个5MB文件时分割成两个数据单元传输。上传过程和下载也有差异，当下载批次文件时明显需要更多控制信息，所以需要更长的同步控制时延。

其次，百度云在传输表 2中后三种类型的文件时，上传的数据总量总是大于Google Drive，这主要是由于Google Drive在上传文件前会进行压缩以减少流量的消耗，这对于流量敏感的用户而言是能提高体验质量的。但是由于Google Drive没有使用捆绑机制，当上传大量小文件时会为每个文件开启一条控制流交换文件元数据，所以在上传100个10KB的文件时，Google Drive最后传输的数据总量反而大于百度云的数据总量。而下载过程中，由于两个云存储的服务器在传输文件之前都没有使用压缩处理，使得下载时传输的数据总量都大于文件本身的大小。

在全部四种文件类型中，不管是上传还是下载百度云的数据传输速率都比Google Drive的大，这也是由于Google Drive数据流的平均RTT比百度云数据流的RTT更大，使得Google Drive每条数据流的平均吞吐量很小。

最后我们观察到，当上传100个10KB的文件时，两个服务都有较高的控制开销率。Google Drive的控制开销率为1.13，这是由于Google Drive没有采用捆绑机制，使得每个文件都需要有与控制服务器交换信息。但是，百度云即使采用了捆绑机制，控制开销也达到了1.44。通过分析百度云的控制流发现，虽然传输过程只有5条控制流，但是每条控制流都会与服务器进行多次数据交换，为每个文件提交元数据。同样情况也出现在百度云的下载过程中，使得百度云在下载时控制开销也达到了1.46。因此，百度云可以通过优化控制信息的交换策略来降低控制信息的开销，以提高用户的体验质量。

PCSMeasure可以被动测量个人云存储服务，在下一步研究中，可以选择测试用户，使用PCSMeasure进行服务的评价，获取数据。利用这些数据，选择合适的数据模型将QoE与指标关联，得到合理的评估模型。同时，当特殊情况下服务出现体验质量下降时，用户能够通过测量比较给用户提供了更多的选择性，并且对于服务提供商进一步改善自身服务也具有重要的指导意义。

5 结语

本文提出了一种基于被动测量的个人云存储QoE测量工具PCSMeasure。在工具的实现中，解决了待测服务进程数据包捕获和个人云存储网络流分类等问题，实现了在用户终端进行个人云存储QoE测量的目的。工具的有效性在实验中得到验证，并且能够测量得到较为准确的结果。

测量工具PCSMeasure在用户的使用过程中通过被动抓捕数据包来完成测量，但是真实测量环境中存在其他进程数据包的影响，使得测量工具存在少量漏包现象。因此，怎样在测量过程中捕获到待测服务进程更为完整的数据包，以降低测量结果的误差，将成为今后下一步研究的重点。而且，除了网络、系统和客户端功能方面，其他的因素，如安全、隐私、价格、客户端界面等相关的问题对于用户QoE也是非常重要的。我们的测量工具为下一步正确完整地提出个人云存储QoE评估模型，打下了基础。