В этой статье я расскажу о внутреннем устройстве популярного сервиса облачного хранения Dropbox. В частности, будет затронуто устройство протокола Dropbox, а также показана статистика его использования в некоторых странах Европы. Кроме этого, я сравню его с другими сервисами, такими как iCloud, Google Drive и SkyDrive.
Статья сугубо техническая. Не будет никаких сводных таблиц со стоимостью за Гб и анализом того, сколько еще можно получить за приглашенных «друзей».
Текст основан на научной статье “Dropbox изнутри: Изучаем сервисы облачного хранения” (Inside Dropbox: Understanding Personal Cloud Storage Services). PDF
В последние несколько лет произошел огромный скачок популярности сервисов облачного хранения данных. В гонке вооружений участвуют все крупные игроки и несколько молодых стартапов. В основном, вся информация о внутреннем устройстве сервисов и реальных цифрах их использования — это тайна за семью печатями. Нас кормят только данными, прошедшими через отдел маркетинга, что, безусловно, несколько отличается от реальности. Поэтому давайте копнем поглубже вместе с ребятами Idilio Drago, Anna Sperotto, Marco Mellia, Ramin Sadre, Maurizio M. Munafò и Aiko Pras — авторами исследования.
Вступление
Dropbox клиент разработан в основном на языке Python с использованием сторонних библиотек, таких как librsync. Клиент поддерживает все основные ОС: Windows, Mac, Linux. Использование Python однозначно говорит о том, что клиент разрабатывался с учетом облегченного портирования на различные платформы.
Основной элемент системы — это блок (chunk) размером до 4 Mb. В случае, если файл большего размера, он разбивается на несколько блоков, и каждый блок воспринимается системой независимо от других. Для каждого блока вычисляется SHA256 хеш, и эта информация является частью метаинформации о файле. Dropbox уменьшает объем передаваемых данных за счет передачи только разницы между измененными блоками файла. Кроме того, локально он содержит всю метаинформацию по файлам, которую синхронизирует с сервером и передает только изменения с прошлой версии (incremental updates).
Dropbox использует два типа серверов: управляющий (control) и сервер данных (data storage). Сервера управления находятся под контролем Dropbox, сервера данных — это сервера Амазона (Amazon S3, EC2). Для коммуникациями с серверами во всех случаях используется HTTPS.
Доменные имена, используемые Dropbox, всегда заканчиваются на dropbox.com. В таблице ниже приведены поддомены для управляющих серверов и серверов данных.
| Поддомен | Описание | |
|---|---|---|
| client-lb/clientX | Dropbox | Meta data |
| notifyX | Dropbox | Notifications |
| api | Dropbox | API control |
| www | Dropbox | Web servers |
| d | Dropbox | Event logs |
| dl | Amazon | Direct links |
| dl-clientX | Amazon | Client storage |
| dl-debugX | Amazon | Back traces |
| dl-web | Amazon | Web storage |
| api-content | Amazon | API storage |
Dropbox: изнутри
Поскольку Dropbox использует HTTPS для шифрования всего трафика между серверами, простой перехват не даст никакой полезной информации. Для исследования мы устанавливали Squid и направляли весь трафик с компьютера под Linux на этот прокси. Также на прокси поставили SSL-bump, чтобы можно было расшифровывать SSL. Последним шагом устанавливаем самоподписанный сертификат на Squid и изменяем сертификат внутри запущенного Dropbox приложения. Данная конфигурация позволяет расшифровать и просмотреть трафик Dropbox.
Иллюстрация показывает протокол, используемый Dropbox для загрузки локально измененных блоков на свои сервера. После регистрации клиента на управляющих серверах clientX.dropbox.com, команда list получает изменения в метаданных, которые показывают разницу между локальной копией и тем, что находится на сервере. Как только происходит локальное изменение файлов, Dropbox вызывает команду commit_batch (client-lb.dropbox.com) и посылает измененные метаданные на сервер. После этого сервер отвечает, какие блоки ему необходимы, используя команду need_blocks, и клиент отсылает эти блоки на Amazon (dl-clientX.dropbox.com). Сохранение каждого блока подтверждается командой ОК.
После этого локальный клиент еще раз раз посылает команду commit_batch на сервер и получает подтверждение, что все блоки получены. Транзакции сохранения данных могут выполняться параллельно.
Протокол управления
Dropbox использует следующие группы управляющих серверов:
- Уведомления (notifications).
Dropbox держит постоянное открытое TCP соеденинение с серверами уведомлений (notifyX.dropbox.com). Это необходимо для получения информации об изменении файлов, которое могло произойти на других клиентах. По сравнению с другим трафиком, эта информация не шифруется. Используется задержка HTTP ответа для быстрого уведомления клиентов (push mechanism). Клиент посылает запрос, и сервер задерживает ответ примерно на 60 секунд. По истечении 60 секунд, клиент немедленно посылает следующий запрос на сервер. Если ответ сформирован раньше, то сервер отвечает немедленно. - Управление метаданными (meta-data administration)
Сервера управления метаданными отвечают не только за информирование об изменениях в блоках и файлах, но также и за авторизацию (authentication) клиента. Для этих серверов используются следующие доменные имена: client-lb.dropbox.com, clientX.dropbox.com. Кроме этого, сервера управления могут контролировать поведение клиента. В момент эксперимента было замечено, что сервера могут указать клиенту максимальное количество блоков, которое он может посылать на сервер. Это используется для управления трафиком, который генерирует клиент. - Системные сообщения (system logs)
сервера предоставляются Амазоном и имеют название dl-debug.dropbox.com; остальные сообщения идут непосредственно на Dropbox d.dropbox.com.
Набор данных и популярность клиентов
Мы избрали пассивный способ наблюдения за Dropbox. Для сбора трафика использовался open source инструмент Tstat. Tstat позволяет собирать разнообразную информацию о ТСР, предоставляя сведения более, чем о сотне разнообразных параметров соединения. Для анализа Dropbox мы предприняли несколько дополнительных шагов.
Поскольку Dropbox использует HTTPS, мы установили, что имя во всех сертификатах, используемых Dropbox — *.dropbox.com. Это было важно для правильной классификации трафика.
Мы пополнили открытую информацию записями с серверов DNS, к которым обращались клиенты. Таким образом мы связали IP адреса и имена серверов.
Tstat возвращал незашифрованную информацию об устройстве и именах директорий, которыми обменивался клиент и сервер уведомлений.
Данные были получены с помощью установки Tstat в 4 точках в Европе. Записи с точек, обозначенных как Home 1 и Home 2, составляют данные пользователей известного интернет-провайдера (ISP), предоставляющего интернет по ADSL и оптическому кабелю. Данные, обозначенные как Campus 1 и Campus 2, были собраны в университетах. Исследования проводились с 24 Марта 2012 по 5 Мая 2012.
| Имя | Тип | Количество IP адресов | Обьем данных (GB) |
|---|---|---|---|
| Campus 1 | Wired | 400 | 5,320 |
| Campus 2 | Wired/Wireless | 2,528 | 55,054 |
| Home 1 | FTTH/ADSL | 18,785 | 509,909 |
| Home 2 | ADSL | 13,723 | 301,448 |
Ниже приведен график, который показывает, сколько различных IP адресов связывалось с облачным сервисом хранения хотя бы раз в день.
Второй график показывает, сколько данных было передано на это облачное хранилище в день.
Хотелось бы обратить внимание на следующее:
- Несмотря на большое количество устройств, использующих iCloud, количество данных, передаваемое на этот сервис, соизмеримо с другими сервисами.
- В момент появления Google Drive, трафик, передаваемый на этот сервис, сделал большой скачок и приблизился к iCloud; в то же время количество инсталляций программы оставалось минимальным.
Для сравнения приведем данные использования сервисов YouTube и Dropbox в Campus 2.
Таблица показывает суммарный трафик Dropbox, который мы отследили в ходе наших измерений.
| Campus 1 | Campus 2 | Home 1 | Home 2 | Всего | |
|---|---|---|---|---|---|
| Запросов | 167,189 | 1,902,824 | 1,438,369 | 693,086 | 4,204,666 |
| Обьем (GB) | 146 | 1,814 | 1,153 | 506 | 3,624 |
| Устройств | 283 | 6,609 | 3,350 | 1,313 | 11,561 |
Анализ трафика
Графики показывают куммулятивную функцию распределения для различного количества блоков.
Оказалось, что более, чем в 80% процентах случаев, количество блоков при сохранении данных не превышает 10. График для данных с точки Home 2 существенно отличается от остальных, так как здесь мы наблюдали одного клиента, который постоянно, на протяжении нескольких дней, пересылал одни и те же блоки. Анализ полученных данных показывает, что основной сценарий использования Dropbox — это постоянная работа с небольшими, постоянно изменяемыми файлами.
Как мы рассмотрели выше, Dropbox использует центральные сервера для хранения данных. Это сразу наводит на вопрос о скорости работы сервиса для пользователей, которые находятся географически далеко от серверов.
Максимальная скорость, которую мы наблюдали, была близка к 10 Mbit/s и наблюдалась на файлах с размером больше 1 Mb. Средняя скорость для Campus 2 была: запись — 462 kbits/s и чтение — 797 kbits/s. Для Campus 1: запись — 359 kbits/s и чтение — 783 kbits/s.
Также из графиков видно, что скорость существенно зависит от количества блоков: чем больше блоков, тем ниже скорость.
Изменения в Dropbox 1.4.0
Начиная с версии 1.4.0, Dropbox добавил две новые команды: store_batch и retrieve_batch, что позволяет работать с несколькими блоками одновременно. Это улучшение должно существенно улучшить пропускную способность сервиса.
Количество устройств
График показывает количество установок Dropbox у пользователей дома. Примерно в 60% случаев у пользователей существует только 1 устройство с Dropbox. У 25% пользователей дома есть 2 устройства, использующих Dropbox.
Среднее время использования
График показывает среднее время использования Dropbox. Анализируя время использования, мы смотрели, сколько времени клиент поддерживал связь с сервером уведомлений. Поскольку клиент всегда держит это соединение открытым либо открывает его заново, это хороший способ оценить время использования.
Из графика видно, что время использования Dropbox в большинстве случаев меньше 4 часов. Исключение составляет Campus 1, где много рабочих компьютеров и компьютеров, работающих постоянно.
Исходные данные
Вы можете загрузить исходные данные, которые использовались в этой статье для дальнейшего анализа. (Исходные данные).
Хочу обратить внимание, что оригинальная статья содержит больше информации. В ней могут быть ответы на вопросы, которые могут возникнуть у вас после прочтения.
Автор: mrtorrent
