Memorizzazione nella cache con Frontdoor di Azure

  • Articolo

Importante

Frontdoor di Azure (versione classica) verrà ritirato il 31 marzo 2027. Per evitare interruzioni del servizio, è importante eseguire la migrazione dei profili frontdoor di Azure (versione classica) al livello Frontdoor di Azure Standard o Premium entro marzo 2027. Per altre informazioni, vedere Ritiro di Frontdoor di Azure (versione classica).

Frontdoor di Azure è una rete di distribuzione di contenuti moderna (rete CDN), con funzionalità di accelerazione del sito dinamico e bilanciamento del carico. Quando la memorizzazione nella cache è configurata nella route, il sito perimetrale che riceve ogni richiesta controlla la cache per ottenere una risposta valida. La memorizzazione nella cache consente di ridurre la quantità di traffico inviato al server di origine. Se non è disponibile alcuna risposta memorizzata nella cache, la richiesta viene inoltrata all'origine.

Ogni sito perimetrale di Frontdoor gestisce la propria cache e le richieste potrebbero essere gestite da siti perimetrali diversi. Di conseguenza, è possibile che il traffico raggiunga ancora l'origine, anche se sono state gestite risposte memorizzate nella cache.

La memorizzazione nella cache può ridurre significativamente la latenza e ridurre il carico nei server di origine. Tuttavia, non tutti i tipi di traffico possono trarre vantaggio dalla memorizzazione nella cache. Gli asset statici, ad esempio immagini, CSS e file JavaScript, sono ideali per la memorizzazione nella cache. Anche se gli asset dinamici, ad esempio gli endpoint API autenticati, non devono essere memorizzati nella cache per evitare la perdita di informazioni personali. È consigliabile avere route separate per asset statici e dinamici, con la memorizzazione nella cache disabilitata per quest'ultima.

Avviso

Prima di abilitare la memorizzazione nella cache, esaminare attentamente la documentazione pubblica e testare tutti gli scenari possibili prima di abilitare la memorizzazione nella cache. Come indicato in precedenza, con la configurazione errata è possibile memorizzare nella cache i dati specifici dell'utente che possono essere condivisi da più utenti che generano incidenti di privacy.

Metodi di richiesta

Solo le richieste che usano il GET metodo di richiesta sono memorizzabili nella cache. Tutti gli altri metodi di richiesta vengono sempre inoltrati tramite proxy attraverso la rete.

Recapito di file di grandi dimensioni

Frontdoor di Azure offre file di grandi dimensioni senza un limite per le dimensioni del file. Se la memorizzazione nella cache è abilitata, Frontdoor usa una tecnica denominata suddivisione in blocchi di oggetti. Quando viene richiesto un file di grandi dimensioni, Frontdoor recupera parti più piccole del file dall'origine. Dopo che Frontdoor riceve una richiesta file completa o una richiesta di file di intervallo di byte, l'ambiente Frontdoor richiede il file dall'origine in blocchi di 8 MB.

Dopo che il blocco arriva all'ambiente Frontdoor di Azure, viene memorizzato nella cache e immediatamente servito all'utente. Frontdoor esegue quindi il prelettura del blocco successivo in parallelo. Questa prelettura fa sì che il contenuto resti in anticipo di un blocco rispetto all'utente, riducendo la latenza. Questo processo continua fino a quando l'intero file viene scaricato (se richiesto) o il client chiude la connessione. Per altre informazioni sulla richiesta di intervalli di byte, vedere RFC 7233.

Frontdoor memorizza nella cache tutti i blocchi ricevuti in modo che l'intero file non debba essere memorizzato nella cache di Frontdoor. Le richieste successive del file o di intervalli di byte vengono soddisfatte dalla cache. Se i blocchi non sono tutti memorizzati nella cache, la prelettura viene usata per richiedere blocchi dall'origine.

Questa ottimizzazione si basa sulla capacità dell'origine di supportare le richieste di intervallo di byte. Se l'origine non supporta le richieste di intervallo di byte o se non gestisce correttamente le richieste di intervallo, questa ottimizzazione non è efficace.

