Memorizzazione nella cache con Frontdoor di Azure

  • Articolo

Importante

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

Frontdoor di Azure è una rete per la distribuzione di contenuti moderna (CDN), con funzionalità di accelerazione del sito e bilanciamento del carico dinamiche. 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 nessuna risposta per la memorizzazione della 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. Allo stesso modo, per evitare la perdita di informazioni personali, è consigliabile non memorizzare nella cache asset dinamici come gli endpoint API autenticati. È consigliabile avere route separate per asset statici e dinamici, disabilitando la memorizzazione nella cache per questi ultimi.

Avviso

Prima di abilitare la memorizzazione nella cache, esaminare attentamente la documentazione pubblica e testare tutti gli scenari possibili. Come indicato in precedenza, a causa di una configurazione errata si rischia di memorizzare nella cache i dati specifici degli utenti e di condividerli con altri utenti, risultando in problemi di privacy.

Metodi di richiesta

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

Recapito di file di grandi dimensioni

Frontdoor di Azure recapita i file di grandi dimensioni senza limiti sulle dimensioni del file. Se il caching è abilitato, Frontdoor di Azure usa una tecnica chiamata suddivisione degli oggetti in blocchi. Quando viene richiesto un file di grandi dimensioni, Frontdoor recupera piccole parti del file dall’origine. Dopo che Frontdoor ha ricevuto una richiesta di file completo o con intervallo di byte, un ambiente Frontdoor di Azure richiede il file dall’origine in blocchi da 8 MB.

Quando il blocco arriva all'ambiente Frontdoor di Azure, viene memorizzato nella cache e reso immediatamente disponibile all'utente. Frontdoor esegue la 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 alla loro ricezione e pertanto l'intero file non deve essere memorizzato nella cache di Frontdoor. Le richieste successive del file o di intervalli di byte vengono soddisfatte dalla cache. Se non tutti i blocchi vengono memorizzati nella cache, viene usata la prelettura per richiedere i blocchi dall’origine.

Questa ottimizzazione presuppone il fatto che il server di origine sia in grado di supportare le richieste di intervalli 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 utilizzare il codice di stato HTTP 206. Inoltre, l'intestazione della risposta Content-Range 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 la risposta nella cache e potrebbe verificarsi un comportamento incoerente.

    Suggerimento

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

  • Restituisce una risposta senza intervallo. Se l'origine non riesce a 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

Consultare Migliorare le prestazioni con la compressione dei file in Frontdoor di Azure.

Frontdoor di Azure (versione classica) comprime in modo dinamico il contenuto sull'edge, offrendo così una risposta più rapida ai client. Affinché un file sia idoneo per la compressione, è necessario abilitare il caching e il file deve essere di un tipo MIME idoneo per la compressione. Attualmente Frontdoor (versione classica) non supporta modifiche a 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 per una risorsa indica la compressione e i risultati della richiesta non sono presenti nella cache, Frontdoor di Azure (versione classica) esegue la compressione della risorsa direttamente nel server POP. In seguito, il file compresso viene gestito nella cache. L'elemento risultante viene restituito con un’intestazione della risposta Transfer-Encoding: chunked.

Se l'origine usa la codifica CTE (Chunked Transfer Encoding) per inviare dati al POP di Frontdoor di Azure, allora 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 o 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

Frontdoor di Azure consente di controllare la modalità di memorizzazione nella cache dei file per una richiesta Web contenente una stringa di query.

In una richiesta Web con una stringa di query, la stringa di query è la parte della richiesta che si verifica dopo un punto di domanda (?). 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 il due stringhe di query:

  • field1, con un valore di value1.
  • field2, con un valore di value2.

Se è presente più di una coppia chiave-valore in una stringa di query di una richiesta, allora l'ordine non ha importanza.

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 la stringa di query dal client all’origine alla prima richiesta ed esegue la memorizzazione nella cache dell'asset. Le richieste successive dell'asset gestite dall'ambiente Frontdoor ignoreranno le stringhe di query finché l'asset memorizzato nella cache non sarà scaduto.

  • Usa stringa di query: in questa modalità ogni richiesta con URL univoco, compresa la stringa di query, viene considerata un asset univoco con la propria cache. Ad esempio, la risposta inviata dall’origine per una richiesta di www.example.ashx?q=test1 viene memorizzata nella cache nell'ambiente Frontdoor e restituita per le memorizzazioni nella cache successive 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 fornita anche una richiesta di www.example.ashx?r=test2&q=test1 dalla 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.

    Ad esempio, supponiamo che la chiave della cache predefinita sia /foo/image/asset.html e 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 stringa di query userid, la chiave della cache della stringa 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. Ciò potrebbe essere dovuto agli aggiornamenti all'applicazione Web o a un aggiornamento rapido di asset che contengono informazioni non corrette.

