Inside Dropbox: Understanding Personal Cloud

Storage Services

1. INTRODUO
Nos ltimos anos, a introduo de servios baseados
na nuvem[18], oferecendo s pessoas e empresas a
capacidade de computao e armazenamento em data
centers remotos e abstraindo a complexidade do
gerenciamento de hardware. Testemunhamos uma
corrida de ouro para oferecer recursos de
armazenamento online, com interessados como
Microsoft, Google e Amazon entrando no mercado no
final de abril de 2012. Eles enfrentam um cenrio
lotado contra solues populares como Box.com,
UbuntuOne e Dropbox. O ltimo, ativo desde 2007,
conta atualmente com mais de 50 milhes usurios*,
carregando mais de 500 milhes de arquivos por dia.
Portanto, no surpreendente que o armazenamento
na nuvem tenha ganhado crescente impulso dentro da
comunidade de pesquisa. Alguns trabalhos
explicitamente consideram o design da arquitetura
do sistema[12], enquanto outros se concentram em
questes de segurana e privacidade no armazenamento Comentado [MR1]: Main Point of article presentation
de dados de usurios[19]. Considerando as ofertas
comerciais, pouco se sabe, com a maioria dos
jogadores fornecendo solues proprietrias e no Comentado [MR2]: gigantes
disposto a compartilhar informaes.
Alguns estudos apresentam uma comparao entre
diferentes fornecedores de armazenamento[13,17]: ao
executar benchmarks, eles se concentram no
desempenho alcanado pelo usurio, mas perde a
caracterizao do uso tpico de um servio em nuvem
e do impacto de comportamento do usurio e do
sistema em aplicativos de armazenamento pessoal.
Neste artigo, fornecemos uma caracterizao do
cloudbased sistemas de armazenamento. Analisamos o
trfego coletado de dois campus universitrios e
dois Pontos de Presena (POP) em um grande provedor
de servios de Internet (ISP) por 42 dias
consecutivos. Primeiro, elaboramos uma metodologia
para monitorar trfego de armazenamento em nuvem,
que, com base na criptografia TLS, no fcil de
entender. Em seguida, nos concentramos em Dropbox,
que mostramos ser a nuvem mais amplamente utilizada
sistema de armazenamento em nossos conjuntos de
dados. Dropbox j conta com cerca de 100 GB de Comentado [MR3]: Atualmente mais 1,2 bilies de upload
trfego dirio em uma das redes monitoradas- ou
seja, 4% do trfego total ou cerca de um tero do
trfego do YouTube na mesma rede. Concentramo-nos
primeiro na caracterizao do desempenho do servio,
destacando possveis estrangulamentos e sugestes
de contramedidas. Ento, ns detalhamos hbitos do
usurio, proporcionando assim uma caracterizao
extensiva da carga de trabalho que o sistema tem
para enfrentar. Para ser nosso melhor conhecimento,
somos os primeiros a fornecer uma anlise do uso do
Dropbox na Internet. Os autores de[11] compararam
Dropbox, Mozy, Carbonite e CrashPlan, mas apenas uma
experincia ativa simplista fornecida para avali-
los. Em [16], a possibilidade de acesso no autorizado
aos dados e as implicaes de segurana de armazenar
dados no Dropbox so analisado. Seguimos uma
metodologia similar para dissecar o protocolo
Dropbox, mas, com foco em um tpico completamente
diferente.
Considerando os sistemas de armazenamento em
geral, [8,9] estudam segurana e implicaes de
privacidade da implantao de desduplicao de dados
- o mecanismo no lugar do Dropbox para evitar o
armazenamento de dados duplicados. Da mesma forma,
[1]
apresenta uma performance de anlise da Amazon
Web Services (AWS) em geral, mas no fornece
informaes sobre o armazenamento pessoal.
Finalmente, vrios trabalhos caracterizam servios
populares, como redes sociais[7,15] ou YouTube[3,6].
Nosso trabalho vai em uma direo similar,
derramando luz no Dropbox e possivelmente outros
sistemas relacionados. Nossas principais
descobertas so:
J vemos uma quantidade significativa de
trfego relacionado para armazenamento de nuvem
pessoal, especialmente em redes de campus, onde
so encontradas pessoas com mais conhecimentos
tcnicos. Ns esperamos que esses sistemas se
 tornem populares tambm em casa, onde a
penetrao j est acima dos 6%.
Destacamos que o desempenho do Dropbox
impulsionado principalmente pela distncia
entre clientes e centros de dados de
armazenamento. Comentado [MR4]: Desvantagem
Alm disso, os tamanhos de transferncia de
dados curtos, juntamente com um perchunk -
mecanismo de reconhecimento prejudica a taxa de
transferncia, que to pouco quanto
530kbits/s em mdia. Um esquema de agrupamento,
confirmaes demoradas ou uma colocao mais
fina de servidores de armazenamento poderiam
ser adotados para melhorar o desempenho.
Considerando o comportamento dos usurios
domsticos, quatro grupos so claros:
7% das pessoas s fazem upload dados; cerca de
26% apenas o download, e at 37% das pessoas
fazem as duas coisas. Os restantes 30% deixam
seus clientes executando, raramente trocando
arquivos.
Curiosamente, uma das caractersticas mais
apreciadas de Dropbox a capacidade
simplificada de compartilhar contedo: 30% dos
usurios domsticos possuem mais de um
dispositivo vinculado e 70% compartilham pelo
menos uma pasta. Nos campi, o nmero de pastas
compartilhadas aumenta, com 40% dos usurios
compartilhando mais de 5 pastas.
Nossas descobertas mostram que aplicativos
pessoais de armazenamento em nuvem so famintos
com dados e o comportamento do usurio afeta
profundamente seus requisitos de rede.
Acreditamos que nossos resultados so teis
tanto para a comunidade de pesquisa quanto para
ISPs para entender e antecipar o impacto da
adoo macia de tais solues.
Da mesma forma, nossa anlise do desempenho do
Dropbox uma referncia para aqueles que
projetam protocolos e provisionamento data-
centers de dados para servios similares, com
lies valiosas sobre possveis
 estrangulamentos introduzidos por algumas
decises de design.
O restante deste artigo est organizado da
seguinte forma:
Sec.2 - Fornece informaes sobre a arquitetura
Dropbox.
Sec.3 descreve nossa coleta de dados e compara a
popularidade de conhecidos sistemas de
armazenamento baseados em nuvem.
Sec.4 - apresenta uma caracterizao do desempenho
do Dropbox. Hbitos de usurio e a carga de trabalho
gerada apresentada na Sec.5. Enquanto essas sees
se concentram principalmente no uso do Software do
cliente Dropbox, Sec.6 discute a interface da Web
menos popular. Finalmente, Sec.7 conclui este
documento, e o apndice A fornece algumas
caractersticas adicionais do trfego de
armazenamento Dropbox.

VISO GERAL DO DROPBOX

2.1 O cliente Dropbox
O cliente nativo do Dropbox implementado
principalmente no Python, usando bibliotecas de
terceiros, como o librsync. A aplicao est
disponvel para Microsoft Windows, Apple OS X e
Linux.2. O objeto bsico no sistema um pedao de
dados com tamanho de at 4MB. Arquivos maiores
divididos em vrios pedaos, cada um tratado como
um objeto independente.
Cada pedao identificado por um valor de hash
SHA256, que faz parte das descries de arquivos de
meta-dados. Dropbox reduz a quantidade de dados
trocados usando a codificao delta ao transmitir
pedaos. Ele tambm mantm localmente em cada
dispositivo um banco de dados de informaes de
meta-dados (atualizado por meio de atualizaes
incrementais) e comprime pedaos antes de envi-
los. Alm disso, o cliente dropbox oferece ao
usurio a capacidade de controlar a velocidade
mxima de download e upload. Dois componentes
importantes podem ser identificados na arquitetura
Dropbox: Comentado [MR5]: ** na apresentao
O controle e os servidores de armazenamento de
dados. Os primeiros esto sob controle direto da
Dropbox Inc., enquanto o Amazon Elastic Compute
Cloud (EC2) e o Servio de armazenamento simples
(S3) so usados como servidores de armazenamento.
Em ambos os casos, subdomnios do dropbox.com so
usados para identificar as diferentes partes do
servio que oferecem uma funcionalidade especfica,
conforme detalhado na tabela.1. HTTPS usado para
acessar todos os servios, exceto o servio de
notificao que executado em HTTP.

2.2 Entendendo o Dropbox Internals