Quando l'origine risponde a una richiesta con un'intestazione Range , deve rispondere in uno dei modi seguenti:

  • Restituisce una risposta con intervallo. La risposta deve usare il codice di stato HTTP 206. Inoltre, l'intestazione Content-Range della risposta deve essere presente e deve corrispondere alla lunghezza effettiva del contenuto restituito dall'origine. Se l'origine non invia le intestazioni di risposta corrette con valori validi, Frontdoor di Azure non memorizza nella cache la risposta e potrebbe verificarsi un comportamento incoerente.

    Suggerimento

    Se l'origine comprime la risposta, assicurarsi che il Content-Range valore dell'intestazione corrisponda alla lunghezza effettiva della risposta compressa.

  • Restituisce una risposta non a intervalli. Se l'origine non è in grado di gestire le richieste di intervallo, può ignorare l'intestazione Range e restituire una risposta non modificata. Assicurarsi che l'origine restituisca un codice di stato della risposta diverso da 206. Ad esempio, l'origine potrebbe restituire una risposta 200 OK.

Se l'origine usa la codifica CTE (Chunked Transfer Encoding) per inviare dati al POP di Frontdoor di Azure, le dimensioni delle risposte superiori a 8 MB non sono supportate.

Compressione dei file

Per informazioni su come migliorare le prestazioni, comprimere i file in Frontdoor di Azure.

Frontdoor di Azure (versione classica) può comprimere dinamicamente il contenuto sul perimetro, con conseguente tempi di risposta più piccoli e veloci per i client. Affinché un file sia idoneo per la compressione, la memorizzazione nella cache deve essere abilitata e il file deve essere di un tipo MIME idoneo per la compressione. Attualmente, Frontdoor (versione classica) non consente di modificare questo elenco. L'elenco corrente consiste in:

  • "application/eot"
  • "application/font"
  • "application/font-sfnt"
  • application/javascript
  • "application/json"
  • "application/opentype"
  • "application/otf"
  • "application/pkcs7-mime"
  • "application/truetype"
  • "application/ttf",
  • "application/vnd.ms-fontobject"
  • "application/xhtml+xml"
  • "application/xml"
  • "application/xml+rss"
  • "application/x-font-opentype"
  • "application/x-font-truetype"
  • "application/x-font-ttf"
  • "application/x-httpd-cgi"
  • "application/x-mpegurl"
  • "application/x-opentype"
  • "application/x-otf"
  • "application/x-perl"
  • "application/x-ttf"
  • "application/x-javascript"
  • "font/eot"
  • "font/ttf"
  • "font/otf"
  • "font/opentype"
  • "image/svg+xml"
  • "text/css"
  • "text/csv"
  • "text/html"
  • "text/javascript"
  • "text/js", "text/plain"
  • "text/richtext"
  • "text/tab-separated-values"
  • "text/xml"
  • "text/x-script"
  • "text/x-component"
  • "text/x-java-source"

Inoltre, la dimensione del file deve essere compresa tra 1 KB e 8 MB.

Questi profili supportano le codifiche di compressione seguenti:

Se una richiesta supporta la compressione gzip e la compressione Brotli, la compressione Brotli ha la precedenza.

Quando una richiesta di un asset specifica la compressione e la richiesta genera un mancato riscontro nella cache, Frontdoor di Azure (versione classica) esegue la compressione dell'asset direttamente nel server POP. In seguito, il file compresso viene gestito nella cache. L'elemento risultante viene restituito con un'intestazione di Transfer-Encoding: chunked risposta.

Se l'origine usa la codifica CTE (Chunked Transfer Encoding) per inviare dati al POP di Frontdoor di Azure, la compressione non è supportata.

Nota

Le richieste di intervallo possono essere compresse in dimensioni diverse. Frontdoor di Azure richiede che i valori di lunghezza del contenuto siano uguali per qualsiasi richiesta HTTP GET. Se i client inviano richieste di intervallo di byte con l'intestazione Accept-Encoding che porta all'origine che risponde con lunghezze di contenuto diverse, Frontdoor di Azure restituirà un errore 503. È possibile disabilitare la compressione nell'origine oppure creare una regola del motore regole per rimuovere l'intestazione Accept-Encoding dalla richiesta di richieste di intervallo di byte.

Comportamento di memorizzazione della stringa di query

Con Frontdoor di Azure è possibile controllare il modo in cui i file vengono memorizzati nella cache per una richiesta Web contenente una stringa di query.

