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

Про автора

Фемке Утрехт

провідна фронтенд-розробниця

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

Усі публікації автора