Para caracterizar o uso do servio a partir de
medies passivas, primeiro adquirimos uma
compreenso do protocolo do cliente Dropbox.
Realizamos vrias experincias ativas para observar
quais informaes so trocadas aps uma determinada
operao. Por exemplo, entre outros, documentamos o
trfego gerado ao adicionar ou remover arquivos em
pastas locais, ao fazer o download de novos arquivos
e ao criar novas pastas. Durante a coleta de dados,
a verso do cliente Dropbox 1.2.52 estava sendo
distribuda como a verso estvel. Uma vez que a
maioria das comunicaes do cliente so
criptografadas com TLS, e nenhuma descrio sobre o
protocolo fornecida pela Dropbox, ns configuramos
um teste local, no qual um PC Linux executando o
cliente Dropbox foi instrudo a usar um servidor
proxy squid sob nosso controle. No ltimo, o mdulo
SSL-bump4 foi usado para encerrar conexes SSL e
salvar fluxos de trfego descodificados. A rea de
memria onde o aplicativo Dropbox armazena
autoridades de certificados confiveis foi
modificado em tempo de execuo para substituir o
certificado original da Dropbox Inc. pelo auto
assinado que assina o servidor proxy. Por meio desta
configurao, conseguimos observar e entender a
comunicao do cliente Dropbox.

Aplicaes de dispositivos mveis acessam Dropbox on demand usando

APIs; Aqueles no so considerados neste trabalho.
Http://www.dropbox.com/release_notes
Http://wiki.squid-cache.org/Features/SslBump

Figura 1: An example of Dropbox protocolo.

Por exemplo, a Fig.1 ilustra as mensagens que

observamos ao commitar um lote de pedaos. Depois
de se registrar no centro de controle do Dropbox
atravs de um servidor clientX.dropbox.com, o
comando da lista recupera atualizaes de meta-
dados. Assim que novos arquivos so adicionados
localmente, um comando de commit batch (no client-
lb.dropbox.com) envia informaes de meta-dados.
Isso pode desencadear operaes de armazenamento,
realizadas diretamente com servidores Amazon (em dl-
clientX.dropbox.com). Cada operao de
armazenamento em partes reconhecida por uma
mensagem OK. Como veremos na Sec.4, este mecanismo
de reconhecimento pode originar gargalos de
desempenho. Finalmente, medida que os pacotes so
submetidos com sucesso, o cliente troca mensagens
com os servidores Dropbox centrais (novamente em
client-lb.dropbox.com) para concluir as transaes.
Observe que essas mensagens que commitam transaes
podem ocorrer em paralelo com operaes de
armazenamento mais recentes. Uma descrio completa
dos protocolos Dropbox est fora do escopo deste
artigo. Ns, no entanto, exploramos esse
conhecimento para marcar os fluxos TCP passivamente
observados com os provveis comandos executados pelo
cliente, mesmo que no possamos acessar o contedo
das conexes (criptografadas). A seguir,
descrevemos os protocolos utilizados para trocar
dados com os servidores de controle Dropbox e com
os servidores de armazenamento da Amazon.

2.3 Fluxos de controle do cliente

O cliente Dropbox troca informaes de controle
principalmente com servidores gerenciados
diretamente pela Dropbox Inc. Ns identificamos trs
subgrupos de servidores de controle:
(i) Notificao, (ii) administrao de meta-dados e
(iii) servidores de log do sistema.
Os servidores de logs do sistema coletam informaes
de tempo de execuo sobre os clientes, incluindo
back-traces de exceo (via Amazon, em Dl- Comentado [MR6]: Rastreamento de pilha
debug.dropbox.com) e outros logs de eventos
possivelmente teis para otimizao do sistema (em
d.dropbox.com). Uma vez que flui para esses
servidores no esto diretamente relacionados ao uso
do sistema e no carregam muitos dados, eles no
foram considerados mais distante. A seguir
descrevemos a chave TCP fluxos para os servidores
de meta-dados e notificao.

2.3.1 Protocolo de notificao

O cliente Dropbox continua aberta continuamente uma
conexo TCP para um servidor de notificao
(notifyX.dropbox.com), usado para receber
informaes sobre mudanas realizadas em outro
lugar. Em contraste com o trfego, as conexes de
notificao no so criptografadas. As respostas
HTTP atrasadas so usadas para implementar um
mecanismo de envio: uma solicitao de notificao
enviada pelo cliente local solicitando eventuais
mudanas ao servidor. A resposta recebida
periodicamente cerca de 60 segundos depois em caso
de no haver mudana; Depois de receb-lo, o cliente
envia imediatamente um novo pedido. As alteraes
no armazenamento central so, em vez disso,
anunciadas assim que so executadas. Cada
dispositivo vinculado ao Dropbox possui um
identificador exclusivo (host int). Identificadores
nicos (chamados namespaces) tambm so usados para
cada pasta compartilhada. O identificador do cliente
enviado nos pedidos de notificao, juntamente com
a lista atual de namespaces. Os dispositivos e o
nmero de pastas compartilhadas podem, portanto, ser
identificados em traos de rede, observando
passivamente os fluxos de notificao. Finalmente,
diferentes dispositivos pertencentes a um nico
usurio tambm podem ser inferidos, comparando
listas de namespace. Comentado [MR7]: Um espao conceitual que
agrupa classes , identificadores , etc. para
evitar conflitos com itens em cdigo no relacionado que
possuem os mesmos nomes.
2.3.2 Protocolo de Informaes de Meta-Dados
As mensagens de administrao de meta-dados de
autenticao e arquivo so trocadas com um conjunto
separado de servidores, (client-lb.dropbox.com e /
ou clientX.dropbox.com).
Normalmente, as transaes de sincronizao comeam
com mensagens para servidores de meta-dados, seguido
de um lote de operaes de armazenamento ou
recuperao por meio de servidores Amazon. medida
que os chunks de dados so trocados/ confirmados com Comentado [MR8]: as trocas
xito, o cliente envia mensagens para servidores de Comentado [MR9]: pedao grande
meta-dados para concluir as transaes (ver Fig.1).
Devido a uma manipulao de tempo limite de conexo
TCP agressiva, vrias conexes TLS curtas para
servidores de meta-dados pode ser observado durante
este procedimento. As respostas do servidor s
mensagens do cliente podem incluir parmetros gerais
de controle. Por exemplo, nossos experimentos
testados revelam que a verso atual do protocolo
limita o nmero de trocas a serem transferidas para
no mximo 100 por transao. Ou seja, se mais de 100
pedaos precisam ser trocados, a operao dividida
em vrios lotes, cada um de no mximo 100 pedaos.
Tais parmetros moldam o trfego produzido pelo
cliente, conforme analisado na Sec.4.
2.4 Fluxos de armazenamento de dados
Conforme ilustrado na fig.1, todas as operaes de
armazenamento e recuperao so tratadas por
mquinas virtuais no Amazon EC2. Mais de 500 nomes
de domnio distintos (dl-clientX.dropbox.com)
apontam para servidores Amazon. Um subconjunto
desses, alis so enviados regularmente aos
clientes. Os clientes rodam nas listas recebidas ao
executar operaes de armazenamento, distribuindo a
carga de trabalho. Normalmente, os fluxos de
armazenamento carregam comandos de armazenamento ou
os comandos de recuperao. Isso permite que os
fluxos de armazenamento sejam divididos em dois
grupos, verificando a quantidade de dados baixados
e carregados em cada fluxo. Por meio dos dados
coletados em nosso ambiente de teste, documentamos
a sobrecarga de armazenamento e recuperamos comandos
e derivamos um mtodo para rotular os fluxos. Alm
disso, identificamos uma relao direta entre o
nmero de segmentos TCP com a bandeira PSH definida
nos fluxos de armazenamento e o nmero de blocos
transportados. O Apndice A apresenta mais detalhes
sobre nossa metodologia bem como alguns resultados
que validam que os modelos construdos em nosso
ambiente de teste representam o trfego gerado por
usurios reais de forma satisfatria. Usamos esse
conhecimento nas prximas sees para caracterizar
o desempenho do sistema e a carga de trabalho.
2.5 Interface da Web e outros protocolos
O contedo armazenado no Dropbox tambm pode ser
acessado atravs de interfaces da Web. Um conjunto
separado de nomes de domnio usado para
identificar os diferentes servios e, portanto, pode
ser explorado para distinguir as operaes
realizadas. Por exemplo, os URLs contendo dl-
eb.dropbox.com so usados ao baixar contedo privado
de contas de usurio. O domnio dl.dropbox.com
fornece links diretos para arquivos compartilhados.
Conforme mostrado na Sec.6, a ltima a interface
preferida da Web Dropbox.
Imagem ----

Alm disso, outros protocolos esto disponveis,

como o LAN Synchronization Protocol e as APIs
pblicas. No entanto, esses protocolos no fornecem
informaes teis para o objetivo deste artigo. Eles
so, portanto, mais ignorados no restante deste
artigo.

