Ottimizzazione delle prestazioni con le regole CDN

Il motore di regole di Azure Front Door (chiamato Rule sets in Standard/Premium) consente di intercettare e modificare le richieste e le risposte HTTP presso il PoP edge prima che vengano memorizzate nella cache o inoltrate all'origine. Senza un motore di regole, sarebbe necessario gestire attività come i reindirizzamenti da HTTP a HTTPS, le intestazioni di risposta di sicurezza e il blocco geografico all'interno del codice dell'applicazione nell'origine, aumentando la latenza e collegando gli aspetti di sicurezza alla logica di business. Le regole eseguite all'edge sono più rapide e riducono il carico sull'origine.

Uno dei casi d'uso più comuni del motore di regole è imporre l'uso di HTTPS. Quando un client richiede il sito tramite HTTP, una regola di reindirizzamento presso l'edge di Front Door restituisce immediatamente una risposta 301 Moved Permanently (o 302 Found) che punta all'URL HTTPS, senza che la richiesta raggiunga l'origine. Questo è più veloce dei reindirizzamenti gestiti dall'origine e garantisce che tutto il traffico sia crittografato durante il transito. Configuratelo come azione di reindirizzamento per le richieste in cui la condizione RequestScheme è uguale a HTTP.

I browser moderni supportano intestazioni HTTP di sicurezza che prevengono gli attacchi comuni. È possibile aggiungere queste intestazioni a tutte le risposte usando le azioni Append response header del motore di regole, senza modificare il server di origine. Tra le intestazioni principali figurano: Strict-Transport-Security (impone HTTPS per un determinato periodo), X-Content-Type-Options: nosniff (impedisce il MIME sniffing), X-Frame-Options: DENY (previene il clickjacking) e Content-Security-Policy (limita le origini dei contenuti). L'aggiunta di queste intestazioni all'edge garantisce un'applicazione uniforme a tutte le origini.

Il motore di regole consente di sostituire il TTL predefinito della cache per schemi URL specifici. Ad esempio, si potrebbe voler memorizzare nella cache /static/images/* per 30 giorni, ma conservare nella cache le risposte di /api/* solo per 60 secondi. Usate una condizione di corrispondenza su RequestUri e un'azione Route configuration override che imposti una durata personalizzata della cache. In questo modo è possibile controllare in modo dettagliato la cache senza creare più route separate per ogni tipo di contenuto.

Le azioni di riscrittura degli URL modificano l'URL della richiesta prima che venga inoltrata all'origine, senza cambiare l'URL visualizzato dal client. Questa funzionalità è utile per inviare le richieste da una struttura URL a un percorso diverso nel backend. Ad esempio, è possibile riscrivere /products/item/{id} in /catalog/v2/products/{id} per adattarsi a una modifica dell'API backend senza aggiornare i collegamenti nei client. La riscrittura degli URL è un'azione del motore di regole che modifica il URL path usando la sostituzione di stringhe o i gruppi di cattura.

Il filtraggio geografico a livello del motore di regole consente di reindirizzare o bloccare gli utenti di determinati Paesi in base alla geolocalizzazione derivata dall'indirizzo IP del client. A differenza del filtraggio geografico del CDN (che restituisce 403), il filtraggio geografico del motore di regole offre maggiore flessibilità: è possibile reindirizzare i Paesi bloccati a una landing page che spiega la disponibilità regionale oppure indirizzare determinati Paesi a gruppi di origini specifici per area geografica (ad esempio, gli utenti dell'UE verso origini nell'UE per la conformità al GDPR). La corrispondenza geografica RemoteAddress usa il database IP-paese di MaxMind.

Il motore di regole può aggiungere, sovrascrivere o eliminare le intestazioni della richiesta prima di inoltrarla all'origine. Un uso comune consiste nell'aggiungere X-Forwarded-For o un'intestazione personalizzata come X-Front-Door-Id, così l'origine sa che le richieste sono passate da Front Door e può verificarle. È anche possibile eliminare l'intestazione Host originale e sostituirla con il nome host dell'origine, un'operazione importante quando l'origine convalida l'intestazione Host. In questo modo avete il pieno controllo su ciò che il server di origine visualizza.

Le condizioni del motore di regole possono confrontare i valori delle intestazioni della richiesta, consentendo una logica di routing sofisticata. Ad esempio, è possibile indirizzare le richieste che contengono l'intestazione X-API-Version: 2 a un gruppo di origini diverso che esegue l'API v2, mentre le richieste senza tale intestazione vengono indirizzate all'origine v1. Questo consente di gestire il versioning blue-green delle API all'edge senza richiedere nomi host separati per ogni versione dell'API. Il routing basato sulle intestazioni viene usato anche per i test A/B, indirizzando il traffico in base a un cookie personalizzato di segmentazione degli utenti.

La compressione delle risposte in Front Door comprime le risposte basate su testo (HTML, CSS, JavaScript, JSON) usando gzip o Brotli prima di servirle dai PoP. La compressione è particolarmente efficace per i bundle JavaScript di grandi dimensioni, di cui può ridurre la dimensione di trasferimento fino al 70%. Abilitate la compressione nelle impostazioni della route e specificate i tipi MIME da comprimere. Il contenuto compresso viene memorizzato nella cache del PoP in forma compressa: solo la prima richiesta per ogni risorsa attiva la compressione; le richieste successive ricevono immediatamente il file compresso memorizzato nella cache.

Origin Shield è un ulteriore livello di memorizzazione nella cache facoltativo che Front Door colloca tra i nodi edge dei PoP e l'origine. Quando è abilitato, invece di richiedere indipendentemente contenuti non memorizzati nella cache all'origine, ciascuno degli oltre 100 PoP edge inoltra le mancate corrispondenze della cache a un singolo PoP regionale Origin Shield, che le inoltra poi all'origine. Questo riduce significativamente il numero di richieste che raggiungono l'origine (il cosiddetto rapporto di offload dell'origine), continuando a servire i contenuti a livello globale dai PoP edge.

Prima di distribuire in produzione le modifiche al motore di regole, convalidatele usando gli strumenti di diagnostica e test del portale. Il pannello Diagnostic settings, insieme ai log WAF in modalità di rilevamento, mostra quali regole corrispondono. Per il motore di regole è inoltre possibile esaminare le intestazioni effettive delle richieste e delle risposte negli strumenti per sviluppatori del browser dopo la distribuzione in un ambiente di staging, oppure usare curl -v per inviare richieste specifiche e verificare che le intestazioni della risposta e il comportamento dei reindirizzamenti siano quelli previsti prima del passaggio alla produzione.

Verificate la vostra comprensione dei concetti di Microsoft Azure Fundamentals (AZ-900) illustrati in questa lezione.

In questa lezione avete appreso che il motore di regole di Front Door gestisce all'edge i reindirizzamenti da HTTP a HTTPS, le intestazioni di risposta di sicurezza e le sostituzioni del TTL della cache senza modifiche all'origine; la riscrittura degli URL modifica in modo trasparente i percorsi delle richieste inoltrate all'origine, mentre il reindirizzamento degli URL modifica l'URL visualizzato dal client; infine, Origin Shield riduce il carico sull'origine consolidando le richieste per le mancate corrispondenze della cache attraverso un nodo shield regionale. Nella prossima lezione esploreremo Azure AI Services per aggiungere funzionalità intelligenti alle vostre applicazioni.