Cloudflare открыла Origin Range Requests для кэширования частей больших файлов

23 октября 2026 года Cloudflare представила Origin Range Requests — новый способ кэшировать частичные загрузки больших файлов. Как пишет The Cloudflare Blog, функция доступна на всех тарифах. Включить её для нужного трафика можно через Cache Rule, не подбирая размер диапазона. После перехода R2 на новую реализацию p99 времени до первого байта, по данным компании, сократился примерно вдвое.

Почему прежний кэш загружал лишнее

При перемотке видео плеер может запросить лишь небольшой участок файла. Для этого клиент отправляет HTTP-запрос с заголовком Range; если сервер может отдать нужные байты, он отвечает 206 Partial Content. Частичные запросы используют и для возобновления загрузок больших файлов. О похожем сценарии со стороны браузера мы писали отдельно.

Прежняя система Cloudflare сопоставляла клиентский запрос с диапазонами фиксированного размера, настроенными для зоны. Большой диапазон заставлял CDN забирать у источника гораздо больше байтов, чем требовалось клиенту. Маленький порождал множество обращений к источнику и увеличивал нагрузку на память при объединении запросов. Изменение настройки к тому же делало старые записи кэша непригодными: размер диапазона входил в ключ.

Были и ограничения на одновременную работу с файлом. Запросы к разным участкам одного диапазона могли блокировать друг друга. Кэш на базе nginx не позволял совместить такую обработку с отдачей файла, пока тот ещё записывается в кэш. Лишние байты при этом проходили не только путь от источника: их могли передавать и между уровнями распределённого кэша.

У R2 прежний диапазон составлял 64 МиБ. Поэтому небольшое чтение на границе двух диапазонов могло вызвать передачу 128 МиБ между дата-центрами. Для запроса нескольких байтов маршрут получался внушительный.

Как Pingora собирает частичный ответ

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

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

Прежде чем соединить части, система проверяет ответ источника, размер объекта и ETag: байты должны относиться к одному представлению. Если условие If-Range не выполняется, Cloudflare отдаёт полный объект, а не смесь версий. Полный ответ она возвращает и тогда, когда после распаковки нельзя корректно выполнить запрос диапазона. Запросу, который можно удовлетворить, соответствует 206; диапазону, который невозможно удовлетворить, — 416.

Сверх запрошенного объёма всё ещё приходится загружать данные: маленький запрос может потребовать целый чанк. Но избыточная работа теперь ограничена размером чанка кэша, а не размером диапазона, который заказчик Cloudflare задавал в настройках зоны. После перевода R2 p99 времени до первого байта снизился примерно наполовину как при попаданиях в кэш, так и при промахах. Дальнейшее улучшение сборки ответа из кэша и данных вышестоящего узла сократило трафик между уровнями кэша для R2 и похожих нагрузок примерно на 6% за неделю.

Что делать сайтам с крупными файлами

Функция рассчитана на кэшируемые объекты, части которых клиенты запрашивают отдельно: видео с перемоткой, возобновляемые загрузки, программные пакеты, архивы, образы дисков и файлы моделей. Команда сайта выбирает такой трафик в Cache Rules и включает Origin Range Requests через панель Caching > Cache Rules или API. Обращаться в поддержку и настраивать размер диапазона не нужно.

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

Моё мнение: настройка ушла туда, где ей место

Мне нравится, что из панели убрали выбор между «слишком много запросов» и «слишком много байтов». Заказчику Cloudflare не нужно угадывать размер диапазона, который устроит и короткую перемотку, и длинную загрузку. Когда маленький запрос отправляет 128 МиБ гулять между дата-центрами, такая гибкость выглядит несколько переоценённой.

Для сайта с видео или тяжёлыми загрузками я бы всё же начал с проверки: поддерживает ли источник диапазоны, кэшируются ли ответы и сколько данных передаётся при реальном использовании. Результаты R2 показывают эффект на нагрузке Cloudflare, а не обещают такое же ускорение каждому сайту. Скорость лучше обсуждать по замерам — фраза «у меня стало быстрее» пока не метрика.

Источники

Откуда новость. Текст — пересказ своими словами, факты — из источника, мнение — автора.

1. Origin Range Requests: Serving large files without range-request tuning blog.cloudflare.com

Об авторе

Фемке Утрехт

ведущий frontend-разработчик

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

Все публикации автора