In una richiesta Web con una stringa di query, la stringa di query è quella parte della richiesta che si verifica dopo un punto interrogativo (?). Una stringa di query può contenere una o più coppie chiave-valore, in cui il nome del campo e il relativo valore sono separati da un segno di uguale (=). Ogni coppia chiave-valore è separata da una e commerciale (&).

Ad esempio, l'URL http://www.contoso.com/content.mov?field1=value1&field2=value2 contiene due stringhe di query:

  • field1, con il valore .value1
  • field2, con il valore .value2

Se in una stringa di query di una richiesta sono presenti più coppie chiave-valore, l'ordine non è rilevante.

Quando si configura la memorizzazione nella cache, specificare come la cache deve gestire le stringhe di query. Sono supportati i comportamenti seguenti:

  • Ignora stringa di query: in questa modalità Frontdoor di Azure passa le stringhe di query dal client all'origine nella prima richiesta e memorizza nella cache l'asset. Le richieste future per l'asset servito dall'ambiente Frontdoor ignorano le stringhe di query fino alla scadenza dell'asset memorizzato nella cache.

  • Usa stringa di query: in questa modalità, ogni richiesta con un URL univoco, inclusa la stringa di query, viene considerata come un asset univoco con la propria cache. Ad esempio, la risposta dall'origine di una richiesta per www.example.ashx?q=test1 viene memorizzata nella cache nell'ambiente Frontdoor e restituita per l'esecuzione di cache con la stessa stringa di query. Una richiesta di www.example.ashx?q=test2 viene memorizzata nella cache come asset separato con la propria impostazione di durata (TTL).

    L'ordine dei parametri della stringa di query non è rilevante. Ad esempio, se l'ambiente Frontdoor di Azure include una risposta memorizzata nella cache per l'URL www.example.ashx?q=test1&r=test2, viene servita anche una richiesta per www.example.ashx?r=test2&q=test1 la cache.

  • Ignora stringhe di query specificate e Includi stringhe di query specificate: in questa modalità è possibile configurare Frontdoor di Azure per includere o escludere parametri specificati quando viene generata la chiave della cache.

    Si supponga, ad esempio, che la chiave della cache predefinita sia /foo/image/asset.htmle che venga effettuata una richiesta all'URL https://contoso.com/foo/image/asset.html?language=EN&userid=100&sessionid=200. Se è presente una regola del motore regole per escludere il parametro della userid stringa di query, la chiave della cache delle stringhe di query sarà /foo/image/asset.html?language=EN&sessionid=200.

Configurare il comportamento della stringa di query nella route frontdoor.

Ripulire la cache

Per informazioni su come configurare l'eliminazione della cache, vedere Eliminazione della cache in Frontdoor di Azure.

Frontdoor di Azure memorizza nella cache gli asset fino alla scadenza della durata (TTL) dell'asset. Ogni volta che un client richiede un asset con TTL scaduto, l'ambiente Frontdoor recupera una nuova copia aggiornata dell'asset per gestire la richiesta e quindi archivia la cache aggiornata.

La procedura consigliata per assicurarsi che gli utenti ottengano sempre la copia più recente degli asset consiste nel versioning di questi ultimi per ogni aggiornamento e nella relativa pubblicazione come nuovi URL. Frontdoor recupera immediatamente i nuovi asset per le richieste client successive. A volte si desidera ripulire il contenuto memorizzato nella cache da tutti i nodi periodici e forzare il recupero dei nuovi asset aggiornati. Il motivo potrebbe essere dovuto agli aggiornamenti dell'applicazione Web o aggiornare rapidamente gli asset contenenti informazioni non corrette.

Screenshot del pulsante di eliminazione della cache e della pagina.

Selezionare gli asset da eliminare dai nodi perimetrali. Per cancellare tutti gli asset, selezionare Ripulisci tutto. In caso contrario, in Percorso immettere il percorso di ogni asset da ripulire.

Questi formati sono supportati negli elenchi di percorsi da eliminare:

  • Eliminazione del percorso singolo: ripulire i singoli asset specificando il percorso completo dell'asset (senza il protocollo e il dominio), con l'estensione del file, ad esempio /pictures/strasbourg.png;
  • Eliminazione di caratteri jolly: l'asterisco (*) può essere usato come carattere jolly. Eliminare tutte le cartelle, le sottocartelle e i file in un endpoint con /* nel percorso o eliminare tutte le sottocartelle e i file in una cartella specifica specificando la cartella seguita da /*, ad esempio /pictures/*.
  • Root domain purge: (Eliminazione del dominio radice) consente di eliminare la radice dell'endpoint inserendo "/" nel percorso.

