Modalità di corrispondenza delle richieste con una configurazione di route
Una route in Frontdoor di Azure definisce il modo in cui il traffico viene gestito quando una richiesta in ingresso arriva al perimetro frontdoor di Azure. Le impostazioni di route stabiliscono un'associazione tra un dominio e un gruppo di origine. Usando funzionalità avanzate, ad esempio Pattern to Match e Rule set, è possibile avere un controllo granulare sul traffico verso le risorse back-end.
Nota
Quando si usano i set di regole di Frontdoor, è possibile configurare una regola per eseguire l'override del gruppo di origine per una richiesta. Il gruppo di origine impostato dal set di regole sostituisce il processo di routing descritto in questo 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).
Quando una richiesta arriva al perimetro frontdoor di Azure (versione classica), uno dei primi passaggi consiste nel determinare come instradare la richiesta corrispondente a una risorsa back-end e quindi eseguire un'azione definita nella configurazione di routing. Questo documento illustra in che modo Frontdoor determina la configurazione di route da usare durante l'elaborazione di una richiesta.
Struttura di una configurazione di routing di Frontdoor
Una regola di routing frontdoor è costituita da due parti principali: "lato sinistro" e "lato destro". Frontdoor corrisponde alla richiesta in ingresso sul lato sinistro della route, mentre il lato destro definisce la modalità di elaborazione della richiesta.
Corrispondenza in ingresso (lato sinistro)
Le proprietà seguenti determinano se la richiesta in ingresso corrisponde alla regola di routing (lato sinistro):
- Protocolli HTTP - HTTP o HTTPS
- Dominio : ad esempio: www.foo.com, *.bar.com
- Percorsi - Ad esempio: /*, /users/*, /file.gif
Queste proprietà vengono espanse internamente in modo che ogni combinazione di protocollo/dominio/percorso sia un potenziale set di corrispondenze.
Decisione di routing (lato destro)
La decisione su come elaborare la richiesta dipende dal fatto che la memorizzazione nella cache sia abilitata per la route. Se una risposta memorizzata nella cache non è disponibile, la richiesta viene inoltrata all'origine appropriata.
Corrispondenza route
Questa sezione illustra in che modo Frontdoor corrisponde alle richieste alle regole di routing. Il principio di base è che Frontdoor corrisponde sempre alla richiesta più specifica valutando le proprietà "lato sinistro": protocollo, dominio e percorso, in tale ordine.
Corrispondenza di host front-end
Frontdoor di Azure usa i passaggi seguenti per trovare le corrispondenze con gli host front-end:
- Verificare la presenza di route con una corrispondenza esatta nell'host front-end.
- Se non viene trovata alcuna corrispondenza esatta, la richiesta viene rifiutata con un errore 404: Richiesta non valida.
Le tabelle seguenti illustrano tre regole di routing diverse con i relativi host front-end e percorsi:
| Regola di routing | Host front-end | Percorso |
|---|---|---|
| Un | foo.contoso.com | /* |
| G | foo.contoso.com | /Gli utenti/* |
| A | www.fabrikam.com, foo.adventure-works.com | /*/Immagini/* |
La tabella seguente mostra i risultati corrispondenti per le regole di routing nella tabella precedente:
| Host front-end in ingresso | Regole di routing corrispondenti |
|---|---|
| foo.contoso.com | A, B |
| www.fabrikam.com | A |
| images.fabrikam.com | Errore 404: Richiesta non valida |
| foo.adventure-works.com | A |
| contoso.com | Errore 404: Richiesta non valida |
| www.adventure-works.com | Errore 404: Richiesta non valida |
| www.northwindtraders.com | Errore 404: Richiesta non valida |
Corrispondenza del percorso
Dopo che Frontdoor di Azure determina l'host front-end specifico e filtra le regole di routing possibili, seleziona le regole di routing in base al percorso della richiesta. Viene usata la logica seguente:
- Verificare la presenza di regole di routing con una corrispondenza esatta con il percorso della richiesta.
- Se non viene trovata alcuna corrispondenza esatta, cercare una regola di routing con un percorso con caratteri jolly corrispondente.
- Se non viene trovato alcun percorso corrispondente, la richiesta viene rifiutata con un errore 404: Richiesta non valida.
Nota
Il carattere * jolly è valido solo per i percorsi che non hanno altri caratteri dopo di esso. Inoltre, il carattere * jolly deve essere preceduto da una barra /. I percorsi senza caratteri jolly sono considerati percorsi di corrispondenza esatta. Un percorso che termina in una barra / è anche un percorso di corrispondenza esatta. Assicurarsi che i percorsi seguano queste regole per evitare errori.
Nota
- I percorsi senza caratteri jolly sono considerati percorsi di corrispondenza esatta. Un percorso che termina con un
/è anche una corrispondenza esatta. - I modelli di percorso non fanno distinzione tra maiuscole e minuscole. Ad esempio,
/FOOe/foovengono considerati duplicati e non sono consentiti nell'impostazione Criteri di corrispondenza.
Nella tabella seguente sono elencate le regole di routing con le combinazioni di host front-end e percorso:
| Regola di routing | Host front-end | Percorso |
|---|---|---|
| Un | www.contoso.com | / |
| G | www.contoso.com | /* |
| A | www.contoso.com | /ab |
| D | www.contoso.com | /abc |
| E | www.contoso.com | /abc/ |
| F | www.contoso.com | /abc/* |
| G | www.contoso.com | /abc/def |
| H | www.contoso.com | /path/ |
La tabella seguente illustra la regola di routing corrispondente a una richiesta in ingresso nel perimetro di Frontdoor di Azure:
| Richiesta in ingresso | Route corrispondente |
|---|---|
| www.contoso.com/ | Un |
| www.contoso.com/a | G |
| www.contoso.com/ab | A |
| www.contoso.com/abc | D |
| www.contoso.com/abzzz | G |
| www.contoso.com/abc/ | E |
| www.contoso.com/abc/d | F |
| www.contoso.com/abc/def | G |
| www.contoso.com/abc/defzzz| F | |
| www.contoso.com/abc/def/ghi| F | |
| www.contoso.com/path | G |
| www.contoso.com/path/ | H |
| www.contoso.com/path/zzz | G |
Avviso
Se non sono presenti regole di routing per un host front-end di corrispondenza esatta senza un percorso di route catch-all (/*), non verrà trovata alcuna regola di routing.
Configurazione di esempio:
| Itinerario | Host | Percorso |
|---|---|---|
| Un | profile.contoso.com | /API/* |
Tabella corrispondente:
| Richiesta in ingresso | Route corrispondente |
|---|---|
| profile.domain.com/other | Nessuno. Errore 404: Richiesta non valida |
Decisione di routing
Quando Frontdoor di Azure corrisponde a una regola di routing, decide come elaborare la richiesta. Se è disponibile una risposta memorizzata nella cache, viene restituita al client.
Se un set di regole è configurato per la regola di routing corrispondente, viene elaborato in ordine. I set di regole possono eseguire l'override di una route indirizzando il traffico a un gruppo di origine specifico. Se non viene definito alcun set di regole, la richiesta viene inoltrata al gruppo di origine senza modifiche.
Se Frontdoor di Azure (versione classica) non ha una risposta memorizzata nella cache, verifica la presenza di una configurazione di riscrittura URL. Se non è definito alcun percorso di inoltro personalizzato, la richiesta viene inoltrata al back-end appropriato nel pool back-end configurato. Se viene definito un percorso di inoltro personalizzato, il percorso della richiesta viene aggiornato di conseguenza e quindi inoltrato al back-end.
Passaggi successivi
- Creare una frontdoor di Azure.
- Informazioni sull'architettura di routing di Frontdoor di Azure.
- Creare una frontdoor di Azure (versione classica) .
- Informazioni sull'architettura di routing di Frontdoor di Azure.