Optimisation des performances avec les règles CDN

Le moteur de règles d’Azure Front Door (appelé Rule sets dans Standard/Premium) vous permet d’intercepter et de modifier les demandes et les réponses HTTP au niveau du PoP périphérique, avant leur mise en cache ou leur transfert vers l’origine. Sans moteur de règles, vous devriez gérer des tâches telles que les redirections HTTP vers HTTPS, les en-têtes de réponse de sécurité et le blocage géographique dans le code de votre application d’origine, ce qui ajouterait de la latence et couplerait les problèmes de sécurité à la logique métier. Les règles exécutées à la périphérie sont plus rapides et réduisent la charge de l’origine.

L’un des cas d’utilisation les plus courants du moteur de règles consiste à imposer HTTPS. Lorsqu’un client demande votre site via HTTP, une règle de redirection à la périphérie de Front Door renvoie immédiatement une réponse 301 Moved Permanently (ou 302 Found) pointant vers l’URL HTTPS, sans que la demande n’atteigne jamais l’origine. Cette méthode est plus rapide que les redirections côté origine et garantit le chiffrement de tout le trafic en transit. Configurez-la comme une action de redirection pour les demandes dont la condition RequestScheme est égale à HTTP.

Les navigateurs modernes prennent en charge des en-têtes de sécurité HTTP qui empêchent les attaques courantes. Vous pouvez ajouter ces en-têtes à toutes les réponses à l’aide d’actions Append response header du moteur de règles, sans modifier votre serveur d’origine. Les principaux en-têtes sont les suivants : Strict-Transport-Security (force HTTPS pendant une certaine période), X-Content-Type-Options: nosniff (empêche la détection automatique du type MIME), X-Frame-Options: DENY (empêche le détournement de clic) et Content-Security-Policy (limite les sources de contenu). Leur ajout à la périphérie garantit une application cohérente sur toutes les origines.

Le moteur de règles vous permet de remplacer la durée de vie TTL du cache par défaut pour certains modèles d’URL. Par exemple, vous pouvez mettre en cache /static/images/* pendant 30 jours, mais les réponses de /api/* pendant seulement 60 secondes. Utilisez une condition de correspondance sur RequestUri et une action Route configuration override qui définit une durée de cache personnalisée. Vous bénéficiez ainsi d’un contrôle précis du comportement du cache sans créer plusieurs routes distinctes pour chaque type de contenu.

Les actions de réécriture d’URL modifient l’URL de la demande avant son transfert vers l’origine, sans changer l’URL visible par le client. Cette fonctionnalité est utile pour envoyer des demandes d’une structure d’URL vers un autre chemin du serveur principal. Par exemple, réécrivez /products/item/{id} en /catalog/v2/products/{id} pour prendre en charge une modification de l’API principale sans mettre à jour les liens des clients. La réécriture d’URL est une action du moteur de règles qui modifie le URL path à l’aide d’un remplacement de chaîne ou de groupes de capture.

Le filtrage géographique au niveau du moteur de règles vous permet de rediriger ou de bloquer les utilisateurs de certains pays en fonction de la géolocalisation dérivée de l’adresse IP du client. Contrairement au filtrage géographique du CDN (qui renvoie 403), celui du moteur de règles offre davantage de souplesse : vous pouvez rediriger les utilisateurs de pays bloqués vers une page d’accueil expliquant la disponibilité régionale, ou acheminer certains pays vers des groupes d’origines propres à chaque région (par exemple, les utilisateurs de l’UE vers des origines de l’UE pour respecter le GDPR). La correspondance géographique RemoteAddress utilise la base de données d’adresses IP associées aux pays de MaxMind.

Le moteur de règles peut ajouter, remplacer ou supprimer des en-têtes de demande avant leur transfert vers l’origine. Une utilisation courante consiste à ajouter un X-Forwarded-For ou un en-tête personnalisé tel que X-Front-Door-Id, afin que l’origine sache que les demandes sont passées par Front Door et puisse les valider. Vous pouvez également supprimer l’en-tête Host d’origine et le remplacer par le nom d’hôte de l’origine, ce qui est important lorsque l’origine valide l’en-tête Host. Vous contrôlez ainsi entièrement ce que voit le serveur d’origine.

Les conditions du moteur de règles peuvent effectuer une correspondance sur les valeurs des en-têtes de demande, ce qui permet de mettre en place une logique de routage sophistiquée. Par exemple, acheminez les demandes contenant l’en-tête X-API-Version: 2 vers un autre groupe d’origines exécutant l’API v2, tandis que les demandes dépourvues de cet en-tête sont envoyées vers l’origine v1. Vous pouvez ainsi gérer le versionnage d’API blue-green à la périphérie sans exiger de noms d’hôte distincts pour chaque version d’API. Le routage fondé sur les en-têtes sert également aux tests A/B, en fonctionnant selon un cookie personnalisé de segment utilisateur.

La compression des réponses dans Front Door compresse les réponses textuelles (HTML, CSS, JavaScript, JSON) avec gzip ou Brotli avant de les servir depuis les PoPs. La compression est particulièrement efficace pour les grands ensembles de fichiers JS et peut réduire la taille transférée jusqu’à 70 %. Activez la compression dans les paramètres de la route et indiquez les types MIME à compresser. Le contenu compressé est mis en cache sous forme compressée au niveau du PoP : seule la première demande de chaque ressource déclenche la compression ; les demandes suivantes servent instantanément le fichier compressé mis en cache.

Origin Shield est une couche de mise en cache supplémentaire facultative que Front Door place entre les nœuds périphériques des PoPs et l’origine. Lorsqu’elle est activée, au lieu que chacun des plus de 100 PoPs périphériques demande indépendamment le contenu non mis en cache à l’origine, ils transmettent tous les défauts de cache à un seul PoP régional Origin Shield, qui les transmet ensuite à l’origine. Cela réduit considérablement le nombre de demandes atteignant l’origine (ce que l’on appelle le taux de déchargement de l’origine), tout en continuant à servir le contenu dans le monde entier depuis les PoPs périphériques.

Avant de déployer des modifications du moteur de règles en production, validez-les à l’aide des outils de diagnostic et de test du portail. Le volet Diagnostic settings, avec les journaux WAF en mode Détection, indique quelles règles correspondent. Pour le moteur de règles, vous pouvez également inspecter les en-têtes réels des demandes et des réponses dans les outils de développement du navigateur après un déploiement dans un environnement de préproduction, ou utiliser curl -v pour envoyer des demandes précises et vérifier que les en-têtes de réponse et le comportement de redirection sont conformes aux attentes avant le passage en production.

Vérifiez votre compréhension des concepts Microsoft Azure Fundamentals (AZ-900) présentés dans cette leçon.

Dans cette leçon, vous avez appris que le moteur de règles Front Door gère les redirections HTTP vers HTTPS, les en-têtes de réponse de sécurité et les remplacements de TTL du cache à la périphérie, sans modification de l’origine, que la réécriture d’URL modifie discrètement les chemins de demande transférés vers l’origine, tandis que la redirection d’URL modifie l’URL visible par le client, et qu’Origin Shield réduit la charge de l’origine en regroupant les demandes dues aux défauts de cache via un nœud bouclier régional. Nous allons maintenant découvrir Azure AI Services pour ajouter de l’intelligence à vos applications.