Was ist ein Edge-Server?

Ein Edge-Server bearbeitet Anfragen in der Nähe der Endnutzer statt ausschließlich an einem zentralen Origin-Server. Er kann Inhalte zwischenspeichern oder Routing, Transformation, Authentifizierung und Berechnungen an einem verteilten Netzwerkstandort durchführen.

Im HTTP-Kontext ist ein Edge-Server ein Reverse-Proxy, den RFC 9110 als Gateway bezeichnet: Gegenüber dem Client tritt er als Origin-Server auf und leitet Anfragen, die er nicht selbst beantworten kann, an einen anderen Server weiter. CDN-Betreiber setzen viele solcher Server ein und bündeln sie an Standorten, die Fastly als Points of Presence (POPs) und Cloudflare als Rechenzentren bezeichnet. Ein Client erreicht einen dieser Standorte entweder, weil DNS eine für diesen Client ausgewählte Adresse zurückgibt, oder weil dieselbe Anycast-Adresse von jedem Standort aus angekündigt wird und das Netzwerk-Routing einen davon auswählt. Der Edge-Server antwortet dann aus seinem Cache, führt konfigurierte Anfragelogik aus oder leitet die Anfrage zum Origin-Server weiter. Eine an einem Standort zwischengespeicherte Antwort wird nicht automatisch auch an den anderen gespeichert. Wohin eine Anfrage bei einem Cache-Miss als Nächstes gelangt, hängt vom CDN und seiner Konfiguration ab: direkt zum Origin-Server oder zunächst zu einem übergeordneten Cache, etwa einem Shield-POP von Fastly, einer oberen Ebene von Cloudflare Tiered Cache oder einem regionalen Edge-Cache von Amazon CloudFront.

Bearbeitet immer der nächstgelegene Edge-Server die Anfrage? Nein. Bei Anycast wählt das Routing-System den Standort anhand der Netzwerktopologie aus. RFC 4786 weist darauf hin, dass topologische Nähe im Allgemeinen keinen Rückschluss auf die Paketumlaufzeit erlaubt. Bei einer DNS-basierten Auswahl sieht der autoritative DNS-Server des CDN die Adresse des rekursiven Resolvers (des DNS-Servers, der im Auftrag des Nutzers Namen auflöst) statt der eigenen Adresse des Nutzers, sofern der Resolver kein Client-Subnetz weitergibt, also eine gekürzte Form der Nutzeradresse. Wer einen weit entfernten Resolver nutzt, kann deshalb zu einem Standort in der Nähe dieses Resolvers geleitet werden.
Ist eine an einem Edge-Standort zwischengespeicherte Antwort an allen Standorten verfügbar? Nicht automatisch: Hat ein Standort die Antwort nicht gespeichert, entsteht ein Cache-Miss. Wohin die Anfrage dann gelangt, hängt vom CDN und seiner Konfiguration ab. Fastly-POPs leiten Anfragen unabhängig voneinander zum Origin-Server weiter, sofern Shielding sie nicht über einen gemeinsamen Shield-POP führt. Bei Cloudflare Tiered Cache fragt ein Rechenzentrum auf einer unteren Ebene zunächst eine obere Ebene und erst danach den Origin-Server. Amazon CloudFront verfügt standardmäßig über eine solche Ebene: Bei einem Cache-Miss fragt ein POP üblicherweise einen regionalen Edge-Cache, der das Objekt möglicherweise bereits enthält. Keine dieser Ebenen garantiert, welche Anfragen den Origin-Server erreichen. Cloudflare wendet Tiered Cache nur auf Anfragen an, die für das Caching infrage kommen. CloudFront sendet dynamische Anfragen und Methoden wie POST vom POP direkt zum Origin-Server. Fastly empfiehlt, dass Compute-Code auf den Origin-Server zurückgreift, wenn der Shield-POP nicht verfügbar ist.
Welcher Code kann auf einem Edge-Server ausgeführt werden? Das hängt vom Produkt und davon ab, in welcher Phase der Anfrage der Code eingebunden ist. Prüfen Sie dies daher, bevor Sie Ihre Architektur darauf ausrichten. Amazon CloudFront dokumentiert zwei Optionen: CloudFront Functions für einfache Aufgaben wie die Normalisierung von Cache-Schlüsseln, Header-Änderungen, Weiterleitungen und Token-Validierung, ohne Netzwerkzugriff und ohne Zugriff auf den Anfragekörper; und Lambda@Edge für Funktionen, die Netzwerkzugriff, Bibliotheken von Drittanbietern oder den Anfragekörper benötigen. Cache-Ebenen können auch beeinflussen, wie oft Code ausgeführt wird: Bei Fastly Shielding läuft Edge-Code üblicherweise zweimal, einmal am ersten POP und einmal am Shield. Logik, die eine Anfrage umschreibt oder einen Header hinzufügt, muss daher auch bei zweimaliger Ausführung sicher funktionieren.
Schützt die Validierung einer signierten URL am Edge den Origin-Server? Nur bei Anfragen, die den Edge-Server durchlaufen. CloudFront dokumentiert zwei getrennte Schutzmaßnahmen: Signierte URLs oder signierte Cookies beschränken den Zugriff auf Dateien in den Edge-Caches. Der Origin-Server muss separat abgeschottet werden, damit Clients das CDN nicht umgehen und Dateien direkt von ihm abrufen können. Bei S3 als Origin-Server bedeutet das, einer Origin Access Control die Leseberechtigung für den Bucket zu erteilen und allen anderen die Berechtigung zu entziehen, die Dateien über S3-URLs zu lesen. Bei einem benutzerdefinierten Origin-Server ist ein benutzerdefinierter Header erforderlich, den CloudFront Anfragen an den Origin-Server hinzufügt und den dieser voraussetzt. Sowohl die Verbindung zum Client als auch die Verbindung zum Origin-Server müssen HTTPS verwenden, damit der Header bei der Übertragung verschlüsselt ist. Die AWS-Anleitung für Load-Balancer als Origin-Server ergänzt, dass dies nur funktioniert, solange Name und Wert des Headers geheim bleiben, und empfiehlt, sie regelmäßig zu wechseln. Unabhängig davon gilt: Wenn Clients sich mit einem Header namens Authorization statt mit einer signierten URL authentifizieren, verbietet RFC 9111 einem gemeinsam genutzten Cache, die Antwort für eine spätere Anfrage wiederzuverwenden, sofern die Antwort dies nicht mit public, s-maxage oder must-revalidate erlaubt.

