Chunk (чанк) — порция данных, обрабатываемая или передаваемая как единица. Термин применяется в нескольких контекстах: HTTP chunked transfer encoding, объектные хранилища (S3 Multipart Upload), системы резервного копирования с дедупликацией, потоковая обработка данных. Общая идея: вместо одного непрерывного потока данные делятся на управляемые части с независимой обработкой каждой.
HTTP Chunked Transfer Encoding
RFC 9112 (HTTP/1.1) определяет chunked transfer encoding — механизм передачи ответа без заголовка Content-Length. Каждый чанк предваряется шестнадцатеричным размером:
HTTP/1.1 200 OK
Transfer-Encoding: chunked
7
Mozilla
9
Developer
0
Нулевой чанк сигнализирует об окончании ответа. Chunked encoding используется когда сервер генерирует ответ динамически — стриминг AI-ответов, SSE (Server-Sent Events), экспорт больших CSV-файлов — и не может заранее указать Content-Length. Nginx поддерживает chunked encoding автоматически при proxy_buffering off для стриминга от upstream.
Чанки в объектных хранилищах
S3 Multipart Upload разбивает файл на чанки для параллельной загрузки. Минимальный размер чанка: 5 МБ (кроме последнего). Максимум: 5 ГБ на чанк. Максимум чанков: 10 000 (максимальный размер объекта 50 ТБ).
Пример: файл 10 ГБ загружается 100 чанками по 100 МБ параллельно в 10 потоков — время снижается в 10 раз. При разрыве соединения незавершённые чанки можно возобновить по UploadId без перезагрузки всего файла. Инструмент rclone автоматически использует Multipart Upload при копировании в S3 или Cloudflare R2.
Чанки в дедупликации и бэкапах
BorgBackup, Restic и другие инструменты с дедупликацией разбивают файлы на чанки переменного размера через Content-Defined Chunking (CDC). CDC использует скользящий хеш (Rabin fingerprint или Buzhash) для обнаружения «точек разреза» — независимо от смещений внутри файла. Одинаковые чанки сохраняются один раз; при изменении файла на 1 байт пересчитывается только затронутый чанк.
Эффективность дедупликации для VM-образов: два VPS с одинаковой базовой ОС (Ubuntu 22.04) разделяют 8–12 ГБ общих чанков. Первый бэкап требует 20 ГБ, второй — только уникальные чанки (~2–5 ГБ изменений).
Чанки в потоковой обработке
Kafka разбивает поток событий на сегменты (segments) и батчи. Python-библиотека chunked() из itertools: обработка больших CSV-файлов батчами по 1000 строк вместо загрузки всего файла в память:
import pandas as pd
for chunk in pd.read_csv('large_file.csv', chunksize=1000):
process(chunk)
История
HTTP chunked transfer encoding стандартизирован в RFC 2068 (HTTP/1.1, 1997). S3 Multipart Upload появился в Amazon S3 в марте 2010 года. Content-Defined Chunking разработан в 1990-х в контексте систем распределённых файловых систем. rsync (1996) первым популяризировал delta-transfer — передачу только изменённых чанков файла.
На что обращать внимание
При загрузке больших файлов в S3 или объектное хранилище: Multipart Upload обязателен для объектов более 100 МБ — однопоточная загрузка медленна и не возобновляема. Незавершённые multipart uploads накапливаются и занимают место — настройте lifecycle rule для автоматической очистки через 7 дней. Для бэкапов: оптимальный размер чанка Restic — 512 КБ–8 МБ; мелкие чанки дают лучшую дедупликацию, крупные — меньше метаданных.
Чанки в веб-разработке и Nginx
При проксировании через Nginx и потоковой отдаче данных от upstream важно понимать поведение буферизации. По умолчанию Nginx буферизует ответ от backend и отдаёт его чанками или целиком в зависимости от размера. Для стриминга AI-ответов (LLM с Server-Sent Events) необходимо отключить буферизацию:
location /api/stream {
proxy_pass http://backend;
proxy_buffering off;
proxy_cache off;
add_header X-Accel-Buffering no;
}
Без proxy_buffering off Nginx накапливает весь ответ перед отправкой клиенту, и стриминг не работает — пользователь видит пустой экран до завершения генерации.