3. DATAS E POPULARIDADE
3.1 Metodologia
Confiamos em medidas passivas para analisar o
trfego Dropbox nas redes operacionais. Usamos o
Tstat[5], uma ferramenta de monitoramento de cdigo
aberto desenvolvida no Politcnico di Torino, para
coletar dados. O Tstat monitora cada conexo TCP,
expondo informaes sobre mais de 100 metrics 5,
incluindo endereos IP de cliente e servidor,
quantidade de dados trocados, eventuais segmentos
retransmitidos, Round Trip Time (RTT) e o nmero de
segmentos TCP que apresentaram a bandeira PSH [14].
Especificamente visando a anlise do trfego da
Dropbox, implementamos vrios recursos adicionais.
Primeiro, dado que a Dropbox depende do HTTPS,
extramos os certificados TLS / SSL oferecidos pelo
servidor usando uma abordagem DPI clssica. Nossa
anlise mostra que a string*.dropbox.com usada
para assinar todas as comunicaes com os
servidores. Isso fundamental para a classificao
de trfego dos servios. Em segundo lugar,
aumentamos a informao exposta rotulando os
endereos IP do servidor com o nome de domnio
totalmente qualificado original (FQDN) o cliente
solicitado ao servidor DNS[2]. Esta uma
caracterstica chave para revelar informaes sobre
o servidor que est sendo contatado (consulte a Tab.
1) e permite identificar cada servio especfico
relacionado ao Dropbox. Em terceiro lugar, a Tstat
foi instruda para expor a lista de identificadores
de dispositivos e namespaces mais antigos trocados
com os servidores de notificao.
Fig.1 e fig.2

3.2 Conjuntos de dados

Instalamos a Tstat em 4 pontos de vantagem em 2
pases europeus e recolhemos dados de 24 de maro
de 2012 a 5 de maio de 2012. Esta configurao
forneceu um conjunto de conjuntos de dados nicos,
permitindo-nos analisar o uso do armazenamento em
nuvem em diferentes ambientes, que variam em tanto
a tecnologia de acesso quanto os hbitos tpicos do
usurio. A tabela 2 resume os nossos conjuntos de
dados, mostrando, para cada ponto de vantagem, as
tecnologias de acesso reenviado na rede monitorada,
o nmero de endereos IP do cliente exclusivo e a
quantidade total de dados observada durante todo o
perodo. Os conjuntos de dados rotulados como Home1
e Home2 consistem em clientes ADSL e Fiber to Home Comentado [MR10]: Interligao fibra de casa para casa
(FTTH) de um ISP nacional. Os clientes so
fornecidos com endereos IP estticos, mas eles
podem usar roteadores WiFi em casa para compartilhar
a conexo. Campus 1 e Campus 2 foram recolhidos em
ambientes acadmicos: o Campus 1 monitora
principalmente estaes de trabalho com fio em
pesquisas e servios administrativos do
departamento de informtica em uma universidade
europeia. O Campus 2 contabiliza todo o trfego nos
roteadores da fronteira de uma segunda universidade,
incluindo pontos de acesso sem fio no campus e casas
para estudantes. Neste ltimo cenrio, o proxy NAT
e HTTP so muito comuns e o trfego de DNS no foi
exposto sonda. Por razes de privacidade, nossas
sondas exportam apenas fluxos e as informaes
extras descritas na seo anterior. Todos os dados
da carga til so descartados diretamente na sonda.
Para completar nossa anlise, um segundo conjunto
de dados foi coletado no Campus 1 em junho/julho de
2012.

3.3 Popularidade de diferentes fornecedores de

armazenamento
Apresentamos uma comparao da popularidade dos
sistemas de armazenamento baseados na nuvem.
Consideramos explicitamente os seguintes servios:
Dropbox, Google Drive, Apple iCloud e Microsoft
SkyDrive. Outros servios menos conhecidos (por
exemplo, SugarSync, Box.com e UbuntuOne) foram
agregados ao grupo Outros. Confiamos tanto no nome
do servidor TLS extrado quanto no DNS FQDN para
classificar os fluxos como pertencentes a cada
servio. Primeiro, estudamos a popularidade dos
diferentes servios em termos de clientes nicos.
Usamos o conjunto de dados Home 1 porque os
endereos IP so atribudos de forma esttica s
famlias e, portanto, so uma estimativa confivel
do nmero de instalaes. fig.2(a) relata 6 o nmero
de endereos IP distintos que contataram pelo menos
uma vez um servio de armazenamento em um
determinado dia. O iCloud o servio mais acessado,
com cerca de 2.100 famlias (11,1%), mostrando a
alta popularidade dos dispositivos da Apple. O
Dropbox vem em segundo lugar, com cerca de 1.300
famlias (6,9%). Outros servios so muito menos
populares (por exemplo, 1,7% para o SkyDrive).
Curiosamente, o Google Drive aparece imediatamente
no dia do seu lanamento (24 de abril de 2012).
fig.2 (b) relata o volume total de dados para cada
servio no Home 1. O Dropbox est acima de todos os Comentado [MR11]: tops
outros servios em uma ordem de grandeza (observe a
escala logartmica y), com mais de 20GB de dados
trocados diariamente. O volume do iCloud limitado
apesar do maior nmero de dispositivos, porque o
servio no permite aos usurios sincronizar
arquivos arbitrrios. O SkyDrive e o Google Drive
mostram um aumento repentino do volume aps o
lanamento pblico em abril. Fig.3 compara o
compartilhamento de Dropbox e YouTube no volume
total de trfego no Campus 2. Alm da variao que
reflete o padro semanal e feriado, uma frao alta
vista para Dropbox diariamente. Observe que, nesta
rede, o trfego trocado com o Dropbox prximo de
100 GB por dia til: j existe 4% de todo o trfego
ou um volume equivalente a cerca de um tero do
trfego do YouTube no mesmo dia!
Essas descobertas destacam um crescente interesse
pelos sistemas de armazenamento baseados na nuvem,
mostrando que as pessoas esto ansiosas para usar o
espao de armazenamento remoto. O armazenamento em
nuvem j popular, com 6 a 12% dos usurios
domsticos acessando regularmente um ou mais dos
servios. Embora a popularidade dos sistemas
lanados recentemente possa aumentar no futuro, nos
seguintes restringimos a nossa ateno apenas para
o Dropbox, uma vez que , de longe, o sistema mais
usado em termos de volume de trfego no momento. O
trfego geral do Dropbox resumido na guia.3, onde
podemos ver o nmero de fluxos, volume de dados e
dispositivos ligados ao Dropbox nas redes
monitoradas. Nossos conjuntos de dados contam mais
de 11.000 dispositivos Dropbox, identificados
exclusivamente pelo seu host int (ver Seco 2.3.1).
O trfego gerado pela interface da Web e por API
pblica tambm est includo. No total, mais de 3,5
TB foram trocados com servidores Dropbox durante a
nossa captura.

2 imagens ------------------

4. DESEMPENHO DROPBOX
4.1 Desagregao do trfego: armazenamento e
controle
Para entender o desempenho do servio Dropbox e sua
arquitetura, primeiro estudamos a quantidade de
trfego manipulada pelos diferentes conjuntos de
servidores. fig.4 mostra a quebra do trfego
resultante em termos de volume de trfego e nmero
de fluxos. A partir da figura, surge que o
aplicativo cliente Dropbox responsvel por mais
de 80% do volume de trfego em todos os pontos de
vantagem, o que mostra que esse aplicativo
altamente preferido sobre as interfaces da Web para
trocar dados. Uma parcela significativa do volume
(de 7% a 10%) gerada por downloads de links diretos
e a principal interface da Web (ambos representados
como Web na fig.4). Nas redes domsticas, um volume
pequeno, mas no negligencivel, visto na API
Dropbox (at 4%). Finalmente, o volume de dados
causado pelas mensagens de controle insignificante
em todos os conjuntos de dados. Ao considerar o
nmero de fluxos, os servidores de controle so os
principais contribuidores (mais de 80% dos fluxos,
dependendo do conjunto de dados). A diferena na
porcentagem dos fluxos de notificao - cerca de 15%
no Campus 2, Home 1 e Home 2 e menos de 3% no Campus
1 - causada pela diferena na durao tpica das
sesses do Dropbox nessas redes, o que ser Mais
estudado na Sec. 5.5.
Imagem 1 ---------------------
4.2 Locais do servidor e RTT
Mostramos em sees anteriores que o protocolo de
cliente Dropbox depende de servidores diferentes
para realizar tarefas tpicas, como a sincronizao
de arquivos. O Dropbox distribui a carga entre seus
servidores, girando os endereos IP nas respostas
DNS e fornecendo diferentes listas de nomes DNS para
cada cliente. A seguir, queremos entender a
implantao geogrfica desta arquitetura e suas
consequncias no RTT percebido.
2 imagens -------------------