Edge-Server sind besonders wichtig, wenn viele Clients weit entfernt vom Origin-Server dieselbe Antwort anfordern: Bei einem Cache-Treffer wird die Anfrage am Edge-Standort beantwortet und erreicht den Origin-Server nie. Eine Anfrage, die der Edge-Server nicht aus einer gespeicherten Antwort beantworten kann, wird bei ihrem Eintreffen verarbeitet. Das übernimmt entweder der Origin-Server, wobei die Anfrage weiterhin zu ihm übertragen wird, oder Edge-Logik, die die Antwort selbst erzeugt. Dabei übernimmt der Edge-Server Routing, Filterung oder Anfragelogik, statt eine gespeicherte Kopie zu liefern. Wenn Sie Ihre Architektur auf einen Edge-Server ausrichten, berücksichtigen Sie den Verarbeitungsweg bei Cache-Misses, Caches, die sich an jedem Standort separat füllen, und Anfragen, die den Origin-Server erreichen, ohne den Edge-Server zu durchlaufen.

Transloadits Smart CDN schaltet Edge-Caching vor die Verarbeitung auf Abruf. Eine Anfrage an eine URL (tlcdn.com) wird am Edge beantwortet, wenn eine zwischengespeicherte Kopie vorhanden ist. Bei einem Cache-Miss führt die Anfrage Ihr Template als Assembly aus. Der Robot /file/serve wählt das zurückzugebende Ergebnis aus und setzt dessen Header Cache-Control. Anschließend speichert /tlcdn/deliver dieses Ergebnis im Cache und liefert es in der Nähe Ihrer Nutzer aus.

Die verlinkten Seiten beschreiben Caching und Auslieferung am Edge sowie die Verarbeitung in einer Assembly. Sie dokumentieren keine Laufzeitumgebung, in der Sie eigenen Code am Edge ausführen können. Eine URL für Smart CDN kann optional einen Ablaufzeitpunkt und eine Signatur enthalten. Werden die URL oder ihre Parameter danach geändert, stimmt die Signatur nicht mehr. Das verhindert Änderungen an der URL durch Außenstehende nur dann, wenn unsignierte Anfragen abgelehnt werden. Die verlinkten Seiten erklären auch nicht, wie eine unsignierte Anfrage an dasselbe Template behandelt wird. Testen Sie dies daher in Ihrem eigenen Workspace, bevor Sie sich darauf verlassen. Transloadit beschreibt Smart CDN als Transformations- und Auslieferungsschicht, die die Autorisierungsrichtlinie Ihrer Anwendung nicht ersetzt.

Entdecken Sie Transloadits Möglichkeiten zur Auslieferung

Was ist ein Edge-Server?

So funktionieren Edge-Server

Wichtige Fakten

Wann Edge-Server wichtig sind

So hilft Transloadit bei Edge-Servern

Quellen

Machen Sie aus Medienwissen eine funktionierende Pipeline