Screenshot del pulsante di pulizia della cache e della pagina.

Selezionare gli asset che si desidera rimuovere dai nodi periferici. Per cancellare tutti gli asset, selezionare Rimuovi tutto. In caso contrario, in Percorso, immettere il percorso di ogni asset da eliminare.

Questi formati sono supportati negli elenchi di percorsi da rimuovere:

  • Eliminazione del percorso singolo: eliminazione di singoli asset specificando il percorso completo dell’asset (senza il protocollo e il dominio), con o senza l'estensione di file, ad esempio /pictures/strasbourg.png;
  • Rimozione caratteri jolly: l'asterisco (*) può essere usato come carattere jolly. Consente di ripulire tutte le cartelle, le sottocartelle e i file in un endpoint inserendo /* nel percorso o di eliminare tutte le sottocartelle e i file in una determinata cartella 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 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, l'eliminazione diretta dei domini con caratteri jolly non è supportata. È possibile eliminare i percorsi da sottodomini specifici specificando tale sottodominio specifico e il percorso di eliminazione. Ad esempio, se Frontdoor ha *.contoso.com, è possibile rimuovere gli asset del sottodominio foo.contoso.com digitando foo.contoso.com/path/*. Al momento 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, risultano indipendenti dalla stringa di query, vale a dire che l'eliminazione di un URL eliminerà tutte le variazioni delle stringhe di query.

Ora di scadenza della cache

L'ordine delle intestazioni seguente viene usato per determinare quanto tempo un elemento rimane memorizzato nella cache:

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

Alcuni valori dell’intestazione della risposta Cache-Control indicando che non è possibile memorizzare la risposta nella cache. Questo valori includono private, no-cache e 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.

È possibile visualizzare REVALIDATED_HIT nell'intestazione della risposta Cache-Control. 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

Nota

Le richieste che includono l'intestazione di autorizzazione non verranno memorizzate nella cache, a meno che la risposta non contenga una direttiva Cache-Control che consenta la memorizzazione nella cache. Le direttive Cache-Control seguenti hanno tale effetto: must-revalidate, public e s-maxage.

Intestazioni della risposta

Se non è possibile memorizzare nella cache la risposta di origine, allora l’intestazione Set-Cookie viene rimossa prima che la risposta venga inviata 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 valore max-age 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 della risposta X-Cache 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 gestito 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’origione.
  • PRIVATE_NOSTORE: la richiesta non può essere memorizzata nella cache perché l'intestazione di risposta controllo cache è impostata su privato o nessun archivio.
  • 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. Inoltre, i report includono 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’origione: 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.
    • Esegui sempre l’override: Frontdoor di Azure esegue sempre l'override con la 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.
    • Esegui 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 delle specifiche risposte utilizzando l’intestazione Cache-Control con un valore di no-cache, privato o no-store. Quando viene usata in una risposta HTTP dal server di origine ai POP Frontdoor di Azure, Frontdoor di Azure supporta le direttive di Cache-Control e rispetta i comportamenti di caching 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 gestione 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 gestione del designer 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 valori diversi di Usare la durata predefinita della cache.

    • Quando Usa durata predefinita della cache è impostata su Sì, Frontdoor di Azure (versione classica) rispetta sempre la direttiva di intestazione della risposta di origine. Se manca la direttiva di origine, Frontdoor memorizza nella cache il contenuto da uno a tre giorni.
    • Quando Usa durata predefinita della cache è impostato su No, Frontdoor di Azure (versione classica) esegue sempre l'override con la durata della cache, 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 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 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. Questo override non funzionerà se l'intestazione del controllo cache dell'origine ha un valore TTL maggiore del valore di override.

Passaggi successivi