Cloudflare e i 128 MiB sprecati: il costo nascosto della cache

Una CDN dovrebbe avvicinare i dati a chi li chiede. Ma se per consegnare una porzione minuscola di un file ne trasferisce decine di megabyte, la cache non sta risolvendo il problema: lo sta semplicemente spostando su una rete più grande. È un dettaglio che nei diagrammi architetturali non compare quasi mai, perché il diagramma si ferma alla parola “HIT”. Il conto, invece, continua a correre.

Il 23 ottobre 2026 Cloudflare ha descritto Origin Range Requests, una gestione dei byte-range basata sul motore di cache Pingora e ora attivabile tramite Cache Rules su tutti i piani. L’annuncio merita attenzione non perché abbia inventato HTTP Range, che esiste da tempo, ma perché mostra quanto possa costare un’astrazione sbagliata quando milioni di richieste attraversano la stessa infrastruttura.

Il problema non era il file. Era la fetta scelta dalla cache.

Immaginiamo un lettore video che salta al minuto quaranta. Non ha bisogno del film intero: invia una richiesta HTTP con l’header Range per ricevere solo un intervallo di byte. Se tutto funziona, il server risponde con 206 Partial Content e dichiara l’intervallo effettivo in Content-Range. Fin qui non c’è nulla di esotico: è il contratto definito dalla semantica HTTP di RFC 9110.

Il vecchio caching a intervalli di Cloudflare usava invece una dimensione fissa della fetta, configurata per zona. È una scelta comprensibile finché la si guarda da vicino: tagli piccoli significano più richieste all’origine e più lavoro di coordinamento; tagli grandi significano meno operazioni, ma potenzialmente molti byte trasferiti inutilmente. Una dimensione ragionevole per un download sequenziale può essere pessima per una lettura casuale, e viceversa.

Cloudflare racconta che, per R2, la dimensione configurata era di 64 MiB. Una piccola richiesta che attraversava il confine tra due fette poteva quindi innescare il trasferimento di 128 MiB. Non è un rapporto fisso valido per ogni richiesta e non significa che ogni byte richiesto generasse sempre 128 MiB di traffico: è il caso concreto di quella configurazione, sufficiente però a spiegare la sproporzione. Se il trasferimento passa anche tra livelli di cache e data center, lo spreco non resta confinato all’origine.

Pingora non ha trovato la dimensione perfetta. Ha tolto il parametro.

La nuova architettura sfrutta un fatto già vero nel motore di cache di Pingora: i file sono memorizzati su disco in chunk di dimensione fissa, utili anche a riprendere download interrotti. Invece di imporre un secondo schema di suddivisione deciso dall’utente, Origin Range Requests allinea le richieste all’origine ai chunk che la cache usa già. La documentazione tecnica Cloudflare specifica una granularità di 1 MiB.

Supponiamo che il client chieda 1 KiB di un oggetto non ancora presente. Cloudflare può scaricare dall’origine il chunk allineato da 1 MiB che contiene quei byte, memorizzarlo e restituire al client soltanto il kilobyte richiesto. Non è assenza di overhead: il rapporto tra dati richiesti e dati scaricati può ancora essere elevato. È però un overhead delimitato, prevedibile e condivisibile con richieste successive. Se i byte sono già in cache, quel fetch può non servire affatto.

La differenza più interessante non è quindi passare da 64 a 1 MiB. È smettere di trattare la dimensione della fetta come una decisione che il cliente deve indovinare. Un sistema ben progettato dovrebbe conoscere le proprie strutture interne abbastanza bene da non scaricarne il costo cognitivo su chi lo configura. Qui il passaggio da nginx al cache server Pingora ha permesso di rivedere proprio quel confine.

Una cache efficiente non è quella che evita sempre la rete. È quella che sa quali byte possiede, quali sta già ricevendo e quali vale davvero la pena chiedere ancora.

Il difficile comincia quando i byte arrivano da tre posti diversi

C’è una complessità che una semplice regola di dimensionamento non risolve. Una richiesta può coprire una parte già scritta su disco, una parte che un altro download sta trasferendo e una parte che nessuno ha ancora chiesto all’origine. Il coordinatore deve combinare questi pezzi in un’unica risposta coerente, senza scaricare due volte gli stessi dati e senza aspettare che un intero intervallo sia completo prima di iniziare a servire ciò che è già disponibile.

È qui che il racconto tecnico di Cloudflare diventa più interessante del lancio commerciale. Il coordinatore verifica copertura e metadati, legge i chunk disponibili, si aggancia ai download in corso e apre fetch allineati solo per le lacune. Poi aggiorna la copertura della cache e costruisce una risposta verso il client con status, lunghezza e intervallo corretti. L’operazione non è un singolo lookup: è un piccolo piano di esecuzione sui byte.

Il parallelismo con altri sistemi software è evidente. In un database non basta sapere che esiste un indice: bisogna capire quali pagine sono già in memoria e quali letture sono in corso. In un sistema di code non basta avere un consumer: serve impedire che più worker rifacciano inutilmente lo stesso lavoro. Nel caching di grandi oggetti il principio è analogo, ma il risultato finale deve anche rispettare il protocollo HTTP. È lo stesso genere di compromesso architetturale che emerge quando si analizza il costo nascosto della memoria in Cloudflare Workers: ottimizzare una metrica locale non garantisce che il sistema complessivo migliori.

