Загрузка файла частями: как проверить сборку после обрыва

При загрузке файла частями успешная отправка нескольких блоков ещё не подтверждает получение целого документа. Перед завершением нужно проверить принадлежность частей одной загрузке, полноту, порядок и соответствие ожидаемому содержимому. Иначе после обрыва пользователь увидит «готово», а приложение сохранит пропуск, повтор или фрагмент другой версии файла.

Разберём это на искусственном содержимом AAAABBBBCCCC длиной двенадцать байтов. Оно разделено на три части по четыре байта и не является настоящим документом. Пример нужен для проверки модели сборки, а не для внедрения собственного сетевого протокола по статье. Реальная реализация требует отдельных испытаний запросов, параллельной обработки, хранилища, доступа и ограничений ресурсов.

Что произойдёт, если считать только полученные сообщения

Условная загрузка У-1 ожидает части с номерами 0, 1 и 2. Приложение получило 0, 1 и повторно 1. Сообщений три, но третья часть не появилась. Проверка «получено три сообщения» ошибочно завершит работу. Подсчёт суммарных байтов тоже способен дать двенадцать, хотя правильного набора нет.

Другой случай: части пришли в порядке 2, 0, 1. Все необходимые данные есть, но склеивание по времени получения даст CCCCAAAABBBB вместо AAAABBBBCCCC. Следовательно, порядок доставки не должен становиться порядком содержимого. Для выбранной модели нужен определённый порядок частей, а для другой реализации — эквивалентное правило положения данных.

Третий случай выглядит ещё убедительнее: получены AAAA, ZZZZ и CCCC. Номера и общая длина совпадают с ожиданием, но середина другая. Равный размер не доказывает одинаковое содержимое. В учебном примере итог сравнивают с заранее известным SHA-256 исходного набора. Это проверка согласованности с ожидаемыми байтами, а не доказательство безопасности или авторства файла.

Какие сведения нужны выбранной модели

Для учебной сборки сохраняют идентификатор попытки, обозначение исходной версии, ожидаемый размер, число частей и контрольное значение содержимого. У каждой части есть номер и связь с попыткой. Эти поля описывают предложенную модель реестра. Они не являются обязательным набором для всех существующих систем загрузки и не заменяют спецификацию выбранного протокола.

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

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

Готовый протокол и самодельный реестр не взаимозаменяемы

В спецификации tus продолжение связано с ресурсом загрузки и подтверждённым смещением. Клиент может узнать состояние через HEAD и продолжить передачу с соответствующей позиции. При несовпадении смещения сервер должен отклонить запрос конфликтом, не изменяя ресурс. Это конкретное правило tus, а не универсальное описание любой разбитой на блоки загрузки.

Учебная таблица с номерами частей в этой статье не реализует tus. У протокола есть собственные обязательные условия и расширения. Если проект выбирает готовую реализацию, нужно проверять её возможности и настройки, а не добавлять произвольные поля и объявлять совместимость. Наличие слова «возобновление» в интерфейсе не показывает, какой способ согласования состояния используется.

Перед разработкой решите, что действительно требуется пользователю: повтор после краткого обрыва, продолжение после обновления страницы, восстановление на следующий день или перенос на другое устройство. Это разные границы продукта. Некоторые варианты требуют заново получить доступ к исходному файлу или создать новую попытку. Ограничения лучше показать до начала большого ожидания.

После обрыва уточняют подтверждённое состояние

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

Полоса прогресса должна опираться на понятную величину. Отправленные устройством байты, подтверждённые сервером данные и готовый доступный документ относятся к разным этапам. Пользователю можно дать простой экран, но сообщение «файл сохранён» должно соответствовать установленному результату. На этапе сборки или дополнительной проверки уместно показать отдельное ожидание.

В диагностике сохраните условный номер попытки, ожидаемую позицию и доступный ответ сервера. Не копируйте содержимое документов в обычный журнал ради поиска пропавшего блока. Для первичного воспроизведения достаточно искусственного набора и управляемого обрыва на тестовой системе. Массовые отправки настоящих файлов на рабочий сервер здесь не нужны.

Сборка и открытие доступа требуют отдельных решений

Когда части приняты, приложение ещё должно получить целый результат и установить его состояние. Два одновременных запроса завершения не должны создавать две независимые выдачи без предусмотренного смысла. Способ защиты перехода выбирают под хранилище и модель транзакций. Последовательный учебный тест из таблицы не доказывает правильность конкурентной обработки.

Если сборка закончилась ошибкой, сохраните различие между доступными частями и готовым файлом. Повторная попытка не должна незаметно объявлять предыдущий непроверенный результат пригодным. Для временных данных определяют срок существования и процедуру очистки. Очистка не должна удалять действующую загрузку только потому, что давно не менялась экранная полоса прогресса.

После получения целого файла остаются другие проверки. Их границы разобраны в статье о документе до открытия доступа. Здесь критерий уже: приложение собрало именно ожидаемый набор без пропусков и смешения попыток. Этот результат нельзя автоматически расширять до утверждения, что документ безопасен и доступен любому сотруднику.

Ограничения считают для всей попытки

Деление большого файла на небольшие запросы не должно отменять согласованный предел целого документа. Проверяйте общий ожидаемый объём, число активных попыток и фактически сохранённые временные данные. Иначе интерфейс может принимать каждый маленький блок по отдельности, пока место для полного результата уже закончилось. Конкретные пределы задают по ресурсам приложения и требованиям проекта.

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

Как принять восстановление загрузки

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

Отдельно испытайте двойное завершение, удаление попытки во время обработки и повторный выбор изменённого файла с прежним именем. Эти случаи не входят в арифметическую модель и требуют реализации на вашем стеке. Исправление принимают, когда понятны состав результата, подтверждённое состояние после обрыва и следующий шаг пользователя, а зелёный индикатор не скрывает незавершённую сборку.