Техники параллельной загрузки: максимизация пропускной способности
Узнайте, как параллельные загрузки ускоряют передачу файлов. Поймите чанковые загрузки и многопоточные трансферы.
Параллельные загрузки разбивают файл на чанки (обычно по 5–100 МБ каждый) и проталкивают их через несколько одновременных TCP-соединений, обходя потолок пропускной способности, в который один поток упирается на линиях с большой задержкой. Amazon S3 multipart upload, Google Cloud Storage resumable uploads и tus.io — все реализуют этот подход. На линии 1 Гбит/с с задержкой 80 мс до сервера-назначения один HTTP PUT обычно насыщается на 150 Мбит/с, а 8 параллельных потоков выходят за 900 Мбит/с. Прирост реален и предсказуем, как только понимаешь, почему он появляется.
Почему одного потока недостаточно
Контроль перегрузки TCP использует скользящее окно, чтобы решать, сколько неподтверждённых данных держать в полёте. На широкой трубе с большой задержкой дефолтный размер окна (около 16 МБ на Linux 5.x, меньше на старых ядрах) заполняется до возврата ACK, и отправитель простаивает. Это проблема «bandwidth-delay product», и именно поэтому один FTP-трансфер на сервер в Сингапуре из Парижа упирается примерно в 30 Мбит/с даже на гигабитной линии.
Запуск нескольких параллельных соединений обходит проблему, потому что каждое получает собственное окно. Восемь потоков по 30 Мбит/с складываются в 240 Мбит/с, и это до учёта выбора edge-точек CDN, которые часто маршрутизируют разные соединения через разные точки входа.
Чанкинг: какой размер, сколько штук
Золотая середина зависит от задержки и потерь пакетов. Для передач в пределах континента с RTT меньше 50 мс — чанки 10 МБ с 4 параллельными воркерами насыщают большинство потребительских линий. Для трансконтинентальных или нестабильных мобильных соединений (RTT больше 100 мс, потери больше 0,5%) — снижайтесь до чанков 5 МБ с 8–16 воркерами.
API multipart S3 требует минимум 5 МБ на часть (кроме последней), максимум 5 ГБ на часть и до 10 000 частей на загрузку. Это даёт теоретический потолок около 48,8 ТБ на объект. Google Cloud Storage позволяет 32 части на composite и поддерживает resumable session URI, живущие до одной недели. Block blobs в Azure Blob принимают до 50 000 блоков по 4000 МиБ.
Для браузерных передач чанки больше 100 МБ начинают давить на RAM в уже загруженных вкладках, поэтому большинство веб-UI остаются в диапазоне 5–20 МБ.
Как современные сервисы передачи реально это делают
Веб-загрузчик WeTransfer разбивает файлы на чанки по 6 МБ и запускает 3–5 параллельных XHR-запросов. Smash шардирует агрессивнее — чанки по 4 МБ через до 8 воркеров. SwissTransfer использует чанки 50 МБ с 4 параллельными потоками, что благоприятствует пропускной способности на швейцарских оптоволоконных линиях, но хуже работает на нестабильных соединениях, потому что один упавший чанк означает повторную отправку 50 МБ. Dropbox Transfer опирается на свой чанковый API загрузки с чанками 8 МБ.
Различия проявляются в реальных тестах: файл на 5 ГБ при загрузке 500 Мбит/с в WeTransfer заканчивается примерно за 95 секунд; SwissTransfer при сходной пропускной способности — около 105 секунд из-за периодических накладных расходов на повторы чанков.
Возобновляемые загрузки: тихая суперсила
Чанковые загрузки открывают возможность возобновления. Если Wi-Fi падает на 47-м чанке из 120, не нужно начинать с нуля — продолжаете с 48-го. Протокол tus.io (открытый стандарт, сейчас на версии 2.0) формализует это HEAD-запросами для опроса смещения загрузки и PATCH-запросами для добавления, используя заголовки Upload-Offset и Upload-Length.
Resumable upload API в Google Drive использует session URI, живущие 7 дней. Можно уронить ноутбук, перезагрузиться, открыть вкладку и продолжить ровно с того места, где остановились. Это разница между пригодной к делу передачей на 10 ГБ и игрой в монетку.
Клиентское шифрование меняет арифметику
Сервисам передачи со сквозным шифрованием приходится шифровать каждый чанк на клиенте перед отправкой. AES-256-GCM на 500 МБ/с на современном ноутбучном CPU — не узкое место, но порядок имеет значение: зашифровать чанк, отправить чанк, зашифровать следующий. Конвейер с пулом воркеров здесь критичен. Наивные реализации сериализуют шифрование и загрузку, срезая эффективную пропускную способность вдвое. Грамотные реализации держат 2–4 воркера шифрования, кормящих 4–8 воркеров отправки через ограниченную очередь.
Поэтому HexaTransfer запускает шифрование AES-256-GCM в Web Workers рядом с пулом параллельных XHR — потолок в 10 ГБ реально достижим в браузере без затыков на криптографии.
Backpressure и серверные лимиты
Больший параллелизм не всегда быстрее. Если принимающий сервис ограничивает запросы на IP (типично для CloudFront — 25 000 запросов в секунду на distribution), пропихнуть 32 одновременных чанка может вызвать ответы 503 Slow Down. HTTP/2 помогает, потому что мультиплексирует поверх одного TCP-соединения, но многие CDN всё ещё терминируют HTTP/2 на edge и фанаутят HTTP/1.1 к origin, так что эффективный параллелизм зависит от конфигурации edge.
Тестируйте перед чрезмерным распараллеливанием. 8 воркеров почти всегда безопасно; 16 — верхний край того, что облачные объектные хранилища принимают чисто; 32 уже начинают давать повторы, которые стоят дороже выигрыша.
Браузерные лимиты, о которых стоит знать
Chrome и Firefox ограничивают одновременные соединения на origin цифрой 6 для HTTP/1.1 и фактически безлимитом для HTTP/2. Если сервис передачи всё ещё на HTTP/1.1 (редко, но некоторые устаревшие шлюзы FTP-через-HTTP), ваш потолок параллелизма — 6 независимо от количества запущенных воркеров. Проверьте через DevTools: колонка «Waterfall» в панели Network покажет очередь запросов.
Safari на iOS 17 и новее чисто обрабатывает 6 параллельных XHR, но начинает выгружать фоновые вкладки при давлении RAM около 1,5 ГБ, что важно для буферов чанковой загрузки.
Когда параллельные загрузки не помогают
На асимметричных жилых соединениях (типично: 1 Гбит/с вниз, 40 Мбит/с вверх) узкое место — ваш upload, а не приём сервера. Прокачка 8 параллельных потоков по 5 МБ через 40-мегабитную трубу не идёт быстрее одного потока на 40 Мбит/с. Параллелизм помогает, когда потолок одного потока ниже ёмкости трубы, а не когда вы и так насыщаете канал.
Та же история на сотовой связи: при одной палке LTE лишние воркеры в основном производят повторные передачи.
Что искать в сервисе
При выборе инструмента передачи для частых крупных файлов проверьте три вещи: поддерживает ли он возобновляемые чанковые загрузки, сколько параллельных воркеров запускает веб-UI и использует ли HTTP/2 или HTTP/3 до edge. Сервисы, у которых всё это сходится, переместят файл на 10 ГБ за минуты на приличном соединении.
Попробуйте на hexatransfer.com — бесплатно, без регистрации, до 10 ГБ.
Безопасная отправка больших файлов со сквозным шифрованием
Передавайте файлы до 10 ГБ бесплатно со сквозным шифрованием. Регистрация не требуется. Ваши файлы шифруются в браузере перед загрузкой — никто другой не может их прочитать.
Отправить файл