Beschleunigen des Datenverkehrs

  • Artikel

Front Door optimiert den Datenverkehrspfad vom Endbenutzer zum Ursprungsserver. In diesem Artikel wird beschrieben, wie der Datenverkehr vom Benutzer über Front Door an den Ursprungsserver geleitet wird.

Wichtig

Azure Front Door (klassisch) wird am 31. März 2027 eingestellt. Um Dienstunterbrechungen zu vermeiden, ist es wichtig, dass Sie Ihre (klassischen) Azure Front Door-Profile bis März 2027 zur Dienstebene Azure Front Door Standard oder Premium migrieren. Weitere Informationen finden Sie unter Einstellung von Azure Front Door (klassisch).

Front Door optimiert den Datenverkehrspfad vom Endbenutzer bis zum Back-End-Server. In diesem Artikel wird beschrieben, wie der Datenverkehr vom Benutzer über Front Door an das Back-End geleitet wird.

Auswählen der Front Door-Edgestandorte für die Anforderung (Anycast)

Global verfügt Front Door über mehr als 150 Edgestandorte bzw. Points of Presence (PoPs), die sich in vielen Ländern/Regionen befinden. Jeder Front Door-PoP kann Datenverkehr für jede Anforderung bedienen.

Datenverkehr, der an die Azure Front Door-Edgestandorte geleitet wird, verwendet Anycast sowohl für DNS-Datenverkehr (Domain Name System) als auch für HTTP-Datenverkehr (Hypertext Transfer Protocol). Mit Anycast können Benutzeranforderungen den nächstgelegenen Edgestandort mit möglichst wenigen Netzwerkhops erreichen. Diese Architektur bietet bessere Roundtripzeiten für Endbenutzer durch Maximierung der Vorteile von geteiltem TCP.

Azure Front Door unterteilt die Edge-Standorte in Primär- und Fallback-Ringe. Die Edge-Standorte im äußeren Ring befinden sich näher bei den Benutzern und ermöglichen daher niedrigere Latenzen. Die Edge-Standorte im inneren Ring können bei eventuellen Problemen das Failover für die Edge-Standorte im äußeren Ring übernehmen.

Das bevorzugte Ziel für den gesamten Datenverkehr ist der äußere Ring. Der innere Ring ist als Entlastung bei übermäßig hohem Datenverkehr im äußeren Ring konzipiert. Allen Front-End-Hosts oder Domänen, die von Front Door bedient werden, werden eine primäre und eine Fallback-VIP (Virtual Internet Protocol-Adresse) zugewiesen, die von den Edge-Standorten im inneren und äußeren Ring bekannt gegeben werden.

Diese Architektur stellt sicher, dass Anforderungen von Ihren Endbenutzern immer die nächstgelegenen Front Door-Edge-Standorte erreichen. Wenn der bevorzugte Front Door-Edge-Standort nicht einwandfrei funktioniert, wird der gesamte Datenverkehr automatisch zum nächstgelegenen Edge-Standort verschoben.

Herstellen einer Verbindung zum Front Door-Edge-Standort (Geteiltes TCP)

Geteiltes TCP ist ein Verfahren, bei dem eine Verbindung, die eine hohe Roundtripzeit haben würde, in kleine Teile aufgeteilt wird, um die Wartezeiten und TCP-Probleme zu reduzieren.

Geteiltes TCP bietet die Möglichkeit, die TCP-Verbindung des Clients an einem Front Door-Edge-Standort in der Nähe des Benutzers zu beenden. Es wird eine separate TCP-Verbindung zum Ursprungsserver hergestellt, und diese separate Verbindung weist möglicherweise eine hohe Roundtripzeit auf.

Das folgende Diagramm veranschaulicht, wie drei Benutzer an verschiedenen geografischen Standorten eine Verbindung mit einem Front Door-Edgestandort in der Nähe ihres Standorts herstellen. Front Door hält dann die länger bestehende Verbindung mit dem Ursprungsserver in Europa aufrecht:

Diagramm, das veranschaulicht, wie Front Door eine kurze TCP-Verbindung mit dem nächstgelegenen Front Door-Edgestandort für den Benutzer und eine längere TCP-Verbindung mit dem Ursprung verwendet.

Zum Herstellen einer TCP-Verbindung sind drei bis fünf Roundtrips vom Client zum Server erforderlich. Mit der Architektur von Front Door wird die Leistung beim Herstellen der Verbindung optimiert. Die „kurze Verbindung“ zwischen Endbenutzer und Front Door-Edge-Standort bedeutet, dass die Verbindung über drei bis fünf kurze (und nicht lange) Roundtrips hergestellt wird, was zu Latenzeinsparungen führt. Die „lange Verbindung“ zwischen dem Front Door-Edge-Standort und dem Ursprungsserver kann vorab eingerichtet und bei weiteren Endbenutzeranforderungen wiederverwendet werden, wodurch sich die Verbindungszeit verkürzt. Der Effekt des geteilten TCP multipliziert sich beim Herstellen einer SSL/TLS-Verbindung (Transport Layer Security), da hier mehr Roundtrips zum Sichern einer Verbindung erforderlich sind.

Geteiltes TCP bietet die Möglichkeit, die TCP-Verbindung des Clients an einem Front Door-Edge-Standort in der Nähe des Benutzers zu beenden. Es wird eine separate TCP-Verbindung zum Back-End-Server hergestellt, und diese separate Verbindung weist möglicherweise eine hohe Roundtripzeit auf.

Das folgende Diagramm veranschaulicht, wie drei Benutzer an verschiedenen geografischen Standorten eine Verbindung mit einem Front Door-Edgestandort in der Nähe ihres Standorts herstellen. Front Door hält dann die länger bestehende Verbindung mit dem Back-End-Server in Europa aufrecht:

Diagramm, das veranschaulicht, wie Front Door eine kurze TCP-Verbindung mit dem nächstgelegenen Front Door-Edgestandort für den Benutzer und eine längere TCP-Verbindung mit dem Back-End verwendet.

Zum Herstellen einer TCP-Verbindung sind drei bis fünf Roundtrips vom Client zum Server erforderlich. Mit der Architektur von Front Door wird die Leistung beim Herstellen der Verbindung optimiert. Die „kurze Verbindung“ zwischen Endbenutzer und Front Door-Edge-Standort bedeutet, dass die Verbindung über drei bis fünf kurze (und nicht lange) Roundtrips hergestellt wird, was zu Latenzeinsparungen führt. Die „lange Verbindung“ zwischen dem Front Door-Edge-Standort und dem Back-End-Server kann vorab eingerichtet und bei weiteren Endbenutzeranforderungen wiederverwendet werden, wodurch sich die Verbindungszeit verkürzt. Der Effekt des geteilten TCP multipliziert sich beim Herstellen einer SSL/TLS-Verbindung (Transport Layer Security), da hier mehr Roundtrips zum Sichern einer Verbindung erforderlich sind.

Nächste Schritte