4.2.1 Localizaes do servidor

Nomes na guia.1 terminado por um sufixo numrico so
normalmente resolvidos para um endereo IP de
servidor nico7 e os clientes so responsveis por
selecionar qual servidor ser usado em uma
solicitao. Por exemplo, os servidores de meta-
dados so atualmente abordados por um pool fixo de
10 endereos IP e servidores de notificao por um
conjunto de 20 endereos IP. Os servidores de
armazenamento so abordados por mais de 600
endereos IP dos centros de dados da Amazon. Fig.5
mostra o nmero de servidores de armazenamento
contatados por dia em nossos pontos de vantagem. A
figura aponta que os clientes do Campus 1 e Home 2
no chegam a todos os servidores de armazenamento
diariamente. Tanto no Campus 2 quanto no Home 1,
mais servidores so contatados por causa do maior
nmero de dispositivos nesses pontos de vantagem.
As informaes de roteamento sugerem que os
servidores de controle esto localizados na Costa
Oeste dos Estados Unidos (provavelmente na
Califrnia), enquanto os servidores de
armazenamento esto na Costa Leste dos Estados
Unidos (aparentemente nos centros de dados da
Virgnia do Norte da Amazon). Para verificar a
configurao atual do Dropbox em todo o mundo,
realizamos medies ativas usando o PlanetLab. Ao
selecionar ns de 13 pases em 6 continentes,
verificamos quais endereos IP so obtidos ao
resolver os nomes de DNS do Dropbox vistos em nossas
medidas passivas, bem como as rotas e RTT ao entrar
em contato com os servidores. O experimento mostra
que o mesmo conjunto de endereos IP sempre
enviado aos clientes independentemente de suas
localizaes geogrficas. Isso vlido para nomes
de domnio de controle e armazenamento. As
informaes de rota e o RTT sugerem que os mesmos
centros de dados dos EUA observados em nossas
medidas passivas so os nicos utilizados em todo o
mundo. Ou seja, o Dropbox , como agora, um servio
centralizado nos EUA. Considerando que mais de
metade dos clientes da Dropbox esto fora do US 8 e
a grande quantidade de trfego observada em nossos
pontos de vista, o trfego trocado entre os clientes
e os centros de dados provavelmente j sero muito
relevantes na rede principal.

4.2.2 Armazenamento e controle RTT

Uma anlise mais profunda do RTT em nossos quatro
pontos de vantagem revela mais detalhes sobre a
implementao fsica da arquitetura Dropbox. Sec.
4.4 mostrar que o RTT tem um grande impacto no
desempenho do servio. Fig.6 mostra, separadamente
para o armazenamento ( esquerda) e os fluxos de
controle (direita), o CDF do RTT mnimo em fluxos
onde pelo menos 10 amostras RTT poderiam ser obtidas
(ver[14]). A figura representa apenas o RTT entre as
nossas sondas e os servidores, para filtrar o
impacto das tecnologias de acesso (por exemplo,
ADSL). Os RTTs para servidores de armazenamento na
Amazon permaneceram estveis durante nossas
medies, o que significa que no houve mudanas
significativas na topologia da rede. As diferenas
nos RTTs entre os pontos de vantagem esto
relacionadas aos pases onde as sondas esto
localizadas. Este RTT constante durante nossos 42
dias de medies outra forte indicao de que um
nico centro de dados foi usado por todos os
usurios em nossos pontos de vantagem. Os RTTs para
os servidores de controle so menos constantes.
Tanto no Campus 1 quanto no Home 2, a curva apresenta
pequenos passos (menos de 10ms). Assumimos que eles
so causados por mudanas na rota IP, j que o mesmo
comportamento no visvel em todas as sondas.
Tambm neste caso, as medidas sugerem um cluster de
servidores de controle central. Finalmente,
interessante notar a alta diferena no RTT entre os
centros de dados de controle e armazenamento. Isso
provavelmente causado pela distncia fsica entre
eles dentro dos EUA
----------------------2 figuras ------------------

4.3 Recuperar e armazenar fluxos

4.3.1 Tamanho do fluxo
Conforme mostrado na Fig.4, a maioria do trfego
gerada por operaes de armazenamento. A Fig.7
mostra o CDF do tamanho do fluxo para operaes de
armazenamento. Como o SSL usado, observamos um
tamanho de fluxo mnimo de aproximadamente 4kB. Os
fluxos tm um tamanho mximo de aproximadamente
400MB devido aos parmetros de tempo de execuo
atuais do Dropbox. Os lotes so limitados a um
mximo de 100 pedaos, cada um menor ou igual 4MB,
conforme descrito na Seco2. da Fig.7, surge que
uma porcentagem significativa de fluxos (at 40% em
alguns casos) troca menos de 10kB, o que significa
que eles so compostos principalmente por mensagens
de handshake SSL e uma pequena quantidade de dados
do usurio. Uma percentagem muito elevada de fluxos
(variando de 40% a 80%) consistem em menos de 100kB.
Supomos que dois fatores esto causando esse Comentado [MR12]: We conjecture
comportamento:
(i) o protocolo de sincronizao enviando e
recebendo arquivos deltas assim que forem
detectados; (ii) o uso principal do Dropbox para a
sincronizao de pequenos arquivos mudou
constantemente, em vez de backups peridicos
(grandes). Comparando os CDFs para as operaes de
recuperao e armazenamento, podemos ver que os
fluxos de recuperao normalmente so maiores que
os armazenados. Isto particularmente visvel nos
conjuntos de dados Campus 1, Campus 2 e Home 1. Por
exemplo, enquanto 60% dos fluxos de armazenamento
no Home 1 no tm mais de 100kB, a porcentagem de
cerca de 40% para recuperar fluxos na mesma rede.
Isso pode ser parcialmente explicado pela primeira
ocorrncia de sincronizao em lote quando as
sesses so iniciadas. Alm disso, observamos uma
grande quantidade de dispositivos usando o Dropbox
apenas para baixar o contedo. Este uso ser
analisado ainda mais nas prximas sees. Tambm
destacamos uma discrepncia notvel no CDF para os
fluxos de armazenamento no Home 2. Um nico
dispositivo foi enviar pacotes nicos em conexes
TCP consecutivas durante vrios dias em nossa
captura. Isso fez com que o CDF fosse fortemente
tendencioso em direo ao tamanho mximo do bloco
usado pelo Dropbox (4MB). No foi possvel
determinar se esse comportamento devido a
problemas no cliente Dropbox manifestado neste nico
dispositivo ou outro uso legtimo do servio.
-------- fig. 8---------------

4.3.2 Pedaos por lote

Fig.8 representa o CDF do nmero estimado de trocas
por fluxo. As curvas mostram que a maioria dos lotes
so compostos por um pequeno nmero de pedaos. Os
fluxos de armazenamento no tm mais de 10 pedaos
em mais de 80% dos casos em todos os conjuntos de
dados. A distribuio do Home 2 diverge devido ao
comportamento do cliente nico descrito
anormalmente na seo anterior. Essas distribuies
reforam nossa conjectura sobre o domnio dos deltas
e pequenos arquivos nos hbitos de uso do Dropbox:
a maioria dos fluxos muito pequena e composta por
alguns pedaos. A maioria dos fluxos remanescentes
tem o nmero mximo permitido de pedaos por lote
e, portanto, so fortemente moldados pelo projeto
de protocolo do Dropbox

4.4 Volume de armazenamento

Nossas medidas na Sec.4.2 indicam que o Dropbox
depende de centros centralizados de dados para
controle e armazenamento. Isso levanta a questo
sobre o desempenho do servio para usurios que no
esto localizados perto desses centros de dados. O
throughput das operaes de armazenamento Comentado [MR13]: taxa de transferncia
certamente uma das principais mtricas de
desempenho. A fig.9 mostra o rendimento alcanado
por cada fluxo de armazenamento no Campus2. A figura
mostra parcelas separadas para as operaes de
recuperao e armazenamento. Parcelas similares
sero obtidas usando o conjunto de dados do Campus
1. Home1 e Home2 so excludos desta anlise, uma
vez que a tecnologia de acesso (ADSL, em particular)
pode ser um gargalo para o sistema nessas redes. O
eixo x representa o nmero de bytes transferidos no
fluxo, j subtraindo as despesas gerais tpicas de
SSL (veja o Apndice A para detalhes), enquanto o
eixo y mostra o caudal calculado como a relao
entre os bytes transferidos e a durao de cada
fluxo (nota as escalas logartmicas). A durao foi
contabilizada como o tempo entre o primeiro pacote
TCP SYN e o ltimo pacote com carga til no fluxo,
ignorando os atrasos na terminao da conexo. Os
fluxos so representados por marcas diferentes de
acordo com o nmero de pedaos. No geral, o
throughput notavelmente baixa. O rendimento mdio Comentado [MR14]: taxa de transferncia
(marcado com linhas horizontais tracejadas na
figura) no superior a 462kbits/s para fluxos de
armazenamento e 797kbits/s para recuperar fluxos em
Campus 2 (359kbits/s e 783kbits/s no Campus 1,
respectivamente). Em geral, o rendimento observado
mais alto (perto de 10Mbits/s em ambos datasets) s Comentado [MR15]: Conjunto de dados
alcanado por fluxos que transportam mais de 1MB.
Alm disso, os fluxos alcanam menor dbito medida
que o nmero de pedaos aumenta. Isso pode ser visto
pela concentrao de fluxos com grande nmero de
pedaos na parte inferior das parcelas para qualquer
tamanho determinado.
Os tempos de inicializao de TCP e os
reconhecimentos seqenciais da camada de aplicao
so dois fatores principais que limitam a taxa de
transferncia, afetando fluxos com uma pequena
quantidade de dados e fluxos com um grande nmero
de blocos, respectivamente. Em ambos os casos, o RTT
elevado entre clientes e centros de dados amplifica
os efeitos. A seguir, esses problemas so
detalhados.

