Passa al contenuto principale

13. Caching in HTTP (Caching in HTTP)

HTTP è tipicamente utilizzato per sistemi informativi distribuiti, dove le prestazioni possono essere migliorate utilizzando cache di risposta. Il protocollo HTTP/1.1 include molti elementi progettati per far funzionare il caching il meglio possibile. Gli obiettivi del caching in HTTP/1.1 sono eliminare la necessità di inviare richieste in molti casi ed eliminare la necessità di inviare risposte complete in molti altri casi. Il primo riduce il numero di round-trip di rete necessari per molte operazioni; utilizziamo un meccanismo di "scadenza" (expiration) a questo scopo (vedere sezione 13.2). Il secondo riduce i requisiti di larghezza di banda di rete; utilizziamo un meccanismo di "validazione" (validation) a questo scopo (vedere sezione 13.3).

Il protocollo HTTP/1.1 fornisce i seguenti elementi importanti:

  1. Funzionalità di protocollo che forniscono completa trasparenza semantica quando tutte le parti ne hanno bisogno
  2. Funzionalità di protocollo che consentono al server di origine o all'user agent di richiedere e controllare esplicitamente operazioni non trasparenti
  3. Funzionalità di protocollo che consentono alla cache di allegare avvisi alle risposte che non mantengono l'approssimazione richiesta di trasparenza semantica

13.1.1 Cache Correctness (Correttezza della Cache)​

Una cache corretta deve (MUST) rispondere a una richiesta utilizzando la risposta più aggiornata detenuta dalla cache che sia applicabile alla richiesta e soddisfi una delle seguenti condizioni:

  1. È stata verificata per l'equivalenza con ciò che il server di origine restituirebbe rivalidando la risposta con il server di origine (sezione 13.3)

  2. È "sufficientemente fresca" (fresh enough) (vedere sezione 13.2). Per impostazione predefinita, ciò significa che soddisfa i requisiti di freschezza meno restrittivi del client, del server di origine e della cache (vedere sezione 14.9)

  3. È un messaggio di risposta appropriato 304 (Not Modified), 305 (Proxy Redirect) o di errore (4xx o 5xx)

Se la cache non può comunicare con il server di origine, una cache corretta dovrebbe (SHOULD) rispondere come descritto sopra se la risposta può essere correttamente servita dalla cache; altrimenti, deve (MUST) restituire un errore o un avviso che indica il fallimento della comunicazione.

13.1.2 Warnings (Avvisi)​

Ogni volta che una cache restituisce una risposta che non è né di prima mano né "sufficientemente fresca", deve (MUST) allegare un avviso a tale effetto utilizzando l'intestazione generale Warning. Gli avvisi vengono assegnati codici di avviso a tre cifre:

  • 1xx - Avviso che descrive la freschezza o lo stato di rivalidazione della risposta, e quindi deve essere rimosso dopo una rivalidazione riuscita
  • 2xx - Avviso che descrive alcuni aspetti del corpo dell'entità o delle intestazioni dell'entità che non verranno corretti mediante rivalidazione, e quindi non devono essere rimossi dopo una rivalidazione riuscita

13.1.3 Cache-control Mechanisms (Meccanismi di Controllo della Cache)​

I meccanismi di caching di base in HTTP/1.1 (tempi di scadenza specificati dal server e validatori) sono direttive implicite alla cache. L'intestazione Cache-Control consente al client o al server di trasmettere varie direttive in una richiesta o risposta. Queste direttive generalmente sovrascrivono l'algoritmo di caching predefinito.

