Vue d’ensemble de l’architecture de routage

Le routage du trafic de Azure Front Door s’effectue en plusieurs étapes. Le trafic est tout d’abord redirigé du client vers Front Door. Ensuite, Front Door utilise votre configuration pour déterminer l’origine à laquelle envoyer le trafic. Le pare-feu d’applications Web, les règles de routage, le moteur de règles et la configuration de la mise en cache de Front Door peuvent tous avoir une incidence sur le processus de routage.

Le diagramme suivant montre l’architecture de routage :

Important

Azure Front Door (classique) va être mis hors service le 31 mars 2027. Pour éviter toute interruption de service, il est important de migrer vos profils Azure Front Door (classique) vers le niveau Azure Front Door Standard ou Premium au plus en mars 2027. Pour plus d’informations, consultez Mise hors service d’Azure Front Door (classique).

Le reste de cet article décrit ces étapes en détail.

Sélectionner et se connecter à l’emplacement de périphérie Front Door

L’utilisateur ou l’application cliente initie une connexion vers Front Door. La connexion se termine à un emplacement de périphérie le plus proche de l’utilisateur final. L’emplacement de périphérie de Front Door traite la demande.

Pour plus d’informations sur la façon dont les demandes sont adressées à Front Door, consultez Accélération du trafic de Front Door.

Requête de correspondance à un profil Front Door

Lorsque Front Door reçoit une requête HTTP, il utilise l’en-tête Host de la requête pour faire correspondre la requête au bon profil Front Door du client. Si la demande utilise un nom de domaine personnalisé, le nom de domaine doit être inscrit avec Front Door pour permettre aux requêtes d’être mises en correspondance avec votre profil.

Requête de correspondance à Front Door

Lorsque Front Door reçoit une requête HTTP, il utilise l’en-tête Host de la requête pour faire correspondre la requête à la bonne instance Front Door du client. Si la demande utilise un nom de domaine personnalisé, le nom de domaine doit être inscrit avec Front Door pour permettre aux requêtes d’être mises en correspondance avec votre instance Front Door.

Le client et le serveur effectuent une négociation TLS à l’aide du certificat TLS que vous avez configuré pour votre nom de domaine personnalisé, ou à l’aide du certificat Front Door lorsque l’en-tête Host se termine par *.azurefd.net.

Évaluer les règles WAF

Si votre domaine a activé le pare-feu d’applications web, les règles WAF sont évaluées.

Si votre serveur frontal a activé le pare-feu d’applications web, les règles WAF sont évaluées.

Si une règle n’a pas été respectée, Front Door retourne une erreur au client, et le traitement de la requête s’arrête.

Faire correspondre un itinéraire

Front Door établit une correspondance entre les requêtes et un itinéraire. En savoir plus sur le processus de mise en correspondance des itinéraires.

L’itinéraire spécifie le groupe d’origine vers lequel la requête doit être envoyée.

Faire correspondre une règle d’acheminement

Front Door établit une correspondance entre les requêtes et une règle d’acheminement. En savoir plus sur le processus de mise en correspondance des itinéraires.

L’itinéraire spécifie le pool back-end auquel la requête doit être envoyée.

Évaluer les ensembles de règles

Si vous avez défini des ensembles de règles pour l’itinéraire, ceux-ci sont exécutés dans l’ordre dans lequel ils sont configurés. Les ensembles de règles peuvent remplacer le groupe d’origine spécifié dans un itinéraire. Les ensembles de règles peuvent également déclencher une réponse de redirection à la requête au lieu de la transférer à une origine.

Évaluer les moteurs de règles

Si vous avez défini des moteurs de règles pour l’itinéraire, ceux-ci sont exécutés dans l’ordre dans lequel ils sont configurés. Les moteurs de règles peuvent remplacer le pool principal spécifié dans une règle de routage. Les moteurs de règles peuvent également déclencher une réponse de redirection à la requête au lieu de la transférer vers un serveur principal.

Retourner la réponse mise en cache

Si la mise en cache est activée pour la règle de routage Front Door, et si le cache de l’emplacement de périphérie inclut une réponse valide pour la requête, Front Door renvoie la réponse mise en cache.

Si la mise en cache est désactivée ou si aucune réponse n’est disponible, la requête est transférée à l’origine.

Si la mise en cache est activée pour la règle de routage Front Door, et si le cache de l’emplacement de périphérie inclut une réponse valide pour la requête, Front Door renvoie la réponse mise en cache.

Si la mise en cache est désactivée ou si aucune réponse n’est disponible, la requête est transférée au back-end.

Sélectionner l’origine

Front Door sélectionne une origine à utiliser dans le groupe d’origine. La sélection d’origine est basée sur plusieurs facteurs, notamment :

• L’intégrité de chaque origine, que Front Door surveille à l’aide de sondes d’intégrité.
• La méthode de routage pour votre groupe d’origine.
• Si vous avez activé ou non l’affinité de session

Transférer la requête à l’origine

Enfin, la requête est transmise à l’origine.

Sélectionner le backend

Front Door sélectionne un serveur principal à utiliser dans le pool principal. La sélection du serveur back-end est basée sur plusieurs facteurs, notamment :

• L’intégrité de chaque back-end, que Front Door surveille à l’aide de sondes d’intégrité.
• La méthode de routage pour votre pool principal.
• Si vous avez activé ou non l’affinité de session

Transférer la requête au back-end

Enfin, la requête est transférée au back-end.

Étapes suivantes

• Découvrez comment créer un profil Front Door.

• Découvrez comment créer un profil Front Door.