----------------2 figuras --------------

4.4.1 Efeitos de inicializao do TCP

Os fluxos que carregam uma pequena quantidade de
dados so limitados pelos tempos de inicializao
do TCP lento. Isto particularmente relevante nas
redes de campus analisados, uma vez que a capacidade
de ligao de dados e o RTT aos centros de dados de
armazenamento so elevados nessas redes. A Fig.9
mostra o rendimento mximo para completar a
transferncia de uma quantidade especfica de dados,
assumindo que os fluxos permaneceram na fase de
incio lento TCP. Calculamos a latncia como em [4],
com janela de congestionamento inicial de 3
segmentos e ajustando a frmula para incluir
despesas gerais (por exemplo, os 3 RTTs de
handshakes SSL na configurao atual do Dropbox). A
Fig.9 mostra que aproxima o rendimento mximo
satisfatoriamente. Isso claro para os fluxos com
um nico pedao, que sofrem menos com os
impedimentos da camada de aplicao. O limite no
apertado para recuperar fluxos, pois sua latncia
inclui pelo menos 1 tempo de reao do servidor.
Observe que o throughput ainda pode ser limitado por
outros fatores, como a seleo explcita do usurio
de limites de transferncia ou o possvel
congestionamento da rede. No entanto, ao considerar
apenas os fluxos com um nico pedao, mais de 99%
dos fluxos de armazenamento e cerca de 95% dos
fluxos de recuperao no Campus 1 no possuem
retransmisses TCP. Estas percentagens so mais
baixas no Campus 2 (88% e 75%) devido aos pontos de
acesso sem fio. Os fluxos de um nico pedao sem
transmisso de experincias de retransmisso perto
do limite (por exemplo, -17% em mdia para fluxos
de armazenamento no Campus 1), confirmando que o
incio do TCP o principal gargalo.

4.4.2 Reconhecimentos sequenciais

Os fluxos com mais de 1 pedao tm o esquema de
reconhecimento sequencial (Fig.1) como um gargalo
porque o mecanismo fora os clientes a esperar um
RTT (mais o tempo de reao do servidor) entre duas
operaes de armazenamento. Naturalmente, os fluxos
que transportam um grande nmero de pequenos pedaos
sofrem relativamente mais desse impedimento do que
os fluxos com grandes pedaos. A Fig.8 mostra que
mais de 40% dos fluxos tm pelo menos 2 pedaos e
so potencialmente afetados por isso. Os fluxos com
vrios pedaos tambm so afetados pelos fatores
descritos anteriormente. Alm disso, o cliente
Dropbox mantm conexes de armazenamento abertas por
um curto intervalo depois de transferir um pedao,
aguardando novos pedaos. Portanto, alguns fluxos
na Fig.9 pode ter uma durao mais longa porque
foram reutilizados durante este intervalo ocioso.
Para remover esses efeitos e realar o impacto de
reconhecimentos sequenciais, dividimos o eixo x da
fig.9 em slots de tamanhos iguais (em escala
logartmica) e, para cada slot, selecione o fluxo
com o rendimento mximo em cada um dos quatro grupos
mostrados na figura. Fig.10 mostra a durao desses
fluxos representativos. Fluxos com mais de 50
pedaos, por exemplo, sempre duram mais de 30s,
independentemente dos tamanhos. Considerando o RTT
no Campus 2, at um tero disso (5-10s)
desperdiado enquanto os reconhecimentos da camada
de aplicao esto transitando a rede. A durao
restante principalmente devido ao servidor e aos
tempos de reao do cliente entre os chunks. Comentado [MR16]: trocas

------------- tabela -------------------

4.5 Implicaes e recomendaes

Nossas medidas indicam claramente que o protocolo
de camada de aplicao em combinao com RTT grande
penaliza o desempenho do sistema. Identificamos trs
possveis solues para remover os estrangulamentos
identificados:
1. Agrupar pequenos pedaos, aumentando a
quantidade de dados enviados por operao de
armazenamento. O Dropbox 1.4.0, anunciado em
abril de 2012, implementa um mecanismo de
agrupamento, que analisado no seguinte;
2. Usando um esquema de confirmao atrasada nas
operaes de armazenamento, trocados de
pipelining para remover os efeitos de
confirmaes sequenciais;
3. Trazendo os servidores de armazenamento mais
perto dos clientes, melhorando assim o
rendimento global.
Observe que as duas primeiras contramedidas visam
apenas o gargalo da camada de aplicao. O terceiro,
embora vlido para qualquer servio on-line, teria
o impacto extra positivo de remover o trfego de
armazenamento pesado do ncleo da internet.
4.5.1 Melhorias no Dropbox 1.4.0
A ltima verso do Dropbox acrescenta dois comandos
(armazenar lote e recuperar lote), permitindo que
vrios blocos sejam submetidos em uma nica
operao.9 Os comandos de um nico pedao ainda
esto em uso: o sistema decide em tempo de execuo
se os blocos sero agrupados ou no. Utilizamos
dados extra capturados no Campus 1 durante junho e
julho de 2012 para quantificar os efeitos desse
mecanismo no desempenho do sistema.
Aba.4 compara o tamanho do fluxo e as distribuies
de transferncia antes e depois da implantao do
Dropbox 1.4.0.
O aumento no tamanho do fluxo mdio mostra que os
fluxos se tornam maiores, provavelmente porque mais
pequenos pedaos podem ser acomodados em uma nica
conexo TCP nesta verso. As mdias so menos
afetadas, uma vez que apenas fluxos menores se
beneficiam do mecanismo. Tanto a mdia como a mdia
de produo, por outro lado, so dramaticamente
melhoradas. O rendimento mdio dos fluxos de
recuperao, por exemplo, cerca de 65% maior no
conjunto de dados mais recente.
Uma vez que os novos comandos do lote e os comandos
do singlechunk so ainda executados Comentado [MR17]: trocas unica
sequencialmente, parece existir espao para
melhorias no protocolo. Uma caracterizao completa
disso , no entanto, fora do alcance deste artigo.
Tal anlise ser realizada no futuro trabalho,
juntamente com um estudo da eficcia e possveis
inconvenientes de cada uma de nossas recomendaes.

---------- 2 tabelas ----------

