Cloudflare : Origin Range Requests, sans réglage

Ce qui se passe

Un lecteur vidéo qui saute au milieu du film demande quelques mégaoctets. Avec l'ancien cache de Cloudflare, cette requête pouvait faire tirer 128 MiB depuis l'origine et les faire circuler entre centres de données, parfois après le départ du spectateur. Cloudflare a refait le mécanisme et l'ouvre à tous les forfaits sous le nom d'Origin Range Requests, sans taille à régler ni contact avec le support.

Pourquoi l'ancien cache coûtait cher

Une requête Range demande une partie d'une ressource, et le serveur répond 206 Partial Content avec l'intervalle fourni :

HTTP

GET /movie.mp4 HTTP/1.1
Host: example.com
Range: bytes=1048576-2097151

L'ancien cache découpait chaque requête en tranches de taille fixe, choisie par zone, selon le principe du découpage de cache décrit par nginx. Aucune valeur ne convenait à tout :

une tranche petite multipliait les petites requêtes vers l'origine et chargeait la mémoire ;
une tranche grande faisait télécharger bien plus que demandé, et chaque étape du trajet, de l'origine au client, multipliait le gaspillage ;
les tailles configurées allaient de quelques dizaines de kilo-octets à quelques dizaines de gigaoctets ; changer la taille invalidait le cache, car elle entrait dans la clé ;
des requêtes simultanées tombant dans la même tranche pouvaient se bloquer, et la fonction ne se combinait pas avec le streaming concurrent.

R2 en était le plus gros utilisateur interne, avec une tranche de 64 MiB : une petite lecture à cheval sur deux tranches coûtait 128 MiB.

Ce qui change

Pingora, le nouveau serveur de cache, stocke déjà chaque fichier sur disque en morceaux de taille fixe. Le morceau devient la tranche, et le réglage disparaît. Pour une requête Range, le cache :

cherche les en-têtes de la ressource et les plages déjà couvertes ;
lit ce qu'il peut sur disque ou dans les flux en cours ;
demande à l'origine les plages manquantes, alignées sur les frontières de morceaux ;
écrit les nouveaux octets et note la plage dans les métadonnées ;
assemble la réponse avec Content-Range et Content-Length justes, et ne renvoie que les octets demandés.

Une deuxième requête dont la plage recoupe un téléchargement en cours s'y rattache au lieu d'ouvrir une autre lecture sur l'origine. Avant d'assembler, Cloudflare vérifie que tout vient de la même version : taille totale stable, même ETag, et If-Range respecté (version différente : la ressource entière). Il ne compose pas de plage sur un contenu qu'il va décompresser. Les réponses restent du HTTP standard : 206 pour une plage satisfaisable, 416 sinon, ressource complète quand une plage serait risquée.

Les chiffres

Pour R2 : le p99 du premier octet a été divisé par deux environ, en cas de succès comme de défaut de cache. Une amélioration ultérieure, qui mélange octets du disque et octets de l'amont dans une seule réponse, a réduit le trafic des niveaux de cache de R2 et de charges proches d'environ 6 % d'une semaine à l'autre, soit des pétaoctets par jour en moins entre centres de données.

Comment s'y prendre

Créer une Cache Rule qui cible vos fichiers volumineux (tableau de bord : Caching, puis Cache Rules) et régler Origin Range Requests sur On. Par l'API, le paramètre est origin_range_requests avec mode à on. Les usages visés : vidéo MP4 avec saut, téléchargements reprenables, distributions logicielles et dépôts de paquets, images disque et archives, fichiers de modèles d'IA, clients qui ne lisent qu'une petite région d'un gros fichier.

Limites : une plage plus petite qu'un morceau télécharge quand même le morceau entier ; le surcoût est borné mais pas nul. Activer la fonction ne rend pas cacheable ce qui ne l'était pas, et l'origine doit accepter les plages d'octets. La taille d'un morceau n'est pas donnée. Cloudflare prévoit d'en faire le mode par défaut pour certains types de fichiers, modifiable par règle.

Source : Cloudflare, « Origin Range Requests », 23 octobre 2026. Source en anglais.