Nota

Eliminazione dei domini con caratteri jolly: specificando i percorsi memorizzati nella cache per l'eliminazione, come descritto in questa sezione, non si applica ad alcun dominio con caratteri jolly associati a Frontdoor. Attualmente, non è supportato l'eliminazione diretta dei domini con caratteri jolly. È possibile eliminare i percorsi da sottodomini specifici specificando tale sottodominio specifico e il percorso di eliminazione. Ad esempio, se frontdoor ha *.contoso.com, è possibile ripulire gli asset del sottodominio foo.contoso.com digitando foo.contoso.com/path/*. Attualmente, la specifica dei nomi host nel percorso del contenuto di eliminazione è limitata ai sottodomini dei domini con caratteri jolly, se applicabile.

Le pulizie della cache su Frontdoor non fanno distinzione tra maiuscole e minuscole. Inoltre, sono indipendenti dalla stringa di query, il che significa che l'eliminazione di un URL elimina tutte le varianti della stringa di query.

Ora di scadenza della cache

L'ordine di intestazioni seguente viene usato per determinare per quanto tempo un elemento viene archiviato nella cache:

  1. Cache-Control: s-maxage=<seconds>
  2. Cache-Control: max-age=<seconds>
  3. Expires: <http-date>

Alcuni Cache-Control valori di intestazione della risposta indicano che la risposta non è memorizzabile nella cache. Questi valori includono private, no-cachee no-store. Frontdoor rispetta questi valori di intestazione e non memorizza nella cache le risposte, anche se si esegue l'override del comportamento di memorizzazione nella cache usando il motore regole.

Se l'intestazione Cache-Control non è presente nella risposta dall'origine, per impostazione predefinita Frontdoor determina in modo casuale una durata della cache compresa tra uno e tre giorni.

Nota

La scadenza della cache non può essere maggiore di 366 giorni.

L'intestazione della Cache-Control risposta potrebbe essere visualizzataREVALIDATED_HIT. Ciò indica che il contenuto memorizzato nella cache in Frontdoor di Azure è stato riconvalidato con il server di origine prima di essere servito al client. Ciò può verificarsi quando il contenuto memorizzato nella cache è scaduto, ma il server di origine indica che il contenuto non è stato modificato. In questo caso, il contenuto memorizzato nella cache viene servito al client e la scadenza della cache viene reimpostata.

Intestazioni delle richieste

Le intestazioni di richiesta seguenti non vengono inoltrate all'origine quando la memorizzazione nella cache è abilitata:

  • Content-Length
  • Transfer-Encoding
  • Accept
  • Accept-Charset
  • Accept-Language

Intestazioni della risposta

Se la risposta di origine è memorizzabile nella cache, l'intestazione viene rimossa prima dell'invio Set-Cookie della risposta al client. Se una risposta di origine non è memorizzabile nella cache, Frontdoor non rimuove l'intestazione. Ad esempio, se la risposta di origine include un'intestazione Cache-Control con un max-age valore indica a Frontdoor che la risposta è memorizzabile nella cache e l'intestazione Set-Cookie viene rimossa.

Inoltre, Frontdoor collega l'intestazione X-Cache a tutte le risposte. L'intestazione X-Cache della risposta include uno dei valori seguenti:

  • TCP_HIT o TCP_REMOTE_HIT: il primo blocco di 8 MB della risposta è un riscontro nella cache e il contenuto viene servito dalla cache di Frontdoor.
  • TCP_MISS: il primo blocco di 8 MB della risposta è un mancato riscontro nella cache e il contenuto viene recuperato dall'origine.
  • PRIVATE_NOSTORE: la richiesta non può essere memorizzata nella cache perché l'intestazione della risposta Cache-Control è impostata su private o no-store.
  • CONFIG_NOCACHE: la richiesta è configurata per non memorizzare nella cache nel profilo frontdoor.

Log e report

Il log di accesso include lo stato della cache per ogni richiesta. I report includono anche informazioni sull'uso della cache di Frontdoor di Azure nell'applicazione.

Il log di accesso include lo stato della cache per ogni richiesta.

Comportamento e durata della cache

Il comportamento e la durata della cache possono essere configurati nel motore regole. La configurazione della memorizzazione nella cache del motore regole sostituisce sempre la configurazione della route.

  • Quando la memorizzazione nella cache è disabilitata, Frontdoor di Azure non memorizza nella cache il contenuto della risposta, indipendentemente dalle direttive di risposta di origine.

  • Quando la memorizzazione nella cache è abilitata, il comportamento della cache è diverso a seconda del valore di comportamento della cache applicato dal motore regole:

    • Rispetta l'origine: Frontdoor di Azure rispetta sempre la direttiva di intestazione della risposta all'origine. Se manca la direttiva di origine, Frontdoor di Azure memorizza nella cache il contenuto da uno a tre giorni.
    • Eseguire l'override sempre: Frontdoor di Azure esegue sempre l'override della durata della cache, ovvero memorizza nella cache il contenuto per la durata della cache ignorando i valori dalle direttive di risposta di origine. Questo comportamento si applica solo se la risposta è memorizzabile nella cache.
    • Eseguire l'override se l'origine manca: se l'origine non restituisce i valori TTL di memorizzazione nella cache, Frontdoor di Azure usa la durata della cache specificata. Questo comportamento si applica solo se la risposta è memorizzabile nella cache.

Nota

  • Frontdoor di Azure non garantisce la quantità di tempo in cui il contenuto viene archiviato nella cache. Il contenuto memorizzato nella cache potrebbe essere rimosso dalla cache perimetrale prima della scadenza del contenuto se il contenuto non viene usato di frequente. Frontdoor potrebbe essere in grado di gestire i dati dalla cache anche se i dati memorizzati nella cache sono scaduti. Questo comportamento può aiutare il sito a rimanere parzialmente disponibile quando le origini sono offline.
  • Le origini possono specificare di non memorizzare nella cache risposte specifiche usando l'intestazione Cache-Control con il valore no-cache, private o no-store. Se usato in una risposta HTTP dal server di origine ai POP frontdoor di Azure, Frontdoor di Azure supporta le direttive di controllo della cache e rispetta i comportamenti di memorizzazione nella cache per le direttive cache-control in RFC 7234 - Hypertext Transfer Protocol (HTTP/1.1): Caching (ietf.org).

Il comportamento e la durata della cache possono essere configurati sia nella regola di routing della finestra di progettazione di Frontdoor che nel motore regole. La configurazione della memorizzazione nella cache del motore regole sostituisce sempre la configurazione della regola di routing della finestra di progettazione di Frontdoor.

  • Quando la memorizzazione nella cache è disabilitata, Frontdoor di Azure (versione classica) non memorizza nella cache il contenuto della risposta, indipendentemente dalle direttive di risposta di origine.

  • Quando la memorizzazione nella cache è abilitata, il comportamento della cache è diverso per i diversi valori di Durata predefinita della cache.

    • Quando la durata predefinita per l'uso della cache è impostata su Sì, Frontdoor di Azure (versione classica) rispetta sempre la direttiva di intestazione della risposta all'origine. Se manca la direttiva di origine, frontdoor memorizza nella cache il contenuto da uno a tre giorni.
    • Quando La durata predefinita della cache è impostata su No, Frontdoor di Azure (versione classica) esegue sempre l'override con la durata della cache (campi obbligatori), ovvero memorizza nella cache il contenuto per la durata della cache ignorando i valori dalle direttive di risposta di origine.

Nota

  • Frontdoor di Azure (versione classica) non garantisce la quantità di tempo di archiviazione del contenuto nella cache. Il contenuto memorizzato nella cache potrebbe essere rimosso dalla cache perimetrale prima della scadenza del contenuto se il contenuto non viene usato di frequente. Frontdoor di Azure (versione classica) potrebbe essere in grado di gestire i dati dalla cache anche se i dati memorizzati nella cache sono scaduti. Questo comportamento può aiutare il sito a rimanere parzialmente disponibile quando le origini sono offline.
  • La durata della cache impostata nella regola di routing della finestra di progettazione di Frontdoor è la durata minima della cache. Questa sostituzione non funzionerà se l'intestazione del controllo cache dell'origine ha un valore TTL maggiore del valore di override.

Passaggi successivi