5. SERVICE WORKLOAD (GUIA DE SERVIO)
5.1 Volume de armazenamento
Nesta seo, correlacionamos clientes ISP
(endereos IP) em redes domsticas e o volume de
armazenamento total em operaes de recuperao e
armazenamento. A quantidade de dados recuperados e
armazenados por domiclio retratada na Fig.11.
Cada endereo IP representado por um ponto e
diferentes smbolos so usados para ilustrar o
nmero de dispositivos por trs do endereo IP.
Note-se que colocamos todos os casos com menos de
1kB nos eixos devido s escalas logartmicas. A
figura conta apenas para as transferncias feitas a
partir do cliente Dropbox. De forma semelhante
Sec.4.4, a sobrecarga tpica das negociaes de SSL
foi subtrada do valor transferido.
Fig.11 mostra que os usurios do Dropbox tendem a
baixar mais do que carregar. Isso visvel na
densidade de pontos abaixo das diagonais. No geral,
o total de dados baixados no Campus 2 2,4 vezes
superior ao total de dados carregados. Essa relao
igual a 1,6 e 1,4 no Campus 1 e Home 1,
respectivamente. Home 2 uma exceo: a proporo
de aproximadamente 0,9 nesta rede. Alguns clientes
que carregaram massivamente o contedo criaram essa
divergncia. Esses clientes aparecem no canto
superior direito da Fig.11(b). Note-se que um desses
clientes tambm responsvel pelo vis na CDF
representada na fig.7 em ambos os conjuntos de
dados, quatro cenrios de uso podem ser
identificados:
(i) Usurios ocasionais, que abandonam seus clientes
Dropbox, dificilmente sincronizando qualquer
contedo (pontos prximos s origens);
(ii) usurios de upload nico que enviam arquivos
principalmente (pontos prximos aos eixos y);
(iii) usurios de download exclusivo, executando
operaes predominantemente recuperadas (pontos
prximos aos eixos x);
(iv) usurios pesados que armazenam e recuperam
grandes quantidades de dados (pontos ao longo das
diagonais). A proporo de usurios em cada grupo
explica a relao geral entre downloads e uploads
vistos na Fig.11.
Tabela 5 quantifica os grupos. Os endereos IP so
divididos de acordo com as seguintes heursticas:
os endereos IP que tm menos de 10kB em ambas as
operaes de recuperao e armazenamento esto
includos no grupo ocasional; Os endereos IP que
possuem mais de trs ordens de grandeza de diferena
entre upload e download (por exemplo, 1GB versus
1MB) esto includos apenas em download ou upload-
only; Todos os outros esto no grupo pesado. Para
cada grupo, a tabela mostra a percentagem grupal de
endereos IP e sesses, o total de dados
transferidos, o nmero mdio de dias em que os
dispositivos foram vistos online e a mdia de
dispositivos por domiclio.
O grupo ocasional representa cerca de 30% dos
endereos IP totais em ambos os pontos de vantagem.
Como esperado, os clientes deste grupo trocam uma
quantidade insignificante de dados e ficam online
no Dropbox menos tempo quando comparados aos outros.
Eles tambm tm a menor quantidade mdia de
dispositivos. Este grupo, portanto, gera
marginalmente qualquer carga no sistema. O grupo
upload-only representa cerca de 7% dos endereos IP
e responsvel por uma quantidade significativa de
uploads (21% no Home 1 e 11% no Home 2). Considerando
o baixo nmero de dispositivos, os usurios deste
grupo parecem estar interessados em Dropbox para
backups e para submisso de contedo a terceiros ou
a dispositivos geograficamente dispersos. O
comportamento oposto pode ser concludo para o grupo
de download exclusivo. Este grupo , no entanto,
muito significativo tanto no nmero de endereos IP
(26% no Home 1 quanto em 28% no Home 2) e no volume
transferido (25% e 28%, respectivamente). Da mesma
forma que o grupo de upload-only, um nmero moderado
de dispositivos por endereo IP visto neste grupo.
Finalmente, representando 37% dos endereos IP no
Home 1 e 33% no Home 2, o grupo pesado responsvel
pela maior parte do volume transferido pelos
clientes da Dropbox. Os clientes deste grupo possuem
um elevado nmero de dispositivos (acima de 2 em
mdia), aparecem em linha mais de 60% dos dias em
nossa captura e so responsveis por mais de 50% das
sesses do Dropbox. O uso do Dropbox para a
sincronizao de dispositivos em uma casa parece ser
o cenrio tpico desse grupo. Esses so, portanto,
os usurios causando o maior impacto na carga de
trabalho do sistema e na utilizao da rede.

5.2 Dispositivos
Nesta seo, descrevemos a distribuio do nmero
de dispositivos que residem na mesma LAN. Os
dispositivos conectados mesma LAN podem fazer uso
do protocolo LAN Sync para sincronizar arquivos sem
recuperar o contedo duplicado da nuvem. A Fig.12
mostra a distribuio do nmero de dispositivos por
endereo IP em Home 1 e Home 2.
Em cerca de 60% dos agregados familiares que
utilizam o cliente Dropbox, existe apenas um nico
dispositivo ligado ao servio. A maioria dos
agregados familiares remanescentes tem at 4
dispositivos e, surpreendentemente, fazem parte do
grupo pesado identificado na seo anterior. Ao
inspecionar um subconjunto de conexes de
notificao no Home 1, observamos que em cerca de
60% das famlias com mais de 1 dispositivo (cerca
de 25% do total), pelo menos 1 pasta compartilhada
entre os dispositivos. Isso confirma ainda mais
nossas descobertas sobre o uso tpico do Dropbox
entre usurios pesados para a sincronizao de
dispositivos. Desde o trfego da LAN SyncProtocol
no atinge nossas sondas, no podemos quantificar a
quantidade de largura de banda salva nestas casas
pelo uso do protocolo. Contudo, podemos concluir que
no mais de 25% das famlias esto lucrando com
isso. Os usurios restantes sempre contam com
datacenters de armazenamento central para suas
transferncias de dados.

5.3 Pastas Compartilhadas

Para medir at que ponto o Dropbox est sendo usado
para compartilhamento de contedo ou trabalho
colaborativo, ns analisamos identificaes de
namespace no trilho Home 1 e Campus 1 (no Home 2 e
no Campus 2 esta informao no foi exposta). A
Fig.13 mostra a distribuio do nmero de espaos
de nomes por dispositivo. Ao analisar os dados do
Campus 1 em datas diferentes, possvel concluir
que o nmero de espaos de nomes por dispositivo no
estacionrio e tem uma tendncia ligeiramente
crescente. FIG. 13 foi construdo considerando o
ltimo nmero observado de espaos de nomes em cada
dispositivo em nossos conjuntos de dados. Em ambas
as redes, o nmero de usurios com apenas 1
namespace (a pasta raiz dos usurios) pequeno: 13%
no Campus 1 e 28% no Home 1. Em geral, os usurios
no Campus 1 tm mais namespaces do que no Home 1. A
porcentagem de usurios com 5 ou mais namespaces
igual a 50% no primeiro e 23% nos ltimos. Ao
considerar apenas os endereos IP atribudos s
estaes de trabalho no Campus 1, cada dispositivo
possui, em mdia, 3,86 namespaces.
5.4 Uso dirio
Caracterizamos se o uso do cliente Dropbox tem
alguma sazonalidade tpica. Fig.14 mostra a srie
temporal do nmero de dispositivos distintos
iniciando uma sesso Dropbox em cada ponto de vista
por dia. As sries temporais so normalizadas pelo
nmero total de dispositivos em cada conjunto de
dados. Cerca de 40% de todos os dispositivos iniciam
pelo menos uma sesso todos os dias em redes
domsticas, incluindo fins de semana.10 Nas redes
de campus, por outro lado, h uma forte sazonalidade
semanal. Em uma escala de tempo mais fina (caixas
de 1 hora), observamos que o uso do servio segue
um padro de dia-noite claro. A Fig. 15 mostra o uso
dirio do cliente Dropbox. Todas as parcelas foram
produzidas pela mdia das quantidades por intervalo
em todos os dias teis em nossos conjuntos de dados.
A Fig.15 (a) mostra a frao de dispositivos
distintos que iniciam uma sesso em cada intervalo,
enquanto a Fig. 15 (b) representa a frao de
dispositivos que esto ativos (isto , esto
conectados ao Dropbox) por intervalo de tempo. A
partir desses nmeros, podemos ver que o uso do
Dropbox varia fortemente em diferentes locais,
seguindo a presena de usurios no ambiente. Por
exemplo, no Campus 1, as startups de sesso tm uma
relao clara com o horrio de trabalho dos
funcionrios. As iniciaes de sesso so melhor
distribudas durante o dia no Campus 2 como
consequncia do trnsito de alunos em pontos de
acesso sem fio. Nas redes domsticas, picos de
startups so vistos no incio da manh e durante a
noite. No geral, todas as sries temporais de
dispositivos ativos (Fig.15(b)) so suaves,
mostrando que o nmero de usurios ativos a qualquer
hora do dia facilmente previsvel. Fig.15 (c) e
15 (d) representam a frao do nmero total de bytes
trocados em cada intervalo de tempo em recuperar e
armazenar funes, respectivamente. Fig.15 (c)
mostra que o nmero de bytes recebidos nas operaes
de recuperao tem uma correlao com a
inicializao de clientes. Isso sugere que a
primeira sincronizao aps o incio de um
dispositivo dominada pelo download de contedo
produzido em outro lugar, em vez do upload de
contedo produzido enquanto no est disponvel.
Embora outros padres sejam visveis nas figuras,
como a concentrao de downloads pela manh no
Campus 1 e noite no Home 1, ambas as sries ainda
so muito barulhentas nesse nvel de agregao.

5.5 Durao da sesso

