Перейти к содержанию
HexaTransfer
Вернуться к блогу
Передача файлов

Возобновление прерванных передач: никогда с нуля

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

Возобновляемые передачи делят файл на чанки и отслеживают, какие из них успешно получены; при разрыве соединения клиент продолжает со следующего неотправленного чанка вместо перезапуска с нулевого байта. Веб-стандартом для этого является tus.io (открытый протокол возобновляемых загрузок), реализованный в SwissTransfer, HexaTransfer, Vimeo, Cloudinary и многих современных сервисах передачи. Для скачивания HTTP Range-запросы (RFC 7233) позволяют браузерам и инструментам вроде curl или aria2 возобновлять прерванные загрузки. Без возобновляемости загрузка 9,8 ГБ, прерванная на 9,5 ГБ, обходится вам полным сбросом — с возобновляемостью вы теряете не более 50 МБ.

Проблема невозобновляемых загрузок

Наивная загрузка файла отправляет его целиком одним HTTP POST-запросом. Если что-то прерывает соединение — падение Wi-Fi, тайм-аут VPN, переход ноутбука в сон, сбой у провайдера — TCP-соединение закрывается, и сервер отбрасывает все частично полученные данные. Клиент начинает заново с нулевого байта.

Для загрузки 5 ГБ при скорости 50 Мбит/с это 13 минут выброшенной работы. Для 50 ГБ — более двух часов. Доля сбоев невозобновляемых загрузок на мобильных соединениях разрушительна: 30-минутная загрузка по 4G редко успешно завершается с первого раза.

Как работают возобновляемые протоколы

Современные возобновляемые загрузки работают примерно следующим образом:

  1. Создание: клиент отправляет POST на сервер с общим размером файла и метаданными. Сервер возвращает уникальный URL для этой конкретной загрузки и резервирует хранилище.
  2. Чанкирование: клиент нарезает файл на чанки (обычно по 5–64 МБ).
  3. Загрузка: клиент отправляет каждый чанк как PATCH-запрос с заголовком Content-Range или Upload-Offset, указывающим позицию чанка.
  4. Подтверждение: сервер записывает чанк в хранилище и подтверждает новое смещение.
  5. Возобновление: при разрыве соединения клиент отправляет HEAD-запрос на URL загрузки. Сервер отвечает текущим смещением (сколько байт он получил). Клиент продолжает с этого смещения.
  6. Завершение: когда последний чанк подтверждён, загрузка завершена.

Эта модель описана спецификацией tus.io (версия 1.0.0 широко развёрнута). Другие варианты включают S3 Multipart Upload (для прямых загрузок в S3) и Google Cloud Storage Resumable Uploads.

Tus.io: открытый стандарт

Tus («transloadit upload server») — бесплатный открытый протокол, поддерживаемый Transloadit. Спецификация размещена на tus.io и реализована в:

  • Клиентских библиотеках: tus-js-client (браузер + Node.js), TUSKit (iOS), tus-android-client, tus-java-client
  • Серверных реализациях: tusd (референсный сервер на Go), tus-node-server и многие интеграции с фреймворками
  • Коммерческих сервисах: SwissTransfer, HexaTransfer, Vimeo, Cloudinary, Transloadit, companion-серверы Uppy

Протокол намеренно минималистичен: четыре HTTP-метода (POST, HEAD, PATCH, OPTIONS), несколько заголовков (Upload-Offset, Upload-Length, Tus-Resumable). Это сохраняет реализации простыми и совместимыми.

Решения по размеру чанков

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

| Размер чанка | Стоимость восстановления при сбое | Накладные расходы | |---|---|---| | 1 МБ | Потеря ≤ 1 МБ | Высокие (много запросов) | | 5 МБ | Потеря ≤ 5 МБ | Умеренные | | 16 МБ | Потеря ≤ 16 МБ | Низкие | | 64 МБ | Потеря ≤ 64 МБ | Минимальные | | 256 МБ | Потеря ≤ 256 МБ | Пренебрежимые, но болезненно при сбое |

Для стабильных соединений чанки 32–64 МБ максимизируют пропускную способность. Для мобильного или нестабильного Wi-Fi чанки 2–5 МБ быстрее восстанавливаются при каждом сбое. Сервисы обычно выбирают значение по умолчанию 5–10 МБ как компромисс.

Что реально прерывает передачи

Понимание режимов сбоев помогает оценить, насколько реализация возобновления у сервиса надёжна:

  • Падение Wi-Fi: смена сети, потеря сигнала, перезагрузка маршрутизатора. Очень распространено.
  • Переход ноутбука в сон: закрытие крышки на macOS/Windows. ОС приостанавливает сеть; после пробуждения соединения нередко нужно переустанавливать.
  • Приостановка вкладки: современные браузеры приостанавливают фоновые вкладки для экономии памяти. Загрузки в приостановленной вкладке могут зависнуть.
  • Проблемы у провайдера/магистрали: кратковременные изменения маршрутизации, необходимость повторного TLS-рукопожатия.
  • Переподключение VPN: клиенты VPN периодически переговариваются; TCP-соединение обрывается.
  • Перезапуски на стороне сервера: сервис передачи выпускает новую версию; текущие запросы завершаются ошибкой.
  • Изменения политик cross-origin: корпоративные файрволы, инспектирующие трафик, иногда прерывают долгосрочные соединения.

