Оптимизация пакетной загрузки: передавайте папки быстрее

Наибольшую скорость при пакетной загрузке даёт объединение папки в один .zip (режим store, без сжатия) с последующей загрузкой одного большого объекта вместо тысяч маленьких. Папка из 5 000 .jpg-файлов по 500 КБ каждый суммарно составляет 2,5 ГБ, но загружается поштучно в 10–20 раз дольше, чем единый архив 2,5 ГБ, поскольку каждый небольшой файл несёт полные накладные расходы TLS и HTTP. Сервисы с поддержкой параллельной загрузки (HexaTransfer, Dropbox, rclone) помогают, когда многие чанки крупные. Сервисы без параллелизма всё равно выигрывают по пропускной способности, как только вы объединяете маленькие файлы в один архив. Добавьте дедупликацию случайно продублированных файлов, пропустите мусор .DS_Store и Thumbs.db — и завершите передачу за долю наивного времени.

Почему тысячи маленьких файлов работают медленно

Каждая загрузка файла по HTTPS несёт фиксированные накладные расходы: TLS-рукопожатие (повторно используется при keep-alive), HTTP-заголовки (~500 байт), подтверждение сервера и сброс на диск на принимающей стороне. Для файла в 50 КБ эти накладные расходы могут превышать сам файл. Для файла в 500 КБ накладные расходы составляют 10–20% от общего объёма на канале.

Умножьте на 5 000 файлов — и вы потратили половину времени на метаданные вместо полезной нагрузки. Именно поэтому копирование большой папки с множеством маленьких файлов на внешний накопитель всегда медленнее, чем копирование одного архива аналогичного размера.

Сначала архивируй, потом загружай

Единственное наибольшее ускорение при загрузке папок: сначала упаковать в один .zip, .7z или .tar. Для уже сжатого содержимого (фотографии, видео, офисные документы) используйте режим store (без сжатия) — получите выгоду от объединения без затрат CPU. Для текстовых папок (логи, исходный код) используйте стандартное сжатие для реальной экономии объёма.

Команды:

macOS/Linux: zip -0 -r archive.zip folder/ для без сжатия; zip -r archive.zip folder/ для стандартного сжатия.
Windows: правая кнопка мыши на папку → Отправить → Сжатая (zip) папка. Или 7-Zip: Добавить в архив → Уровень сжатия → Без сжатия.
Большие папки: tar -cf archive.tar folder/ (без сжатия) или tar -czf archive.tar.gz folder/ (gzip).

Дедупликация перед архивированием

Папки накапливают дублированные файлы со временем. Дизайн-проекты содержат «final_v2.psd», «final_v2_COPY.psd», «final_v2_BACKUP.psd» — одинаковое содержимое, разные имена. Папка в 20 ГБ после дедупликации запросто превращается в 12 ГБ.

Инструменты: fdupes (Linux), rmlint (Linux/macOS), Duplicate File Finder (macOS), dupeGuru (кросс-платформенный). Большинство работает путём хэширования файлов и выявления одинаковых хэшей. Просмотрите результаты, удалите дубликаты, затем архивируйте.

Для фотографов каталог Lightroom уже отслеживает уникальные фотографии; экспортируйте только выбранные помеченные снимки, а не весь каталог съёмки.

Пропускайте системный мусор

Каждая папка macOS накапливает скрытые файлы .DS_Store (метаданные). Каждая папка Windows содержит Thumbs.db. На Linux файлы .directory появляются от KDE. Они ничего не добавляют получателю и раздувают счётчик файлов в архиве.

При создании zip на macOS:

zip -r archive.zip folder/ -x "*.DS_Store" "__MACOSX"

В Windows через 7-Zip исключайте паттерны через UI или командную строку: -xr!Thumbs.db -xr!desktop.ini. Для rsync-передач используйте --exclude='.DS_Store' --exclude='Thumbs.db'.

Параллельные чанкированные загрузки

Когда сервис поддерживает это, параллельные HTTP-потоки насыщают полосу пропускания, которую одно TCP-соединение не может заполнить на путях с высокой задержкой. Протокол tus.io поддерживает это через параллельную загрузку чанков. Клиентские библиотеки, например tus-js-client, по умолчанию используют один параллельный запрос, но можно настроить больше.

При межконтинентальных загрузках (например, пользователь в США к европейскому сервису) параллелизм удваивает или утраивает эффективную пропускную способность. При местных загрузках один поток обычно насыщает полосу и параллелизм ничего не даёт.

Настройка размера чанков

Большие чанки снижают накладные расходы на запрос; маленькие чанки быстрее восстанавливаются при сбоях сети. Компромисс зависит от вашего подключения:

| Тип подключения | Рекомендуемый размер чанка | |---|---| | Гигабитная оптика, проводное | 32–64 МБ | | Жилая оптика, Wi-Fi | 10–20 МБ | | Офисный широкополосный | 10 МБ | | Мобильная сеть 4G/5G | 2–5 МБ | | Нестабильный/гостиничный Wi-Fi | 1–2 МБ |