13.1.4 Explicit User Agent Warnings (Avvisi Espliciti dell'User Agent)​

Molti user agent hanno meccanismi di elenco storico, come un pulsante "Indietro" e un elenco storico, che possono essere utilizzati per visualizzare nuovamente entità recuperate di recente dall'utente. I meccanismi di cronologia e le cache sono diversi.

13.1.5 Exceptions to the Rules and Warnings (Eccezioni alle Regole e Avvisi)​

In alcune situazioni, gli operatori scelgono di configurare le cache per restituire risposte obsolete anche quando non sono conformi alle regole HTTP/1.1. Tali situazioni includono, ma non sono limitate a:

  • Restituire dati obsoleti quando il server di origine non è accessibile
  • Quando le connessioni di rete sono lente o inaffidabili
  • Fornire tempi di risposta più rapidi durante determinati periodi

13.1.6 Client-controlled Behavior (Comportamento Controllato dal Client)​

Gli user agent tipicamente hanno meccanismi di cronologia, come un pulsante indietro, che possono essere utilizzati per visualizzare nuovamente rappresentazioni recuperate in precedenza.

13.2 Expiration Model (Modello di Scadenza)​

Le cache HTTP generalmente memorizzano le voci di cache fino al momento in cui possono usarle senza interrogare il server di origine. Usiamo il termine "semanticamente trasparente" per descrivere una cache quando il suo utilizzo non è visibile né al client richiedente né al server di origine.

13.2.1 Server-Specified Expiration (Scadenza Specificata dal Server)​

Il protocollo di cache HTTP utilizza tempi di scadenza espliciti per indicare quando una risposta diventa obsoleta. Il meccanismo di scadenza si applica solo alle risposte definite come segue:

  • Risposte alle risposte 200, 203, 206, 300, 301 o 410
  • Risposte per le quali il campo di intestazione Cache-Control consente esplicitamente il caching

13.2.2 Heuristic Expiration (Scadenza Euristica)​

Poiché i server di origine non forniscono sempre un tempo di scadenza esplicito, le cache HTTP generalmente assegnano tempi di scadenza euristici, utilizzando algoritmi che utilizzano altri valori di intestazione della voce di cache (come il tempo Last-Modified).

13.2.3 Age Calculations (Calcoli dell'Età)​

Per sapere se una risposta è fresca, la cache deve conoscere la sua età (age). Il valore di Age è una stima del tempo trascorso da quando la risposta è stata generata o validata con successo.

Formula di calcolo dell'età:

age_value = now - date_value
apparent_age = max(0, response_time - date_value)
corrected_received_age = max(apparent_age, age_value)
response_delay = response_time - request_time
corrected_initial_age = corrected_received_age + response_delay
resident_time = now - response_time
current_age = corrected_initial_age + resident_time

13.2.4 Expiration Calculations (Calcoli di Scadenza)​

Per determinare se una risposta è fresca, confrontiamo la sua età corrente con la sua durata di freschezza. Una risposta è fresca quando la sua età non ha superato la sua durata di freschezza.

Calcolo della durata di freschezza:

freshness_lifetime = max_age_value
oppure
freshness_lifetime = expires_value - date_value
oppure
freshness_lifetime = (now - last_modified_value) * 0.1

13.2.5 Disambiguating Expiration Values (Disambiguazione dei Valori di Scadenza)​

Poiché il confronto tra i tempi di scadenza e l'ora corrente è sensibile allo sfasamento dell'orologio, le implementazioni dovrebbero utilizzare il tempo di scadenza più conservativo.

13.2.6 Disambiguating Multiple Responses (Disambiguazione di Risposte Multiple)​

Poiché i client potrebbero accedere alle risorse tramite più percorsi, le cache possono ricevere più risposte per la stessa risorsa. Le cache dovrebbero utilizzare la risposta più recente.

13.3 Validation Model (Modello di Validazione)​

Quando una cache ha una voce di cache obsoleta che desidera utilizzare, deve prima verificare con il server di origine (o tramite una cache con una voce fresca) se la sua voce di cache è ancora utilizzabile. Chiamiamo questa "validazione" della voce di cache.

13.3.1 Last-Modified Dates (Date di Ultima Modifica)​

Il valore del campo di intestazione dell'entità Last-Modified è spesso utilizzato come validatore di cache. Generalmente, il valore Last-Modified della voce di cache viene inviato insieme a un'intestazione di richiesta If-Modified-Since.

13.3.2 Entity Tag Cache Validators (Validatori di Cache con Tag di Entità)​

Il valore del campo di intestazione di risposta ETag (tag di entità) fornisce un validatore di cache "opaco". Ciò può consentire una validazione più affidabile, in particolare quando:

  • Le date di modifica non possono essere comodamente memorizzate
  • La risoluzione di un secondo del valore della data HTTP della data di modifica del documento non è sufficiente
  • Le date di modifica non sono coerenti

13.3.3 Weak and Strong Validators (Validatori Deboli e Forti)​

Poiché gli obiettivi del server di origine e della cache possono differire, a volte i client hanno bisogno solo di una risposta sufficientemente buona, piuttosto che di una copia assolutamente più recente.

  • Validatore forte - cambia ogni volta che l'entità cambia, indipendentemente dall'importanza del cambiamento
  • Validatore debole - potrebbe non cambiare per ogni cambiamento di entità (prefisso "W/")

13.3.4 Rules for When to Use Entity Tags and Last-Modified Dates (Regole per Quando Usare Tag di Entità e Date di Ultima Modifica)​

I server di origine HTTP/1.1 dovrebbero (SHOULD) inviare validatori di tag di entità quando possibile, invece di o in aggiunta ai valori Last-Modified.

13.3.5 Non-validating Conditionals (Condizionali Non Validanti)​

Le richieste condizionali possono anche essere utilizzate per altri scopi, come l'ottimizzazione delle richieste o la prevenzione della perdita di aggiornamenti.

13.4 Response Cacheability (Memorizzabilità nella Cache della Risposta)​

A meno che non sia specificato diversamente, le risposte recuperate utilizzando GET sono memorizzabili nella cache. Le seguenti regole definiscono quando una risposta è memorizzabile nella cache:

  1. Il metodo di richiesta stesso è memorizzabile nella cache (GET e HEAD)
  2. Il codice di stato della risposta è comprensibile e memorizzabile nella cache (200, 203, 204, 206, 300, 301, 404, 405, 410, 414, 501)
  3. L'intestazione Cache-Control non indica il divieto di caching
  4. Se si utilizza una cache condivisa, l'intestazione Authorization non appare, a meno che Cache-Control non lo consenta esplicitamente

13.5 Constructing Responses From Caches (Costruzione di Risposte dalle Cache)​

13.5.1 End-to-end and Hop-by-hop Headers (Intestazioni End-to-End e Hop-by-Hop)​

I campi di intestazione HTTP sono classificati in intestazioni end-to-end e intestazioni hop-by-hop:

  • Intestazioni end-to-end - devono essere trasmesse al destinatario finale
  • Intestazioni hop-by-hop - hanno significato solo per una singola connessione a livello di trasporto

13.5.2 Non-modifiable Headers (Intestazioni Non Modificabili)​

Alcune funzionalità potrebbero richiedere che la cache modifichi le intestazioni di alcune voci di cache. Solo le intestazioni end-to-end possono essere modificate.

13.5.3 Combining Headers (Combinazione di Intestazioni)​

Quando una cache valida una risposta a una richiesta e la risposta contiene alcuni campi di intestazione ma non altri, la cache deve combinare i nuovi campi con i campi della vecchia voce.

13.5.4 Combining Byte Ranges (Combinazione di Intervalli di Byte)​

Una risposta dalla cache può essere una risposta di contenuto parziale. In alcuni casi, la cache può combinare un insieme di intervalli di byte memorizzati e un nuovo intervallo di byte per soddisfare la richiesta.

13.6 Caching Negotiated Responses (Caching di Risposte Negoziate)​

L'uso della negoziazione del contenuto guidata dal server (sezione 12.1) può creare risposte diverse in base ai valori di particolari campi di intestazione della richiesta. Il campo di intestazione Vary viene utilizzato per indicare quali campi di intestazione della richiesta vengono utilizzati nella selezione.

13.7 Shared and Non-Shared Caches (Cache Condivise e Non Condivise)​

Poiché lo scopo e i limiti di alcuni campi di intestazione differiscono per diversi tipi di cache, distinguiamo:

  • Cache non condivise - cache accessibile solo da un singolo utente (ad esempio, cache dell'user agent)
  • Cache condivise - cache accessibile da più utenti (ad esempio, cache proxy)

13.8 Errors or Incomplete Response Cache Behavior (Comportamento della Cache per Errori o Risposte Incomplete)​

Quando una cache riceve una risposta incompleta (ad esempio, meno byte Content-Length di quelli specificati), può (MAY) memorizzare la risposta incompleta. Tuttavia, la cache deve (MUST) trattarla come una risposta parziale.

13.9 Side Effects of GET and HEAD (Effetti Collaterali di GET e HEAD)​

A meno che il server di origine non proibisca esplicitamente il caching della risposta, le applicazioni dei metodi GET e HEAD non dovrebbero (SHOULD) avere effetti collaterali.

13.10 Invalidation After Updates or Deletions (Invalidazione Dopo Aggiornamenti o Cancellazioni)​

L'esecuzione riuscita di un metodo che cambierebbe lo stato (POST, PUT, DELETE) deve invalidare tutte le voci di cache per la risorsa identificata da quel Request-URI.

13.11 Write-Through Mandatory (Scrittura Diretta Obbligatoria)​

Tutti i metodi che risultano in una modifica di risorsa sul server di origine devono (MUST) scrivere attraverso il server di origine. La specifica corrente non definisce alcun modo per memorizzare nella cache tali risposte altrove.

13.12 Cache Replacement (Sostituzione della Cache)​

Se una cache riceve una risposta che comporterebbe la sostituzione di una voce con una voce più recente e la vecchia voce contiene direttive Cache-Control, la cache dovrebbe (SHOULD) rispettare tali direttive.

13.13 History Lists (Elenchi Storici)​

Gli user agent tipicamente hanno meccanismi di cronologia, come un pulsante "Indietro" e un elenco storico, che possono essere utilizzati per visualizzare nuovamente rappresentazioni recuperate in precedenza nella sessione dell'utente.

Requisiti del meccanismo di cronologia:

  1. Il meccanismo di cronologia dovrebbe (SHOULD) visualizzare le risorse recuperate in precedenza secondo le preferenze dell'utente
  2. Il meccanismo di cronologia non dovrebbe (SHOULD NOT) tentare di validare le risorse
  3. Il meccanismo di cronologia dovrebbe (SHOULD) visualizzare le rappresentazioni recuperate in precedenza, anche se ora sono scadute

Nota importante: Questo capitolo descrive in dettaglio i meccanismi di caching HTTP/1.1, inclusi il modello di scadenza, il modello di validazione, il controllo della cache e altri concetti fondamentali. Il caching è un meccanismo chiave per migliorare le prestazioni HTTP, e la comprensione di questi concetti è essenziale per costruire applicazioni Web ad alte prestazioni.

Ultimo aggiornamento il