Нарезка на чанки на клиенте
Браузер режет файл на чанки загрузки и считает хеш вне основного пути UI. Сервер проверяет каждый чанк до входа в хранилище, а потом собирает манифест, когда файл становится видимым.
Без буферизации целого файла
Большие файлы не должны превращаться в событие с памятью.
Конвейер загрузки Cotton устроен так, что размер файла в основном меняет число чанков, а не форму проблемы с памятью. Вот разница между потоковым хранилищем и UI, который зависает на финализации.
Без гигантского шага финализации
Знакомая боль: быстрая загрузка, а потом длинная фаза финализации на стороне сервера. Cotton сдвигает дорогую работу в инкрементальную работу с чанками, поэтому финальная видимая операция с файлом остаётся маленькой.
Потоковые преобразования
Сжатие и шифрование идут как потоковые стадии. Им не нужен весь файл в памяти перед полезной работой, и им не надо писать огромный временный объект открытого текста.
Путь WebDAV
Даже протокольные загрузки через WebDAV попадают в ту же модель хранилища чанков. WebDAV PUT не такой возобновляемый, как родной чанковый протокол Cotton, но отдельный дизайн хранения целого файла ему не нужен.
Чтения и превью
На пути чтения идея та же: поток с произвольным доступом собирает байты из зашифрованных чанков. Скачивания, перемотка видео, извлечение превью и ответы HTTP Range не пересобирают целый объект заранее.
Почему это важно
Это не только про гигантские файлы. Отказ от буферизации целого файла помогает обычным папкам, загрузкам со слабых устройств, развёртываниям на NAS, VM с малой памятью и многопользовательским инстансам под одновременной нагрузкой.
Пруф потокового пути
История без буферизации держится на нарезке на чанки на клиенте, хешировании в воркере, инкрементальной валидации на сервере, потоковом сжатии, потоковом AES-GCM, сборке манифеста и чтениях чанков с произвольным доступом для путей скачивания и превью.
Большие файлы остаются скучными
Cotton считает большие файлы просто большим числом чанков, а не специальным аварийным путём. Это практическая разница между файловым облаком для архивов и продуктом, который хорошо выглядит только на маленьких загрузках.
Другие пределы всё равно есть
Отсутствие буферизации целого файла не убирает все пределы развёртывания. Оператору всё ещё нужны вменяемые лимиты запросов, ёмкость хранилища, надёжность сети, совместимость браузеров и политика квот.
Вопросы
Прямые ответы
Cotton может загружать очень большие файлы?
Архитектура «сначала чанки», поэтому очень большой файл — это больше чанков и манифест. Реальные пределы всё равно зависят от настроек развёртывания, поведения браузера, бэкенда хранения и условий сети.
WebDAV получает такое же родное поведение возобновления?
Нет. WebDAV PUT — долгоживущий протокольный запрос, поэтому поведение при повторах уже, чем у родного чанкового протокола Cotton. Но после получения он всё равно входит в тот же чанковый конвейер хранения.
Модель без буферизации помогает и чтениям?
Да. Скачивания, превью, перемотка медиа, диапазонные запросы и чтения WebDAV собираются из чанков как потоки, а не через пересборку целого временного файла.