Большинство потребительских сервисов выбирают разумное значение по умолчанию (5–10 МБ) и не открывают эту настройку. Инструменты командной строки (rclone, aws s3 cp, gsutil) позволяют точную настройку.

Структура папок важна меньше, чем общий объём

Распространённое заблуждение: «глубоко вложенные папки замедляют загрузку». Нет. Формат архива сводит пути к строковым заголовкам независимо от глубины. Папка из 10 000 файлов на 3 уровнях вложенности загружается идентично папке из 10 000 файлов на 10 уровнях после архивирования.

Что действительно важно: количество отдельных файлов. 10 000 маленьких файлов в одном уровне — та же проблема, что 10 000 маленьких файлов в вложенных папках. Архивируйте их.

Стратегия сжатия по типу содержимого

Смешанные фото (.jpg/.heic): .zip в режиме store. Без траты CPU.
RAW-фото (.cr3/.arw/.nef): .zip в режиме store. Уже сжаты внутри.
Видеопроекты (.mp4, .mov, .prproj): .zip в режиме store.
Исходный код: 7z с LZMA2 для максимальной степени.
Файлы логов: 7z с LZMA2; ожидайте сжатие в 10–20 раз.
PDF: режим store. Большинство PDF содержит внутреннее сжатие.
Смешанные офисные документы (.docx, .xlsx): режим store. Они уже ZIP-сжатый XML внутри.
Дампы баз данных (.sql): 7z с LZMA2. Отличное сжатие.

Фоновая или приоритетная загрузка

Браузерные загрузки требуют, чтобы вкладка оставалась открытой. Закрытие вкладки, как правило, прерывает загрузку. Некоторые сервисы предлагают фоновую загрузку через Service Worker, которая продолжается ненадолго после закрытия вкладки, но это ненадёжно на мобильных браузерах и в некоторых корпоративных конфигурациях.

Для действительно крупных пакетных загрузок (100+ ГБ) настольные клиенты выигрывают, поскольку работают как процессы уровня ОС. rclone монтирует и синхронизирует с любым крупным облачным хранилищем. Клиент Dropbox для рабочего стола надёжно ставит загрузки в очередь. Они переживают закрытие крышки ноутбука и смены Wi-Fi способами, с которыми браузеры плохо справляются.

Для пакетных загрузок до 10 ГБ современный браузерный сервис с чанкированными загрузками через tus.io справляется с нагрузкой. Клиентское шифрование HexaTransfer добавляет скромную нагрузку на CPU, но не ощутимо влияет на пропускную способность на современном оборудовании.

Разбивка слишком больших пакетов

Когда ваш пакет превышает потолок сервиса на передачу, разбивайте логически, а не механически. Папки «Фото по датам» для месячной съёмки работают лучше, чем произвольное деление по байтам, потому что получатель может проверить полноту каждого пакета («1–7 марта.zip», «8–14 марта.zip»), а не гадать, отсутствует ли часть .005.

Для сервисов без ограничения на передачу, но с ограничением по сессии, последовательная загрузка нескольких архивов позволяет избежать превышения лимитов параллельных загрузок.

Проверьте, прежде чем уйти

Крупные пакетные загрузки соблазнительно запустить и забыть. Не делайте этого. Прежде чем закрывать ноутбук:

Убедитесь, что страница загрузки показывает «Завершено», а не «В процессе»
Откройте ссылку в другом браузере или режиме инкогнито и проверьте опыт получателя
Убедитесь, что архив корректно открывается (повреждённый .zip при загрузке редко, но возможен)
Подтвердите, что настройки истечения соответствуют вашим намерениям

Пять минут проверки лучше неловкого письма завтра с вопросом, получил ли адресат файлы.

Дельта-синхронизация для повторяющихся пакетов

Если вы обновляете пакет — например, еженедельные резервные копии папки проекта — полная повторная загрузка расточительна. Инструменты вроде rclone, rsync через SSH или выделенные sync-клиенты передают только изменённые файлы. Это требует постоянного хранилища (не временного передаточного сервиса), поэтому является паттерном облачного хранилища, а не передачи.

Для истинных передаточных рабочих процессов, где получатель каждый раз разный, полная архивация пакета — правильный подход.

Итог

Быстрый путь для загрузки папок: архивируйте всё в один .zip (режим store для уже сжатого содержимого, реальное сжатие для текста), пропускайте системные мусорные файлы, дедуплицируйте там, где это оправдано, и загружайте единый архив через сервис с поддержкой чанкированных возобновляемых загрузок. Для очень крупных пакетов используйте настольный клиент. Разница между наивным «загрузить папку напрямую» и оптимизированным подходом нередко составляет 10-кратное ускорение.

Попробуйте на hexatransfer.com — бесплатно, без регистрации, до 10 ГБ.