Un 206 corretto vale più di un HIT veloce

Comporre byte da richieste differenti introduce un rischio serio: mescolare versioni diverse dello stesso oggetto. Se l’origine modifica il file mentre la CDN ne sta recuperando porzioni, una risposta apparentemente valida potrebbe contenere un prefisso vecchio e un suffisso nuovo. Per questo contano gli ETag, la dimensione complessiva dell’oggetto e la coerenza degli header Content-Range e Content-Length. Il coordinatore non può considerare intercambiabili due pezzi solo perché occupano lo stesso offset.

Anche If-Range è più di una finezza da specifica: permette al client di chiedere un intervallo soltanto se il validatore della rappresentazione corrisponde a quello noto. Se non corrisponde, il comportamento corretto è tornare alla rappresentazione completa. Un intervallo non soddisfacibile porta a 416 Range Not Satisfiable, non a una risposta parziale inventata. Se il contenuto deve essere decompresso, gli offset dei byte compressi non corrispondono a quelli della rappresentazione decompressa: la CDN può quindi rinunciare al range e servire il contenuto completo.

Cloudflare documenta requisiti precisi per memorizzare una risposta 206 dell’origine: corpo non compresso, Content-Range coerente con la richiesta, Content-Length numerico e corretto, niente Transfer-Encoding, dimensione totale stabile e ETag coerente quando presente. Le richieste generate dalla funzionalità includono Accept-Encoding: identity. Se l’origine ignora Range e restituisce 200 OK, Cloudflare può usare la risposta, ma deve comunque scaricare il file completo. Una regola di cache non corregge un’origine che non rispetta il contratto.

I numeri migliorano. Ma di chi sono i numeri?

Dopo la migrazione di R2, Cloudflare dichiara un calo di circa il 50% del p99 time to first byte sia sugli hit sia sui miss, e una successiva riduzione di circa il 6% del traffico tiered cache per R2 e carichi simili nel confronto settimana su settimana. Sono risultati operativi rilevanti, ma restano misure interne comunicate dal fornitore: non un benchmark indipendente, non una promessa di dimezzare il TTFB di qualsiasi sito e non una riduzione del 6% della bolletta di chi attiva l’opzione.

Chi gestisce una CDN dovrebbe misurare prima e dopo almeno quattro cose: distribuzione del TTFB, in particolare p95/p99; byte effettivamente letti dall’origine rispetto ai byte consegnati ai client; numero di fetch parziali e loro sovrapposizione; errori o risposte complete inattese su richieste Range. Il semplice cache-hit ratio, preso da solo, non racconta quanti byte sono stati movimentati per produrre quell’hit. È un problema di osservabilità, prima ancora che di configurazione.

Attivare Origin Range Requests non rende ogni file cacheable

La funzione si abilita tramite Cache Rules, selezionando il traffico pertinente e impostando origin_range_requests.mode su on. È pensata per video seekable, download riprendibili, archivi, distribuzioni software, immagini disco e altri oggetti grandi per i quali i client chiedono intervalli. La disponibilità della configurazione tramite Rulesets API era già documentata nel changelog del 2 settembre 2026: la novità dell’annuncio del 23 ottobre è il rollout self-service generalizzato con la spiegazione architetturale, non la nascita improvvisa del supporto Range.

Ci sono limiti che non spariscono: l’oggetto deve rispettare le normali regole di eleggibilità alla cache; i limiti dimensionali si applicano al file intero, non alla piccola porzione richiesta; Origin Range Requests non è supportato con Cache Reserve. E se la tua applicazione firma richieste, applica rate limit o analizza i log dell’origine, deve sapere che gli intervalli chiesti da Cloudflare possono essere diversi da quelli chiesti dal client. La CDN sta pianificando fetch, non facendo da semplice proxy trasparente degli header.

Il test sensato non consiste nell’accendere la regola su tutto il traffico e aspettare una dashboard più verde. Conviene selezionare un insieme misurabile di oggetti grandi, verificare che l’origine restituisca 206 corretti e non compressi, confrontare log e volumi, e osservare se il beneficio resta stabile con richieste concorrenti e accessi casuali. Solo dopo ha senso estendere il perimetro. In un sistema reale, la scelta di cosa condividere e cosa isolare è spesso più importante della tecnologia scelta per farlo.

La lezione non è soltanto per chi usa Cloudflare

L’aspetto più istruttivo è che Cloudflare non ha annunciato un parametro nuovo da ottimizzare. Ha descritto un cambio di modello che rende quel parametro superfluo. Prima il cliente doveva conoscere una parte del funzionamento interno della cache e accettare un compromesso statico; ora il sistema coordina dati disponibili, dati in transito e dati mancanti usando una granularità coerente con il proprio storage.

Questo non elimina la complessità. La sposta dove può essere gestita con informazioni migliori e verifiche più rigorose. È una differenza enorme, soprattutto quando un errore apparentemente innocuo si moltiplica per milioni di richieste. Una CDN che trasferisce 128 MiB per soddisfare pochi byte non ha un problema di marketing o di configurazione estetica: ha un problema di architettura. E il fatto che quel problema fosse nascosto dietro una cache hit è forse la parte più utile da ricordare.