Funzionamento della memorizzazione nella cache

Questo articolo offre una panoramica dei concetti generali di memorizzazione nella cache e illustra il modo in cui la rete per la distribuzione di contenuti di Azure usa la memorizzazione nella cache per migliorare le prestazioni. Per informazioni su come personalizzare il comportamento di memorizzazione nella cache nell'endpoint di rete per la distribuzione di contenuti, vedere Controllare il comportamento di memorizzazione nella cache della rete per la distribuzione di contenuti di Azure con regole di memorizzazione nella cache e Controllare il comportamento di memorizzazione nella cache della rete per la distribuzione di contenuti di Azure con stringhe di query.

Introduzione alla memorizzazione nella cache

La memorizzazione nella cache è il processo di archiviazione dei dati in locale per poter accedere più rapidamente alle future richieste relative ai dati. Nel tipo più comune di memorizzazione nella cache, ovvero la memorizzazione nella cache del Web browser, un Web browser archivia copie di dati statici in locale su un disco rigido. Grazie alla memorizzazione nella cache, il Web browser può evitare l'esecuzione di più round trip con il server e accedere invece agli stessi dati in locale, risparmiando tempo e risorse. La memorizzazione nella cache è particolarmente adatta per la gestione locale di dati statici di piccole dimensioni, ad esempio immagini statiche, file CSS e file JavaScript.

Analogamente, la memorizzazione nella cache viene usata da una rete per la distribuzione di contenuti nei server perimetrali vicini all'utente per evitare che le richieste tornino all'origine e riducendo così la latenza per l'utente finale. A differenza di una cache del Web browser, usata solo per un singolo utente, la rete per la distribuzione di contenuti ha una cache condivisa. In una cache condivisa della rete per la distribuzione di contenuti, una richiesta di file da parte di un utente può essere usata da un altro utente, riducendo notevolmente il numero di richieste al server di origine.

Non è possibile memorizzare nella cache le risorse dinamiche che cambiano di frequente o che sono univoche per un singolo utente. Questi tipi di risorse possono tuttavia sfruttare l'ottimizzazione 'Accelerazione sito dinamico' nella rete per la distribuzione di contenuti di Azure per migliorare le prestazioni.

La memorizzazione nella cache può essere eseguita a più livelli tra il server di origine e l'utente finale:

• Server Web: usa una cache condivisa (per più utenti).
• Rete per la distribuzione di contenuti: usa una cache condivisa (per più utenti).
• Provider di servizi Internet (ISP): usa una cache condivisa (per più utenti).
• Web browser: usa una cache privata (per un solo utente).

Ogni cache gestisce in genere il proprio aggiornamento delle risorse ed esegue la convalida quando un file non è aggiornato. Questo comportamento viene definito nella specifica di memorizzazione nella cache HTTP, RFC 7234.

Aggiornamento delle risorse

Dato che una risorsa memorizzata nella cache può essere potenzialmente non aggiornata rispetto alla risorsa corrispondente nel server di origine, è importante che qualsiasi meccanismo di memorizzazione nella cache abbia il controllo della tempistica di aggiornamento del contenuto. Per risparmiare tempo e consumo di larghezza di banda, una risorsa memorizzata nella cache non viene confrontata con la versione nel server di origine ogni volta che vi si accede. Al contrario, purché una risorsa memorizzata nella cache venga considerata aggiornata, si presuppone che sia la versione più recente e viene inviata direttamente al client. Una risorsa memorizzata nella cache viene considerata nuova quando l'età è inferiore all'età o al periodo definito da un'impostazione della cache. Quando ad esempio ricarica una pagina Web, un browser verifica che ogni risorsa memorizzata nella cache nel disco rigido sia aggiornata e la carica. Se la risorsa non è aggiornata, viene caricata una copia aggiornata dal server.

Convalida

Se una risorsa è considerata non aggiornata, viene chiesto al server di origine di convalidarla per determinare se i dati presenti nella cache corrispondono ancora ai dati presenti nel server di origine. Se il file è stato modificato nel server di origine, la cache aggiorna la propria versione della risorsa. Se invece la risorsa è aggiornata, i dati vengono inviati direttamente dalla cache, senza prima convalidarli.

Memorizzazione nella cache della rete per la distribuzione di contenuti

La memorizzazione nella cache è fondamentale per il funzionamento di una rete per la distribuzione di contenuti per velocizzare il recapito e ridurre il carico di origine per asset statici, ad esempio immagini, tipi di carattere e video. Nella memorizzazione nella cache della rete per la distribuzione di contenuti, le risorse statiche vengono archiviate in modo selettivo in server strategici più vicini a un utente, offrendo i vantaggi seguenti:

• Poiché la maggior parte del traffico Web è statico (ad esempio immagini, tipi di carattere e video), la memorizzazione nella cache della rete di distribuzione dei contenuti di Microsoft Azure riduce la latenza di rete avvicinando il contenuto all'utente, riducendo così la distanza percorsa dai dati.

• Grazie all'offload del lavoro in una rete di distribuzione dei contenuti di Microsoft Azure, la memorizzazione nella cache consente di ridurre il traffico di rete e il carico nel server di origine. È così possibile ridurre i costi e i requisiti in termini di risorse per l'applicazione, anche in presenza di un numero elevato di utenti.

In modo simile a come la memorizzazione nella cache è implementata in un Web browser, è possibile definire come viene eseguita la memorizzazione nella cache della rete di distribuzione dei contenuti di Microsoft Azure inviando intestazioni di direttive di memorizzazione nella cache. Le intestazioni di direttive di memorizzazione nella cache sono intestazioni HTTP, in genere aggiunte dal server di origine. Anche se la maggior parte di queste intestazioni è stata originariamente progettata per la memorizzazione nella cache nei browser client, le intestazioni vengono ora usate anche da tutte le cache intermedie, ad esempio le reti di distribuzione dei contenuti.

È possibile usare due intestazioni per definire l'aggiornamento della cache: Cache-Control e Expires. Cache-Control è più recente e ha la precedenza su Expires, in presenza di entrambe. Esistono inoltre due tipi di intestazioni usate per la convalida (denominati validator): ETag e Last-Modified. ETag è più recente e ha la precedenza su Last-Modified, se sono definite entrambe.

Intestazioni di direttive della cache

La rete di distribuzione dei contenuti di Azure supporta le seguenti intestazioni di direttive della cache HTTP, che definiscono la durata e la condivisione della cache.

Cache-Control:

• Introdotta nella specifica HTTP 1.1 per superare le limitazioni dell'intestazione Expires e per offrire un maggiore controllo sui contenuti nella pubblicazione di contenuti Web.
• Ha la precedenza sull'intestazione Expires, se questa è definita insieme all'intestazione Cache-Control.
• Se usato in una richiesta HTTP dal client al POP della rete per la distribuzione di contenuti, Cache-Control viene ignorato da tutti i profili della rete per la distribuzione di contenuti di Azure, per impostazione predefinita.
• Se usato in una risposta HTTP dal server di origine al POP della rete per la distribuzione di contenuti:
  • La rete CDN Standard/Premium di Azure con tecnologia Edgio e la rete CDN Standard di Azure con tecnologia Microsoft supportano tutte le direttive Cache-Control.
  • La rete CDN Standard/Premium di Azure di Edgio e la rete CDN Standard di Azure di Microsoft rispetta i comportamenti di memorizzazione nella cache per le direttive di controllo della cache in RFC 7234 - Hypertext Transfer Protocol (HTTP/1.1): caching (ietf.org).

Expires:

• Intestazione legacy introdotta in HTTP 1.0; supportata per la compatibilità con la versione precedente.
• Usa una scadenza basata sulla data con precisione al secondo.
• Simile a Cache-Control: max-age.
• Usata quando Cache-Control non esiste.

Pragma:

• Non rispettato dalla rete per la distribuzione di contenuti di Azure, per impostazione predefinita.
• Intestazione legacy introdotta in HTTP 1.0; supportata per la compatibilità con la versione precedente.
• Usata come intestazione della richiesta client con la direttiva seguente: no-cache. Questa direttiva indica al server di distribuire una versione aggiornata della risorsa.
• Pragma: no-cache è pari a Cache-Control: no-cache.

Validator

Quando la cache non è aggiornata, vengono usati validator della cache HTTP per confrontare la versione di un file memorizzata nella cache con la versione presente nel server di origine. La rete CDN Standard/Premium di Azure di Edgio supporta entrambi i validator ETag e Last-Modified per impostazione predefinita, mentre la rete CDN Standard di Azure fornita da Microsoft supporta solo Last-Modified.

ETag:

• La rete CDN Standard/Premium di Azure fornita da Edgio supporta ETag per impostazione predefinita, mentre la rete CDN Standard di Azure di Microsoft non lo supporta.
• ETag definisce una stringa univoca per ogni file e versione di un file, Ad esempio: ETag: "17f0ddd99ed5bbe4edffdd6496d7131f".
• Introdotta nella specifica HTTP 1.1 ed è più recente di Last-Modified. È utile quando è difficile determinare la data dell'ultima modifica.
• Supporta sia la convalida avanzata che la convalida debole. La rete di distribuzione dei contenuti di Azure supporta tuttavia solo la convalida avanzata. Per la convalida avanzata, le due rappresentazioni della risorsa devono essere identiche byte per byte.
• La cache convalida un file che usa ETag inviando un'intestazione If-None-Match con uno o più validator ETag nella richiesta, Ad esempio: If-None-Match: "17f0ddd99ed5bbe4edffdd6496d7131f". Se la versione del server corrisponde a un validator ETag nell'elenco, il server invia il codice di stato 304 (Non modificato) nella risposta. Se la versione è diversa, il server risponde con il codice di stato 200 (OK) e la risorsa aggiornata.

Last-Modified:

• Solo per la rete CDN Standard/Premium di Azure con tecnologia Edgio, Last-Modified è usato se ETag non fa parte della risposta HTTP.
• Specifica la data e ora dell'ultima modifica della risorsa secondo quanto determinato dal server, Ad esempio: Last-Modified: Thu, 19 Oct 2017 09:28:00 GMT.
• Per il contenuto superiore a 8 MB, i server back-end di origine devono mantenere timestamp Last-Modified coerenti per ogni asset. La restituzione di tempi Last-Modified incoerenti dai server back-end causerà errori di mancata corrispondenza del validator e genererà errori HTTP 5XX. Archiviazione di Azure potrebbe non supportare timestamp Last-Modified coerenti tra le repliche, che possono causare errori simili di mancata corrispondenza del validator.
• La cache convalida un file che usa Last-Modified inviando un'intestazione If-Modified-Since con la data e ora nella richiesta. Il server di origine confronta tale data con l'intestazione Last-Modified della risorsa più recente. Se la risorsa non è stata modificata dopo la data e ora specificate, il server restituisce il codice di stato 304 (Non modificato) nella risposta. Se la risorsa è stata modificata, il server restituisce il codice di stato 200 (OK) e la risorsa aggiornata.

Determinazione dei file che possono essere memorizzati nella cache

Non tutte le risorse possono essere memorizzate nella cache. La tabella seguente mostra le risorse che possono essere memorizzate nella cache, in base al tipo di risposta HTTP. Non è possibile memorizzare nella cache le risorse distribuite con risposte HTTP che non soddisfano tutte queste condizioni. Solo per la rete CDN Premium di Azure con tecnologia Edgio è possibile usare il motore regole per personalizzare alcune di queste condizioni.

Affinché la memorizzazione nella cache per la rete CDN Standard di Azure con tecnologia Microsoft funzioni su un asset, il server di origine deve supportare qualsiasi richiesta HEAD e HTTP GET e i valori di lunghezza del contenuto devono corrispondere per tutte le risposte HEAD e GET HTTP per l'asset. Per una richiesta HEAD, il server di origine deve supportare la richiesta HEAD e deve rispondere con le stesse intestazioni come se avesse ricevuto una richiesta GET.

Comportamento predefinito di memorizzazione nella cache

La tabella seguente descrive il comportamento predefinito di memorizzazione nella cache per i prodotti della rete di distribuzione dei contenuti di Microsoft Azure e le relative ottimizzazioni.

Honor origin (Rispetta intestazioni di origine): specifica se rispettare le intestazioni di direttive di memorizzazione nella cache supportate se presenti nella risposta HTTP del server di origine.

CDN cache duration (Durata cache rete CDN): specifica il tempo per il quale una risorsa rimane memorizzata nella cache della rete di distribuzione dei contenuti di Microsoft Azure. Se tuttavia Rispetta intestazioni origine è Sì e la risposta HTTP del server di origine include l'intestazione di direttive della cache Expires o Cache-Control: max-age, la rete di distribuzione dei contenuti di Microsoft Azure userà invece il valore della durata specificato dall'intestazione.

Passaggi successivi

• Per informazioni su come personalizzare ed eseguire l'override del comportamento di memorizzazione nella cache predefinito nella rete per la distribuzione di contenuti tramite regole di memorizzazione nella cache, vedere Controllare il comportamento di memorizzazione nella cache della rete per la distribuzione di contenuti di Azure con regole di memorizzazione nella cache.
• Per informazioni su come usare le stringhe di query per controllare il comportamento di memorizzazione nella cache, vedere Controllare il comportamento di memorizzazione nella cache della rete di distribuzione dei contenuti di Microsoft Azure con stringhe di query.