Share via

Funzionamento della memorizzazione nella cache

  • Articolo

Questo articolo offre una panoramica dei concetti generali relativi alla memorizzazione nella cache e del modo in cui Azure rete per la distribuzione di contenuti 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 di Azure rete per la distribuzione di contenuti con regole di memorizzazione nella cache e Controllare il comportamento di memorizzazione nella cache di Azure rete per la distribuzione di contenuti 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.

Le risorse dinamiche che cambiano frequentemente o sono univoche per un singolo utente non possono essere memorizzate nella cache. Questi tipi di risorse, tuttavia, possono sfruttare i vantaggi dell'ottimizzazione DSA (Dynamic Site Acceleration) 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

Poiché una risorsa memorizzata nella cache può essere potenzialmente non aggiornata o non aggiornata (rispetto alla risorsa corrispondente nel server di origine), è importante che qualsiasi meccanismo di memorizzazione nella cache controlli quando il contenuto ottiene un aggiornamento. 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 (non aggiornata), viene caricata una copia aggiornata dal server.

Convalida

Se una risorsa è considerata non aggiornata, al server di origine viene chiesto di convalidarlo per determinare se i dati nella cache corrispondono ancora a ciò che si trova 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 posizionati in modo strategico che sono più locali per un utente e offrono i vantaggi seguenti:

  • Poiché la maggior parte del traffico Web è statica (ad esempio immagini, tipi di carattere e video), la memorizzazione nella cache della rete per la distribuzione di contenuti riduce la latenza di rete spostando il contenuto più vicino all'utente, riducendo così la distanza che i dati viaggiano.

  • Eseguendo l'offload del lavoro in una rete per la distribuzione di contenuti, la memorizzazione nella cache può ridurre il traffico di rete e il carico sul 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.

Analogamente alla modalità di implementazione della memorizzazione nella cache in un Web browser, è possibile controllare come viene eseguita la memorizzazione nella cache in una rete per la distribuzione di contenuti inviando intestazioni di direttiva cache. Le intestazioni di direttive di memorizzazione nella cache sono intestazioni HTTP, in genere aggiunte dal server di origine. Sebbene la maggior parte di queste intestazioni sia stata originariamente progettata per gestire la memorizzazione nella cache nei browser client, ora vengono usate anche da tutte le cache intermedie, ad esempio le reti di distribuzione di 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

Importante

Per impostazione predefinita, un endpoint rete per la distribuzione di contenuti di Azure ottimizzato per DSA ignora le intestazioni della direttiva della cache e ignora la memorizzazione nella cache. Per Rete CDN di Azure standard dei profili Edgio, è possibile modificare il modo in cui un endpoint di Azure rete per la distribuzione di contenuti gestisce queste intestazioni usando le regole di memorizzazione nella cache della rete per la distribuzione di contenuti per abilitare la memorizzazione nella cache. Per Rete CDN di Azure solo i profili Premium di Edgio, si usa il motore regole per abilitare la memorizzazione nella cache.

Azure rete per la distribuzione di contenuti supporta le intestazioni di direttiva cache HTTP seguenti, che definiscono la durata della cache 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 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:
    • Rete CDN di Azure Standard/Premium di Edgio e Rete CDN di Azure Standard di Microsoft supportano tutte le Cache-Control direttive.
    • Rete CDN di Azure Standard/Premium di Edgio e Rete CDN di Azure Standard di Microsoft rispetta i comportamenti di memorizzazione nella cache per le direttive Cache-Control in RFC 7234 - Hypertext Transfer Protocol (HTTP/1.1): Caching (ietf.org).

Expires:

  • Intestazione legacy introdotta in HTTP 1.0; supportato per la compatibilità con le versioni precedenti.
  • 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 da Azure rete per la distribuzione di contenuti, per impostazione predefinita.
  • Intestazione legacy introdotta in HTTP 1.0; supportato per la compatibilità con le versioni precedenti.
  • 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. Rete CDN di Azure Standard/Premium di Edgio supporta sia ETag che Last-Modified validator per impostazione predefinita, mentre Rete CDN di Azure Standard di Microsoft supporta solo Last-Modified.

ETag:

  • Rete CDN di Azure Standard/Premium di Edgio supporta ETag per impostazione predefinita, mentre Rete CDN di Azure Standard 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; Tuttavia, Azure rete per la distribuzione di contenuti supporta 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 ETag validator nell'elenco, 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:

  • Per Rete CDN di Azure solo Standard/Premium di Edgio, Last-Modified viene 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.
  • 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 dall'ora specificata, 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. Le risorse recapitate con risposte HTTP che non soddisfano tutte queste condizioni non possono essere memorizzate nella cache. Solo per Rete CDN di Azure Premium di Edgio, è possibile usare il motore regole per personalizzare alcune di queste condizioni.

Azure rete per la distribuzione di contenuti da Microsoft Azure rete per la distribuzione di contenuti da Edgio
Codici di stato HTTP 200, 203, 206, 300, 301, 410, 416 200
Metodi HTTP GET, HEAD GET
Limiti delle dimensioni dei file 300 GB 300 GB

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 ricevesse una richiesta GET.

Comportamento predefinito di memorizzazione nella cache

La tabella seguente descrive il comportamento di memorizzazione nella cache predefinito per i prodotti azure rete per la distribuzione di contenuti e le relative ottimizzazioni.

Microsoft: distribuzione Web generale Edgio: Distribuzione Web generale Edgio: DSA
Rispetta intestazioni origine Sì Sì No
durata della cache di rete per la distribuzione di contenuti Due giorni Sette giorni None

Rispetta l'origine: specifica se rispettare le intestazioni della direttiva cache supportate, se presenti nella risposta HTTP dal server di origine.

rete CDN durata della cache: specifica la quantità di tempo per cui una risorsa viene memorizzata nella cache nella rete per la distribuzione di contenuti di Azure. Tuttavia, se l'origine Honor è Sì e la risposta HTTP dal server di origine include l'intestazione Expires della direttiva cache o Cache-Control: max-age, Azure rete per la distribuzione di contenuti usa invece il valore di durata specificato dall'intestazione.

Nota

Azure rete per la distribuzione di contenuti non garantisce la quantità minima di tempo in cui l'oggetto verrà archiviato nella cache. Il contenuto memorizzato nella cache potrebbe essere rimosso dalla cache della rete per la distribuzione di contenuti prima della scadenza se il contenuto non viene richiesto con frequenza per liberare spazio per i contenuti richiesti più frequentemente.

Passaggi successivi