Analisamos a durao da sesso com base nos fluxos
TCP para os servidores de notificao. Home 1, Home
2 e Campus 2 tm um comportamento semelhante em
geral, como mostrado na Fig. 16, com uma exceo
para o nmero de sesses de curta durao. Em ambas
as redes domsticas, um nmero significativo de
fluxos de notificao so encerrados em menos de 1
minuto. Uma inspeo mais prxima revela que a
maioria desses fluxos so de poucos dispositivos. O
comportamento divergente do TCP sugere que os
equipamentos de rede (por exemplo, NAT ou firewalls
- veja [10]) podem estar terminando abruptamente
conexes de notificao. Considerando o
funcionamento normal do protocolo Dropbox, as
conexes de notificao so reestabelecidas
imediatamente depois disso. A maioria dos
dispositivos em Home 1, Home 2 e Campus 2 permanecem
conectados at 4 horas em uma nica sesso. No
Campus 1, uma porcentagem significativamente maior
de sesses duradouras vista. Isso pode ser
explicado pela prevalncia de estaes de trabalho
em uma rotina de trabalho tpica de 8 horas. As
inflexes na cauda das distribuies so vistas em
todas as curvas, como consequncia dos dispositivos
mantidos sempre on-line.
5.6 Implicaes
Os resultados nesta seo ajudam a entender o uso
atual do cliente Dropbox. Isso necessrio, por
exemplo, para provisionar centros de dados e redes
para lidar com o trfego de armazenamento na nuvem.
Nossa anlise dos comportamentos tpicos dos
usurios revela que os usurios tm interesses
diferentes na aplicao. Por exemplo, embora o
Dropbox j esteja instalado em mais de 6% dos
domiclios (ver Sec. 3.3), menos de 40% dessas
famlias esto usando completamente as suas
funcionalidades, isto , sincronizar dispositivos,
compartilhar pastas, etc. Curiosamente, os
resultados so Muito semelhante em ambas as redes
domsticas, reforando nossas concluses. A grande
quantidade de trfego criada por esta porcentagem
limitada de usurios motiva nossas expectativas de
que os sistemas de armazenamento na nuvem estaro
entre as principais aplicaes que produzem o
trfego da Internet em breve. No entanto, fontes
geograficamente dispersas e dados longitudinais so
necessrios para verificar se as concluses desta
seo podem ser generalizadas, medida que mais
pessoas adotam essas solues.

6. ARMAZENAGEM WEB
Alm do aplicativo cliente, o Dropbox permite que
os usurios acessem pastas e arquivos compartilhados
usando sua principal interface da Web e um mecanismo
de download de links diretos. A seguir, analisamos
o uso dessas interfaces. A Fig. 17 apresenta os CDFs
do nmero de bytes nos fluxos de armazenamento da
interface da Web principal do Dropbox. So
apresentados CDFs separados para uploads e
downloads.
Considerando o nmero de bytes carregados, fica
claro que a interface da Web principal dificilmente
usada para carregar contedo. Mais de 95% dos
fluxos enviados com menos de 10kB. Ao considerar os
bytes baixados, at 80% dos fluxos trocaram menos
10kB. Essas distribuies so, no entanto,
fortemente tendenciosas em relao aos tamanhos de
handshake do SSL por dois motivos: (i) a interface
Dropbox recupera as miniaturas dos servidores de
armazenamento usando o SSL; (ii) Os navegadores da
Web abrem vrias conexes paralelas ao recuperar
esses objetos HTTP.
Os fluxos remanescentes tm menos de 10MB em mais
de 95% dos casos, mostrando que apenas arquivos
pequenos so normalmente recuperados desta
interface da Web.Alm disso, analisamos fluxos
relacionados a downloads de links diretos. Observe
que esses fluxos correspondem a 92% dos fluxos de
armazenamento da Web Dropbox no Home 1, confirmando
que esse mecanismo altamente preferido sobre a
interface principal da Dropbox. A Fig.18 mostra o
CDF do tamanho das transferncias de links
diretos.11 Dado que esses downloads nem sempre so
criptografados, o CDF no possui o limite inferior
SSL. Curiosamente, apenas uma pequena porcentagem
de downloads de links diretos maior que 10MB,
sugerindo que seu uso no est relacionado ao
compartilhamento de filmes ou arquivos.

7. CONCLUSES
Para o nosso melhor conhecimento, somos os primeiros
a analisar o uso da Dropbox na internet. Nossa
anlise avaliou o crescente interesse em sistemas
de armazenamento baseados em nuvem. Principais
jogadores como Google, Apple e Microsoft esto
oferecendo o servio. Mostramos que, nesta paisagem,
o Dropbox atualmente o fornecedor mais popular de
um sistema desse tipo.
Ao analisar os fluxos capturados em 4 pontos de
vantagem na Europa ao longo de um perodo de 42 dias
consecutivos, mostramos que
A Dropbox agora responsvel por um volume de
trfego considervel. Em um de nossos conjuntos de
dados, por exemplo, o Dropbox j equivalente a um
tero do trfego do YouTube. Apresentamos uma
extensa caracterizao da Dropbox, tanto em termos
da carga de trabalho do sistema quanto do uso
tpico. Nossas principais descobertas mostram que o
desempenho do servio Dropbox altamente afetado
pela distncia entre os clientes e os centros de
dados, que atualmente esto localizados nos EUA. O
uso de reconhecimentos per-chunk no protocolo do
cliente combinado com os tamanhos tipicamente
pequenos do tamanho profundamente Limita o
rendimento efetivo do servio. Neste artigo,
identificamos duas possveis melhorias no
protocolo:
(i) o uso de um esquema de agrupamento de partes;
(ii) a introduo de reconhecimentos demorados.
Mostramos que a implantao recente de um mecanismo
de agrupamento melhorou o desempenho do sistema
dramaticamente. Alm disso, esperamos que o
desempenho geral seja melhorado pela implantao de
outros centros de dados em diferentes locais. Quanto
carga de trabalho tpica do sistema Dropbox, nossa
anlise mostrou uma variedade de comportamentos de
usurios. Por exemplo, um nmero considervel de
usurios aproveitam as funcionalidades Dropbox,
armazenando e recuperando arquivos e compartilhando
vrias pastas. No entanto, tambm observamos que
cerca de um tero dos usurios abandonam
completamente seus clientes, raramente trocando
dados durante os 42 dias de observaes.

