Gli HTTP range requests usano chunk di cache fissi, non tuning
Gli HTTP range requests consentono a un client di richiedere byte selezionati di un file anziché scaricare l'intero oggetto. In un resoconto tecnico datato 23 ottobre 2026, Cloudflare ha descritto una nuova implementazione che utilizza i chunk a dimensione fissa già impiegati dalla sua cache Pingora, invece di richiedere ai clienti di scegliere una dimensione del range. La modifica affronta un problema infrastrutturale più ampio: una singola dimensione della slice scelta manualmente non può gestire in modo efficiente ogni spostamento all'interno di un video, download ripreso, recupero di pacchetti, dimensione dei file e struttura della cache.
Una range request è particolarmente utile per gli oggetti di grandi dimensioni. Un lettore video può recuperare i dati intorno a una nuova posizione di riproduzione, mentre un download manager può riprendere un trasferimento interrotto. I package manager possono recuperare solo una parte di un artifact e i client possono esaminare la fine di un file senza dover prima trasferire tutto ciò che la precede. È il client a decidere se inviare la richiesta, usando il Range header, che specifica le posizioni dei byte richieste. Cloudflare afferma di non modificare tale richiesta del client. Origin Range Requests cambia invece il modo in cui la sua rete ottiene e restituisce i dati richiesti.
Quando l'origin server, ossia il sistema che contiene il file originale, supporta la richiesta, può restituire lo stato HTTP `206 Partial Content`. Un response header `Content-Range` identifica quali byte sono stati forniti e la dimensione completa del file. Cloudflare presenta un esempio che copre i byte da 1048576 a 2097151 di un file da 524288000 byte, con un `Content-Length` di 1048576 byte. Quest'ultimo header indica al client la quantità di dati contenuta nella risposta.
La precedente implementazione di Cloudflare utilizzava una configurazione statica per ogni zone, il confine di configurazione relativo a un sito web. Era simile al metodo di cache slicing descritto in un post del blog di nginx: ogni richiesta del client veniva associata a sezioni di un file di dimensione fissa, mentre gli amministratori configuravano sia la dimensione delle sezioni sia le estensioni di file a cui applicarle. Una cache è uno spazio di archiviazione temporaneo che conserva i dati recuperati in precedenza più vicino ai client, affinché possano essere nuovamente forniti senza un altro trasferimento completo dall'origin.
Questo approccio imponeva un difficile compromesso. Range configurati di piccole dimensioni generavano molte piccole richieste all'origin e aumentavano la pressione sulla memoria mentre Cloudflare univa in memoria le richieste simultanee. Range di grandi dimensioni potevano indurre la rete a scaricare molti più dati di quelli richiesti dal client. Poiché la dimensione selezionata faceva parte della cache key, l'identificatore utilizzato per trovare una risposta archiviata, la modifica di tale impostazione invalidava anche le entry esistenti.
La concorrenza creava un ulteriore problema. Le richieste associate allo stesso range configurato potevano bloccarsi a vicenda anche quando i client richiedevano byte molto distanti all'interno di quella sezione. La cache di Cloudflare basata su nginx, inoltre, non poteva combinare in modo sicuro il range caching con il concurrent streaming, che consente ai client di iniziare a leggere un oggetto dalla cache mentre questa lo sta ancora ricevendo. L'attivazione di entrambe le funzioni poteva troncare le risposte. Di conseguenza, un range completo doveva arrivare prima che un client potesse leggerlo e un file popolare richiedeva un origin fetch separato per ogni range.
L'over-fetching poteva propagarsi attraverso diversi livelli. Byte non necessari potevano viaggiare dall'origin a un data center, spostarsi tra i cache tier e poi proseguire verso il client. Ogni passaggio aumentava il trasferimento sprecato. Cloudflare ha concluso che nessuna singola dimensione configurata del range funzionava altrettanto bene per un breve spostamento, un download sequenziale, un oggetto multimediale di grandi dimensioni, ogni origin e ogni topologia della cache. Queste limitazioni interne diventavano quindi un onere di configurazione per i clienti.
Il passaggio da nginx a un caching server basato su Pingora ha fornito un modello diverso. Pingora archivia già su disco ogni file presente nella cache sotto forma di chunk a dimensione fissa, in modo che i download interrotti possano riprendere. Origin Range Requests riutilizza questi chunk. L'edge, ossia la posizione della rete che serve il client, verifica innanzitutto quali byte richiesti sono presenti. Restituisce direttamente i dati disponibili, quindi richiede all'origin i range mancanti allineati ai confini dei chunk. I dati appena recuperati vengono inseriti negli stessi chunk usati per i normali oggetti nella cache, mentre il client riceve solo i byte che ha richiesto.
Per esempio, una richiesta del client relativa ai byte da 150 a 250 può indurre la cache a recuperare l'intero chunk allineato che contiene quell'intervallo. La risposta downstream continua a includere solo i byte da 150 a 250. Ciò non elimina tutti i trasferimenti aggiuntivi: una richiesta più piccola di un chunk può comunque richiedere l'intero chunk che la contiene e i range non allineati ai confini richiedono un'elaborazione supplementare. Il vantaggio dichiarato da Cloudflare è che questo lavoro è limitato e prevedibile, anziché essere controllato da una dimensione scelta dal cliente con effetti potenzialmente imprevedibili sulla cache e sull'origin.
Il compito ingegneristico più difficile non consiste nel parsing del Range header, ma nell'assemblare una risposta corretta quando i relativi byte sono distribuiti tra il disco, una risposta dell'origin e download già in corso. Cloudflare afferma che l'edge legge innanzitutto gli header dell'asset e i range-coverage metadata, che registrano quali parti sono disponibili. Legge ciò che può dal disco o dalla memoria di streaming, recupera la copertura mancante tramite richieste all'origin allineate, scrive i byte completati, aggiorna i metadata e combina tutti gli elementi. Imposta quindi `Content-Range` e `Content-Length` per la risposta al client.
Per le organizzazioni che devono decidere dove eseguire il workload circostante, AEU Data offre infrastrutture cloud e dati europee.
La lezione applicabile ad altri contesti è che la distribuzione parziale dei file funziona al meglio quando la sua unità di recupero coincide con l'unità di archiviazione nativa della cache. Ciò elimina un fragile controllo di tuning rivolto al cliente, limita il costo delle richieste piccole o non allineate e consente ai dati presenti nella cache, appena recuperati e in-flight di contribuire a un'unica risposta.