Надёжная возобновляемая реализация обрабатывает всё это одним механизмом: переподключиться, выполнить HEAD для проверки смещения, продолжить оттуда.

Возобновление при скачивании

HTTP Range-запросы (RFC 7233) обеспечивают возобновляемое скачивание. Сервер, рекламирующий Accept-Ranges: bytes в заголовках ответа, поддерживает range-запросы. Клиенты могут затем передавать Range: bytes=1000000- для получения только байт начиная со смещения 1 000 000.

Браузеры используют это автоматически при нажатии «Возобновить» в менеджере загрузок. Chrome, Firefox и Safari поддерживают возобновление загрузок с совместимых серверов. Большинство CDN (Cloudflare, Fastly, CloudFront) поддерживают range-запросы.

Инструменты командной строки открывают больше возможностей:

  • curl -C - -O url возобновляет скачивание с места остановки.
  • wget -c url делает то же самое.
  • aria2c -c -s 16 url скачивает с 16 параллельными потоками range-запросов для скорости.

Сервисы с поддержкой возобновления

Современные сервисы передачи в основном поддерживают возобновление загрузки:

| Сервис | Возобновление загрузки | Возобновление скачивания | |---|---|---| | SwissTransfer | Да (на базе tus) | Да (HTTP ranges) | | HexaTransfer | Да (чанки, совместимо с tus) | Да | | WeTransfer | Да (чанкированные загрузки) | Да | | Dropbox Transfer | Да | Да | | Google Drive | Да (Resumable Upload API) | Да | | OneDrive | Да | Да | | Box | Да | Да |

Бесплатные тарифы иногда отключают возобновление, чтобы стимулировать платный апгрейд, но в 2026 году это редкость. Старые сервисы без возобновления исчезают из рекомендательных списков, потому что пользователям надоедают сбои.

Что не возобновляется автоматически

Обычные HTTP POST-загрузки в примитивных приложениях не возобновляются. FTP-передачи исторически варьируются — некоторые клиенты и серверы поддерживают команды REST (перезапуск), другие нет. Email-вложения не могут быть возобновлены: если отправка через Gmail прерывается на 90%, вы начинаете заново.

Торрент-передачи по своей природе возобновляются, поскольку протокол BitTorrent отслеживает, какие части были проверены. Это часть того, почему BitTorrent оставался полезным для очень крупных дистрибуций даже когда веб догонял по другим параметрам.

Возобновление со сквозным шифрованием

Возобновляемые загрузки в сочетании с клиентским шифрованием требуют тщательного чанкирования. Файл разбивается на чанки, каждый чанк шифруется AES-256-GCM с уникальным IV (вектором инициализации), затем загружается. При возобновлении клиент должен знать, какие чанки завершены, и продолжать со следующего.

Поскольку каждый чанк независимо зашифрован и аутентифицирован (AEAD-режим GCM), частичные загрузки не могут быть подделаны. Вредоносный сервер, вставляющий мусор на смещении 5 ГБ, потерпел бы неудачу при аутентификации при расшифровке получателем — несоответствие GCM-тега было бы обнаружено.

Реализации вроде HexaTransfer используют IV для каждого чанка, детерминированно выводимые из мастер-ключа и индекса чанка, поэтому возобновление не требует отдельного хранения IV. Сторона расшифровки восстанавливает их из того же вывода.

Передовые практики на стороне клиента

Для максимальной надёжности возобновления:

  • Держите вкладку активной во время загрузки. Приостановка браузерной вкладки прерывает текущие загрузки. Предупреждение «не закрывайте эту вкладку» — стандарт в UI сервисов передачи.
  • По возможности подключайтесь по кабелю. Большинство сбоев вызваны падением Wi-Fi.
  • Отключите энергосберегающий сон во время длительных загрузок. macOS: caffeinate -i. Windows: утилита Awake из Powertoys или изменение плана питания.
  • Не меняйте Wi-Fi сеть в процессе загрузки. TCP-соединение меняет IP и обрывается.
  • Дайте загрузке завершиться, прежде чем закрывать крышку ноутбука. Современные macOS иногда сохраняют загрузки через кратковременный сон, но это ненадёжно.

Проверьте на стороне сервера

Некоторые сервисы показывают неполные прогресс-бары, которые не отражают реальное состояние сервера. После загрузки, пережившей одно или два прерывания, обновите страницу и убедитесь, что ссылка работает — откройте её в режиме инкогнито и скачайте небольшую часть. Если возобновление сработало, весь файл загрузится корректно.

Для сценариев, требующих абсолютной уверенности, вычислите хэш SHA-256 на клиенте, загрузите, затем верифицируйте, хэшируя скачанный файл. Криптографическая проверка целостности занимает 10 секунд CPU на гигабайт и даёт абсолютную гарантию.

Итог

Возобновляемая передача — это базовая функция в 2026 году: любой сервис без неё сразу отпадает для файлов свыше нескольких сотен мегабайт. Ищите соответствие tus.io или эквивалентное чанкированное поведение. Убедитесь, что выбранный вами сервис корректно обрабатывает прерывания: проверьте намеренным разрывом сети на небольшом файле, прежде чем доверить ему крупную передачу.

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

Безопасная отправка больших файлов со сквозным шифрованием

Передавайте файлы до 10 ГБ бесплатно со сквозным шифрованием. Регистрация не требуется. Ваши файлы шифруются в браузере перед загрузкой — никто другой не может их прочитать.

Отправить файл