9. REFERENCES
[1] A. Bergen, Y. Coady, and R. McGeer. Client
Bandwidth: The Forgotten Metric of Online Storage
Providers. In Proceedings of the 2011 IEEE Pacific
Rim Conference on Communications, Computers and
Signal Processing, PacRim2011, pages 543548,
2011.
[2] I. Bermudez, M. Mellia, M. M. Munaf`o,
R. Keralapura, and A. Nucci. DNS to the Rescue:
Discerning Content and Services in a Tangled Web.
In
Proceedings of the 12th ACM SIGCOMM Conference
on Internet Measurement, IMC12, 2012.
[3] M. Cha, H. Kwak, P. Rodriguez, Y.-Y. Ahn, and
S. Moon. I Tube, You Tube, Everybody Tubes:
Analyzing the Worlds Largest User Generated
Content Video System. In Proceedings of the 7th ACM
SIGCOMM Conference on Internet Measurement,
IMC07, pages 114, 2007.
[4] N. Dukkipati, T. Refice, Y. Cheng, J. Chu,
T. Herbert, A. Agarwal, A. Jain, and N. Sutin. An
Argument for Increasing TCPs Initial Congestion
Window. SIGCOMM Comput. Commun. Rev.,
40(3):2633, 2010.
[5] A. Finamore, M. Mellia, M. Meo, M. M. Munaf`o,
and
D. Rossi. Experiences of Internet Traffic Monitoring
with Tstat. IEEE Network, 25(3):814, 2011.
[6] A. Finamore, M. Mellia, M. M. Munaf`o, R.
Torres,
and S. G. Rao. YouTube Everywhere: Impact of
Device and Infrastructure Synergies on
UserExperience. In Proceedings of the 11th ACM
SIGCOMM Conference on Internet Measurement,
IMC11, pages 345360, 2011.
[7] M. Gjoka, M. Sirivianos, A. Markopoulou, and
X. Yang. Poking Facebook: Characterization of OSN
Applications. In Proceedings of the First Workshop
on
Online Social Networks, WOSN08, pages 3136, 2008.
[8] S. Halevi, D. Harnik, B. Pinkas, and
A. Shulman-Peleg. Proofs of Ownership in Remote
Storage Systems. In Proceedings of the 18th ACM
Conference on Computer and Communications
Security, CCS11, pages 491500, 2011.
[9] D. Harnik, B. Pinkas, and A. Shulman-Peleg. Side
Channels in Cloud Services: Deduplication in Cloud
Storage. IEEE Security and Privacy, 8(6):4047,
2010.
[10] S. Hatonen, A. Nyrhinen, L. Eggert, S.
Strowes,
P. Sarolahti, and M. Kojo. An Experimental Study of
Home Gateway Characteristics. In Proceedings of the
10th ACM SIGCOMM Conference on Internet
Measurement, IMC10, pages 260266, 2010.
[11] W. Hu, T. Yang, and J. N. Matthews. The Good,
the
Bad and the Ugly of Consumer Cloud Storage. ACM
SIGOPS Operating Systems Review, 44(3):110115,
2010.
[12] A. Lenk, M. Klems, J. Nimis, S. Tai, and
T. Sandholm. Whats Inside the Cloud? An
Architectural Map of the Cloud Landscape. In
Proceedings of the 2009 ICSE Workshop on Software
Engineering Challenges of Cloud Computing,
CLOUD09, pages 2331, 2009.
[13] A. Li, X. Yang, S. Kandula, and M. Zhang.
CloudCmp: Comparing Public Cloud Providers. In
Proceedings of the 10th ACM SIGCOMM Conference
on Internet Measurement, IMC10, pages 114, 2010.
[14] M. Mellia, M. Meo, L. Muscariello, and D.
Rossi.
Passive Analysis of TCP Anomalies. Computer
Networks, 52(14):26632676, 2008.
[15] A. Mislove, M. Marcon, K. P. Gummadi, P.
Druschel,
and B. Bhattacharjee. Measurement and Analysis of
Online Social Networks. In Proceedings of the 7th
ACM SIGCOMM Conference on Internet
Measurement, IMC07, pages 2942, 2007.
[16] M. Mulazzani, S. Schrittwieser, M. Leithner,
M. Huber, and E. Weippl. Dark Clouds on the
Horizon: Using Cloud Storage as Attack Vector and
Online Slack Space. In Proceedings of the 20th
USENIX Conference on Security, SEC11, 2011.
[17] G. Wang and T. E. Ng. The Impact of
Virtualization
on Network Performance of Amazon EC2 Data
Center. In Proceedings of the 29th IEEE INFOCOM,
pages 19, 2010.
[18] Q. Zhang, L. Cheng, and R. Boutaba. Cloud
Computing: State-of-the-Art and Research
Challenges. Journal of Internet Services and
Applications, 1:718, 2010.
[19] M. Zhou, R. Zhang, W. Xie, W. Qian, and A.
Zhou.
Security and Privacy in Cloud Computing: A Survey.
In Sixth International Conference on Semantics
Knowledge and Grid, SKG10, pages 105112, 2010.

------------- APNDICE --------------------

A. TRFEGO DE ARMAZENAMENTO EM DETALHES
A.1 Fluxos tpicos
FIG. 19 mostra fluxos de armazenamento tpicos
observados em nosso banco de provas.
Todos os pacotes trocados durante handshakes
iniciais e finais so
Retratado. As fases de transferncia de dados (em
cinza) so encurtadas
Por causa do espao. Elementos-chave para a nossa
metodologia,Tais como segmentos TCP com conjunto de
sinalizadores PSH e duraes de fluxo, so
destacados. Para confirmar que esses modelos so
vlidos em clientes reais, o Tstat no Campus 1
estava configurado para registrar estatsticas
sobre as 10 primeiras mensagens delimitadas por
segmentos TCP com conjunto de sinalizadores PSH. A
seguir, mais detalhes de nossa metodologia e os
resultados desta validao so apresentados.
A.2 Marcao de fluxos de armazenamento
Os fluxos de armazenamento so identificados pela
primeira vez usando FQDNs e SSL nomes de
certificados, conforme explicado na Sec.3.1. Depois
disso, eles so classificados com base no nmero de
bytes enviados por cada ponto final da conexo TCP.
O mtodo foi construdo com base no pressuposto de
que um fluxo de armazenamento usado para armazenar
pedaos ou para recuperar pedaos, mas nunca para
ambos. Esta suposio suportada por dois fatores:
(i) quando ambas as operaes ocorrem em paralelo,
Dropbox usa separada conexes para acelerar a
sincronizao; (ii) armazenamento ocioso as
conexes so mantidas abertas esperando por novos
comandos apenas por um curto intervalo de tempo
(60s).

Nossa suposio pode ser possivelmente violada

durante este ocioso intervalo. Na prtica, no
entanto, isso parece ser dificilmente o caso. Fig.20
ilustra que, ao traar o nmero de bytes em fluxos
de armazenamento no Campus 1. Os fluxos esto
concentrados perto os eixos, como esperado sob nossa
suposio.
Fluxos na Fig. 20 j esto divididos em grupos. O
limite entre regies de armazenamento e recuperao
determinada pela funo F (u) = 0,67 (u - 294) +
4103, onde voc o nmero de bytes carregados. Esta
funo foi empiricamente definida usando a
informao extra recolhida no Campus 1, onde o
seguimento foi observado:
As operaes de armazenamento e recuperao exigem
pelo menos 309 bytes de sobrecarga de servidores;
As operaes de armazenamento e recuperao exigem
pelo menos 634 e 362 bytes de despesas gerais de
clientes, respectivamente;
Normalmente, handshakes SSL exigem 294 bytes de
clientes e 4103 bytes de servidores.
F (u) centralizado entre as regies determinadas
de acordo com essas constantes. Para melhorar a
visualizao, as despesas gerais do SSL so
subtrados de cada ponto da figura.
Como as mquinas clientes no Campus 1 so
relativamente homogneas, a diferena entre os dois
grupos muito clara nessa conjunto de dados. Mais
variao no tamanho das mensagens observada em
outros pontos de vantagem. Os apertos de mo SSL,
em particular, so afetados Por diferentes
configuraes de software. No entanto, isso no
alterar consideravelmente as regies de cada
operao de armazenamento quando comparado ao Campus
1.
A.3 Nmero de pedaos
O nmero de pedaos transportados em um fluxo de
armazenamento (c) estimado contando segmentos TCP
com o conjunto de sinalizao PSH na direo inversa
da transferncia, conforme indicado na Fig. 19.
Para recuperar fluxos, c = s-22
. Para fluxos de lojas c = s - 3 ou
C = s - 2, dependendo se a conexo passivamente
Fechado pelo servidor ou no. Isso pode ser inferido
pela diferena horria entre o ltimo pacote com
carga til do cliente e o ltimo do servidor: quando
o servidor fecha uma conexo ociosa, espera-se que
a diferena seja de cerca de 1 minuto (caso
contrrio, apenas alguns segundos). Tstat j
registra os carimbos de hora de tais pacotes por
padro.
Ns validamos essa relao dividindo a quantidade
de carga til (sem handshakes SSL tpicos) na
direo inversa de uma transferncia por c. Essa
proporo deve ser igual a sobrecarga necessria por
operao de armazenamento. FIG. 21 mostra que, para
a grande maioria dos fluxos de lojas, a proporo
de cerca de 309 bytes por pedao, como esperado. Em
Home 2, o cliente aparentemente mal comportado
descrito na Sec. 4.3 preconceitos a distribuio: a
maioria dos fluxos deste cliente no possui
reconhecimento mensagens. A maioria dos fluxos de
recuperao tem uma proporo entre 362 e 426 bytes
por pedao, que so tamanhos tpicos da solicitao
HTTP neste comando. As excees (3% - 8%) podem ser
causadas por perda de pacotes em nossas sondas, bem
como pelos fluxos que armazenaram e recuperaram os
pedaos. Nosso mtodo subestima o nmero de pedaos
naqueles campos

A.4 Durao
Fig.19 mostra a durao utilizada ao calcular o
Throughput de um fluxo de armazenamento (t). Uma
vez que os handshakes TCP/SSL iniciais afetam a
percepo de throughput dos usurios, o primeiro
pacote SYN tomado como o incio da transferncia.
Os apertos de mo de terminao, por outro lado, so
ignorados. Nos fluxos da loja, o ltimo pacote com
carga til enviada pelo cliente considerado o fim
da transferncia. Nos fluxos de recuperao, o
ltimo pacote com carga til normalmente um alerta
de servidor sobre o trmino SSL. Ns compensamos
isso subtraindo 60 da durao da recuperao dos
fluxos sempre que a diferena entre o ltimo pacote
com a carga til do servidor e a do cliente est
acima dos 60. Devido nossa topologia de
monitoramento, t no inclui o tempo de viagem entre
clientes e nossas sondas. Por isso, t est
subestimado um pouco. A Fig.19 tambm mostra que so
necessrias 4 ou 5 RTT antes que o cliente comece a
enviar ou a receber dados. Em alguns casos, isso j
representa aproximadamente 500ms na durao do
fluxo. Observe que a janela de congestionamento TCP
inicial instalada nos servidores estava forando uma
pausa de 1 RTT durante o handshake SSL. Este
parmetro foi sintonizado aps o lanamento do
Dropbox 1.4.0, reduzindo a sobrecarga.