Performanceoptimierung mit CDN-Regeln

Die Regel-Engine von Azure Front Door (in Standard/Premium als Rule sets bezeichnet) ermöglicht es Ihnen, HTTP-Anforderungen und -Antworten am Edge-PoP abzufangen und zu ändern, bevor sie zwischengespeichert oder an den Ursprung weitergeleitet werden. Ohne eine Regel-Engine müssten Sie Aufgaben wie Umleitungen von HTTP zu HTTPS, Sicherheitsheader in Antworten und geografische Blockierung im Code Ihrer Ursprungsanwendung verarbeiten. Das würde zusätzliche Latenz verursachen und Sicherheitsaspekte eng mit der Geschäftslogik verknüpfen. Regeln am Edge werden schneller ausgeführt und verringern die Last auf dem Ursprung.

Eine der häufigsten Anwendungen der Regel-Engine ist die Erzwingung von HTTPS. Wenn ein Client Ihre Website über HTTP anfordert, gibt eine Umleitungsregel am Front Door-Edge sofort eine 301 Moved Permanently- (oder 302 Found-)Antwort mit der HTTPS-URL zurück, ohne dass die Anforderung jemals den Ursprung erreicht. Das ist schneller als Umleitungen auf dem Ursprung und stellt sicher, dass der gesamte Datenverkehr während der Übertragung verschlüsselt ist. Konfigurieren Sie dies als Umleitungsaktion für Anforderungen, bei denen die Bedingung RequestScheme dem Wert HTTP entspricht.

Moderne Browser unterstützen HTTP-Sicherheitsheader, die häufige Angriffe verhindern. Sie können diese Header mit der Aktion Append response header der Regel-Engine zu allen Antworten hinzufügen, ohne Ihren Ursprungsserver zu ändern. Zu den wichtigsten Headern gehören: Strict-Transport-Security (erzwingt HTTPS für einen bestimmten Zeitraum), X-Content-Type-Options: nosniff (verhindert MIME-Sniffing), X-Frame-Options: DENY (verhindert Clickjacking) und Content-Security-Policy (beschränkt Inhaltsquellen). Durch das Hinzufügen am Edge wird eine konsistente Anwendung über alle Ursprünge hinweg sichergestellt.

