Облачное хранилище: 5 факторов, влияющих на скорость
Загрузка 50 ГБ данных через типичный домашний канал «до 100 Мбит/с» занимает порядка 11 часов. Причина не в облачном провайдере и не в его серверах — причина в исходящей скорости канала, которая у большинства тарифов составляет 10–20 Мбит/с.
Скорость облачного хранилища ограничивает самое медленное звено в цепочке «клиент — канал — протокол — сервер». Оптимизировать нужно все четыре.
Пропускная способность канала как первичный ограничитель
Upload speed — главный параметр, определяющий время загрузки. Заявленная провайдером скорость «до X Мбит/с» описывает downstream. Upstream у большинства массовых тарифов в 5–10 раз ниже.
Типичные значения для разных классов подключения:
- Оптоволокно (FTTB/FTTH, симметричный канал): upload 100–1000 Мбит/с.
- Кабельный DOCSIS 3.1: download до 1000 Мбит/с, upload 50–100 Мбит/с.
- DSL/VDSL: download до 100 Мбит/с, upload 5–20 Мбит/с.
- Мобильный LTE/5G: upload 10–50 Мбит/с, с деградацией при нагрузке на базовую станцию.
- Корпоративный канал с SLA: фиксированный upload, обычно 1:1 к download.
Расчёт линейный: файл 10 ГБ при upload 20 Мбит/с загружается ≈ 67 минут. При upload 100 Мбит/с — ≈ 13 минут. Разница двенадцатикратная. Никакая оптимизация на стороне облачного провайдера эту дельту не компенсирует.
Симметричный канал — единственный способ радикально ускорить upload. Если бизнес-процесс требует регулярной загрузки больших объёмов данных, аудит тарифа интернет-провайдера даёт больший эффект, чем смена облачного сервиса.
Латентность и географическое расстояние
RTT (Round Trip Time) измеряется в миллисекундах. Параметр не влияет на пропускную способность, но определяет время отклика при работе с мелкими файлами и API-запросами. Облачное хранилище с высокой латентностью проигрывает локальному диску на любых операциях, где размер запроса мал относительно задержки канала.
Ориентиры RTT для популярных маршрутов:
- Москва — Москва: 1–5 мс.
- Москва — Санкт-Петербург: 10–20 мс.
- Москва — Франкфурт: 30–40 мс.
- Москва — Северная Америка: 100–150 мс.
- Москва — Юго-Восточная Азия: 150–250 мс.
При работе с файлами размером до 1 МБ латентность доминирует над bandwidth. Синхронизация тысяч мелких документов через удалённый дата-центр с RTT 200 мс занимает часы, даже если канал позволяет гигабит. Решение — реплики и CDN, либо географический выбор региона при создании бакета.
Пропускная способность определяет скорость загрузки крупных файлов. Латентность — скорость работы с API и мелкими объектами. Это разные метрики, и оптимизируются они раздельно.
Протоколы передачи данных
От протокола зависит, насколько эффективно приложение использует доступный канал. TCP остаётся базовым протоколом, но для облачных загрузок его поведение при потерях пакетов становится проблемой.
Сравнение протоколов по ключевым параметрам:
| Параметр | TCP (HTTP/1.1, HTTP/2) | QUIC (HTTP/3) | UDP-кастом |
|---|---|---|---|
| Поведение при packet loss > 1% | Резкое падение throughput | Стабильная работа | Зависит от реализации |
| Head-of-line blocking | Есть (особенно HTTP/1.1) | Нет | Нет |
| Шифрование | Внешний слой (TLS) | Встроенное | Внешний слой |
| Поддержка облачными провайдерами | Универсальная | Широкая, но не тотальная | Ограниченная |
| Эффективность на «длинных» каналах | Средняя | Высокая | Высокая |
Механизм TCP congestion control снижает скорость передачи при каждом потерянном пакете. На каналах с packet loss 1–3% реальная скорость падает в 3–5 раз относительно номинала. QUIC и производные протоколы обходят это ограничение за счёт изоляции потоков и встроенного шифрования.
При выборе облачного клиента критично проверить, какой протокол используется. Десктопные агенты крупных провайдеров уже мигрировали на QUIC/HTTP/3. Браузерная загрузка идёт по тому, что поддерживает серверная сторона.
Локальное оборудование и шифрование на стороне клиента
Скорость локального накопителя и CPU нагрузка от шифрования — ограничения, которые пользователь обычно не учитывает. Облачный клиент сначала читает файл, шифрует его, отправляет по сети. Скорость цепочки равна скорости самого медленного звена.
Сравнение накопителей:
| Тип | Линейная запись | Линейное чтение | IOPS (4K) |
|---|---|---|---|
| HDD 7200 RPM | 100–200 МБ/с | 100–200 МБ/с | 100–200 |
| SATA SSD | 400–550 МБ/с | 500–550 МБ/с | 50 000–90 000 |
| NVMe Gen3 | 1500–3000 МБ/с | 2000–3500 МБ/с | 200 000–500 000 |
| NVMe Gen4 | 5000–7000 МБ/с | 5000–7500 МБ/с | 500 000–1 000 000 |
При шифровании «на лету» AES-256 на CPU без аппаратной поддержки AES-NI потребляет 2–4 ядра. Современные клиенты Dropbox, Google Drive, OneDrive поддерживают аппаратное ускорение, но на устаревших машинах этап шифрования становится узким местом.
Отдельный фактор — операционная система и файловая система. Windows с антивирусом, сканирующим каждый файл перед отправкой, замедляет загрузку в 2–3 раза. macOS и Linux в этом сценарии выигрывают за счёт меньшего числа перехватов на уровне ядра.
Серверная обработка: сжатие, дедупликация, шифрование
Провайдер применяет обработку к данным перед записью на физический носитель. Прозрачно для пользователя, но с измеримым эффектом.
Составляющие серверного цикла:
- Сжатие: gzip, zstd или специализированные алгоритмы. Снижает объём для текстовых и офисных форматов в 2–4 раза. Не работает на уже сжатых данных (видео, архивы).
- Дедупликация: на уровне блоков или целых файлов. Ускоряет повторные загрузки идентичных данных. Провайдеры хранят хеши блоков и применяют их для оптимизации.
- Шифрование at-rest: AES-256. На современном серверном железе накладные расходы минимальны.
- Запись на носитель: HDD-массивы в архивных хранилищах дешевле, но медленнее. Tier-1 хранение идёт на SSD или NVMe.
Параметр, на который пользователь не влияет напрямую, но может учитывать при выборе тарифа. «Холодные» классы хранения (AWS S3 Glacier, Yandex Cold Storage) дешевле в 5–10 раз, но скорость первого чтения измеряется минутами или часами. Для активной работы с данными такой класс не подходит.
Серверная обработка снижает эффективный объём передачи, но не скорость канала. Если upload 20 Мбит/с — никакое сжатие на стороне провайдера не превратит его в 200.
Диагностический чек-лист
Чек-лист проверки при жалобе «облако работает медленно»:
- Измерить фактический upload через speedtest (не download).
- Проверить RTT до региона бакета командой
pingилиmtr. - Сравнить скорость загрузки через десктоп-клиент и через браузер — разница указывает на проблему протокола или клиента.
- Проверить нагрузку CPU при загрузке — если процесс клиента потребляет 100% ядра, bottleneck в шифровании.
- Проверить тип накопителя: HDD в качестве источника ограничит скорость на уровне 100–200 МБ/с даже при идеальном канале.
- Исключить антивирус и файрвол на стороне клиента — отключить временно и замерить.
- Проверить packet loss на маршруте — при потерях > 1% TCP деградирует, QUIC работает стабильнее.
- Сопоставить класс хранилища с задачей — архивное хранилище не предназначено для активной работы.
Скорость облачного хранилища — производная от слабейшего звена. В 80% случаев это канал upload или локальный накопитель. Оптимизация начинается с замера каждого этапа цепочки, а не со смены провайдера.