Mit der Regel-Engine können Sie die standardmäßige Cache-TTL überschreiben und für bestimmte URL-Muster festlegen. Beispielsweise möchten Sie /static/images/* möglicherweise 30 Tage lang zwischenspeichern, Antworten von /api/* jedoch nur 60 Sekunden. Verwenden Sie eine Übereinstimmungsbedingung für RequestUri und die Aktion Route configuration override, um eine benutzerdefinierte Cache-Dauer festzulegen. So können Sie das Caching fein abgestuft steuern, ohne für jeden Inhaltstyp mehrere separate Routen zu erstellen.

Aktionen zum Umschreiben von URLs ändern die URL der Anforderung, bevor sie an den Ursprung weitergeleitet wird, ohne die für den Client sichtbare URL zu ändern. Dies ist nützlich, um Anforderungen von einer URL-Struktur an einen anderen Backend-Pfad zu senden. Beispielsweise können Sie /products/item/{id} in /catalog/v2/products/{id} umschreiben, um eine Änderung der Backend-API zu unterstützen, ohne Clientlinks zu aktualisieren. Das Umschreiben von URLs ist eine Aktion der Regel-Engine, die den URL path mithilfe von Zeichenfolgenersetzung oder Erfassungsgruppen ändert.

Geografische Filterung auf Ebene der Regel-Engine ermöglicht es Ihnen, Benutzer aus bestimmten Ländern anhand des aus der Client-IP abgeleiteten geografischen Standorts umzuleiten oder zu blockieren. Im Gegensatz zur geografischen CDN-Filterung (die 403 zurückgibt) bietet die geografische Filterung der Regel-Engine mehr Flexibilität. Sie können blockierte Länder auf eine Landingpage umleiten, die die regionale Verfügbarkeit erläutert, oder bestimmte Länder an regionsspezifische Ursprungsgruppen weiterleiten (z. B. Benutzer aus der EU für die Einhaltung der DSGVO an Ursprünge in der EU). Die geografische Übereinstimmung mit RemoteAddress verwendet die IP-zu-Land-Datenbank von MaxMind.

Die Regel-Engine kann Anforderungsheader hinzufügen, überschreiben oder löschen, bevor die Anforderung an den Ursprung weitergeleitet wird. Häufig wird beispielsweise ein X-Forwarded-For-Header oder ein benutzerdefinierter Header wie X-Front-Door-Id hinzugefügt, damit der Ursprung erkennt, dass die Anforderungen über Front Door eingegangen sind, und sie validieren kann. Sie können auch den ursprünglichen Host-Header löschen und durch den Hostnamen des Ursprungs ersetzen – das ist wichtig, wenn der Ursprung den Host-Header validiert. So erhalten Sie vollständige Kontrolle darüber, was der Ursprungsserver sieht.

Die Bedingungen der Regel-Engine können auf Werte von Anforderungsheadern zutreffen und ermöglichen so eine ausgefeilte Routinglogik. Beispielsweise können Sie Anforderungen mit dem Header X-API-Version: 2 an eine andere Ursprungsgruppe mit der v2-API weiterleiten, während Anforderungen ohne diesen Header an den v1-Ursprung gehen. Dadurch wird Blue-Green-Versionierung von APIs am Edge ermöglicht, ohne separate Hostnamen für jede API-Version zu benötigen. Headerbasiertes Routing wird auch für A/B-Tests verwendet, indem anhand eines benutzerdefinierten Cookies für Benutzersegmente geroutet wird.

Antwortkomprimierung in Front Door komprimiert textbasierte Antworten (HTML, CSS, JavaScript und JSON) mit gzip oder Brotli, bevor sie von PoPs ausgeliefert werden. Die Komprimierung ist besonders bei großen JavaScript-Bundles wirksam und kann die Übertragungsgröße um bis zu 70 % reduzieren. Aktivieren Sie die Komprimierung in den Routeneinstellungen und geben Sie die zu komprimierenden MIME-Typen an. Komprimierte Inhalte werden am PoP in komprimierter Form zwischengespeichert. Daher löst nur die erste Anforderung für jedes Asset eine Komprimierung aus; nachfolgende Anforderungen liefern die komprimierte Datei sofort aus dem Cache.

Origin Shield ist eine optionale zusätzliche Cachingebene, die Front Door zwischen den Edge-Knoten der PoPs und dem Ursprung platziert. Wenn diese Funktion aktiviert ist, fordern nicht mehr jeweils über 100 Edge-PoPs unabhängig voneinander nicht zwischengespeicherte Inhalte vom Ursprung an. Stattdessen leiten sie Cachefehler an einen einzelnen regionalen Origin-Shield-PoP weiter, der die Anforderungen anschließend an den Ursprung weiterleitet. Dadurch wird die Anzahl der Anforderungen an den Ursprung erheblich reduziert (dies wird als Origin-Offload-Verhältnis bezeichnet), während Inhalte weiterhin weltweit von Edge-PoPs ausgeliefert werden.

Validieren Sie Änderungen an der Regel-Engine mithilfe der Diagnose- und Testtools im Portal, bevor Sie sie in der Produktion bereitstellen. Im Bereich Diagnoseeinstellungen können Sie anhand der WAF-Protokolle im Erkennungsmodus sehen, auf welche Regeln Anforderungen zutreffen. Für die Regel-Engine können Sie außerdem nach der Bereitstellung in einer Stagingumgebung die tatsächlichen Anforderungs- und Antwortheader in den Entwicklertools des Browsers prüfen oder mit curl -v bestimmte Anforderungen senden. So können Sie überprüfen, ob Antwortheader und Umleitungsverhalten wie erwartet funktionieren, bevor Sie auf die Produktion umstellen.

Testen Sie Ihr Verständnis der Konzepte aus Microsoft Azure Fundamentals (AZ-900) in dieser Lektion.

In dieser Lektion haben Sie gelernt: Die Regel-Engine von Front Door verarbeitet Umleitungen von HTTP zu HTTPS, Sicherheitsheader in Antworten und Überschreibungen der Cache-TTL am Edge, ohne Änderungen am Ursprung zu erfordern. Mit URL rewrite werden an den Ursprung weitergeleitete Anforderungspfade unbemerkt geändert, während eine URL-Umleitung die für den Client sichtbare URL ändert. Origin Shield reduziert die Last auf dem Ursprung, indem Cachefehler über einen regionalen Shield-Knoten gebündelt werden. Als Nächstes sehen wir uns Azure AI Services an, um Ihren Anwendungen intelligente Funktionen hinzuzufügen.