Was vor fast jedem Webdienst steht
Willkommen
Wenn du example.com in einen Browser eingibst, erreichst du fast nie den Rechner, der die Anwendung tatsächlich ausführt. Du erreichst einen Rechner, der die Anfrage an einen Rechner weiterleitet, der sie ausführt. Dieser Weiterleitungsrechner trägt einen Namen: einen Reverse-Proxy.
Diese Lektion erklärt, was ein Reverse-Proxy tut, warum fast jeder öffentliche Webdienst hinter einem solchen verborgen ist und welche drei Aufgaben die Edge-Schicht gleichzeitig übernimmt.
Am Ende wirst du verstehen:
- Der Unterschied zwischen Client, Proxy und Origin
- Warum ein Proxy vor einem Origin schützt, skaliert und es ermöglicht, Komponenten auszutauschen, ohne dass jemand etwas bemerkt
- Die drei Aufgaben, die ein Reverse Proxy gleichzeitig übernimmt: Verbergen des Origins, Beendigung von TLS und Lastverteilung über Replikate
- Wie eine Anfrage vom Browser über den Proxy zum Upstream und zurück reist, Hop für Hop
Am Ende wirst du selbstbewusst über die Platzierung von Proxys, die Trennung der Zuständigkeiten an der Edge und darüber nachdenken können, warum eine stateless Proxy-Ebene sich leicht vervielfachen lässt, während dies bei einem einzelnen Origin nicht der Fall ist.
Forward Proxy vs. Reverse Proxy
Zwei Proxy-Richtungen
Beide Proxy-Arten stehen zwischen zwei Parteien und leiten den Verkehr weiter. Sie unterscheiden sich darin, welche Partei sie vertreten.
Forward-Proxy: steht vor einer Gruppe von Clients. Die Clients kennen den Proxy; ein externer Server sieht eine Proxy-Adresse, nicht die Client-Adresse. Unternehmens-Egress-Proxys, Inhaltsfilter und SOCKS-Proxys folgen diesem Muster.
Reverse-Proxy: steht vor einer Gruppe von Servern. Die Außenwelt (Clients) kommuniziert mit einer Proxy-Adresse; die Clients ahnen nicht, dass sich dahinter ein echter Server verbirgt. Fast jeder öffentliche Webdienst verwendet einen.
Merkhilfe: Ein Forward-Proxy verbirgt Clients vor Servern. Ein Reverse-Proxy verbirgt Server vor Clients.
Warum ist die Richtung wichtig? Die Aufgabe, die Fehlermodi und die Sicherheitsgrenze unterscheiden sich. Ein Forward-Proxy kümmert sich darum, wen seine Nutzer kontaktieren; ein Reverse-Proxy kümmert sich darum, wer seine Server kontaktiert.
Ein Client, der Verkehr gleichzeitig durch beide Arten sendet, durchläuft: client -> forward_proxy -> internet -> reverse_proxy -> origin.
Warum so viel an der Kante stattfindet
Die Kanten-Schicht rechtfertigt ihre Existenz
Ein Reverse-Proxy übernimmt gleichzeitig drei Aufgaben. Jede einzelne davon rechtfertigt die Schicht; die gleichzeitige Übernahme aller drei an derselben Adresse erklärt, warum fast jede produktive Web-Architektur an der Front dieselbe Form hat.
Aufgabe 1: Ursprung verbergen. Der Proxy antwortet auf einer öffentlichen IP. Backends befinden sich auf privaten IPs, die das Internet nicht erreichen kann. Ein Angreifer, der den Ursprung treffen will, muss zunächst den Proxy kompromittieren.
Aufgabe 2: TLS beenden. Der Proxy hält das Zertifikat für example.com & entschlüsselt eingehende HTTPS-Anfragen. Die Backends kommunizieren mit dem Proxy über ein vertrauenswürdiges Netzsegment per reinem HTTP (oder einfacherem internem TLS). Zertifikatsrotation, -erneuerung & Cipher-Policy liegen an einem einzigen Ort.
Aufgabe 3: Last verteilen. Der Proxy entscheidet, welches Backend jede Anfrage bearbeitet. Die Backends hinter einem Proxy bilden einen Pool; der Proxy wählt pro Anfrage eines aus, basierend auf einer Strategie (Round-Robin, Least-Connections, Hash auf einem Header). Die Kapazität wird erhöht, indem ein Backend zum Pool hinzugefügt wird, statt jedem Client eine neue Adresse mitzuteilen.
Jede Aufgabe ist ein kleines Programm. Zusammen erklären sie, warum eine Schicht so einfach wie „Caddy vor einer Python-App“ mehr Designgewicht trägt als die Python-App selbst.
Design für alle drei Aufgaben
Euer Team betreibt eine kleine API auf einem einzelnen Python-Prozess, der auf Port 8000 auf einer einzelnen VM lauscht. Der Traffic ist so gewachsen, dass eine VM nicht mehr mithalten kann, & eine Sicherheitsprüfung hat festgestellt, dass die VM eine öffentliche IP hat & ihr eigenes TLS-Zertifikat betreibt.
Ihr entscheidet euch, einen Reverse Proxy davor zu schalten. Skizziert das Layout: Wo zeigt DNS hin, wo liegt das Zertifikat, wie erreicht die Last die Backends & was ändert sich an der ursprünglichen VM?
Ein Komponente austauschen, ohne dass es jemand bemerkt
Indirektheit kauft Freiheit
Ein altes Sprichwort aus der Informatik besagt: Jedes Problem kann gelöst werden, indem man eine Ebene der Indirektion hinzufügt (außer dem Problem zu vieler Indirektionsebenen). Der Reverse Proxy ist eine der nützlichsten Indirektionen in verteilten Systemen.
Was man damit gewinnt:
- Austauschbare Backends. Die Anwendung von Python nach Go verschieben? Von einem Rechenzentrum in ein anderes migrieren? Eine neue Version mit null Ausfallzeit ausrollen? All dies geschieht hinter einer stabilen öffentlichen Adresse. Für die Nutzer ändert sich nichts.
- Unabhängiges Skalieren. Die Proxy-Ebene skaliert auf Basis von Bandbreite und CPU auf der TLS-Ebene. Die Backend-Ebene skaliert auf Basis der Anwendungslast. Jede Ebene wächst auf ihrer eigenen Achse, da sie auf verschiedenen Maschinen läuft.
- Fehlerisolierung. Ein fehlerhaftes Deployment im Backend bringt die öffentliche Adresse nicht zum Erliegen. Der Proxy bleibt online; man pusht einen Fix oder rollt zurück; die Welt verbindet sich neu, wenn das Backend wiederhergestellt ist.
- Querschnittliche Belange an einem Ort. Rate Limiting, Geo-Blocking, Request-Logging, Header-Umschreibung, Caching, Antwortkomprimierung: All dies liegt am Proxy. Der Backend-Code kann sich auf die Anwendung konzentrieren.
Ohne den Proxy muss jedes dieser Probleme innerhalb des Anwendungsprozesses gehandhabt werden. Mit dem Proxy liegen sie in einer Ebene, die von einem Team verantwortet wird.
Der Preis: eine weitere Ebene, die betrieben werden muss. Erfahrene Teams akzeptieren diese Kosten, da die Proxy-Ebene selbst zustandslos ist und horizontal skaliert; der Austausch eines Proxys durch zwei erfordert keine Koordination.
Ein Blue/Green-Deployment über den Proxy
Ihr Team betreibt Version 1 der API auf drei Backend-VMs (Blue-Pool) hinter einem Reverse Proxy. Sie möchten Version 2 bereitstellen, mit der Möglichkeit, innerhalb von unter dreißig Sekunden zurückzurollen, falls etwas schiefgeht.
Sie starten drei neue Backend-VMs (Green-Pool), die Version 2 ausführen, parallel zum Blue-Pool, leiten aber noch keinen Verkehr an sie weiter.
Vom Browser zum Backend und zurück
Eine Anfrage von Anfang bis Ende verfolgen
Verfolge eine einzelne HTTPS-GET-Anfrage an https://api.example.com/users/42 durch einen Reverse Proxy vor einem Backend-Pool.
Hop 1: DNS-Auflösung. Der Browser fragt einen Resolver nach api.example.com. Der Resolver liefert die öffentliche IP-Adresse des Proxys (z. B. 203.0.113.10) zurück. Der Browser öffnet eine TCP-Verbindung zu 203.0.113.10:443.
Hop 2: TLS-Handshake. Der Proxy präsentiert sein Zertifikat für api.example.com. Der Browser validiert das Zertifikat, beide Seiten einigen sich auf einen Sitzungsschlüssel, & der verschlüsselte Kanal wird geöffnet.
Hop 3: HTTP-Anfrage innerhalb von TLS. Der Browser sendet GET /users/42 HTTP/1.1\nHost: api.example.com\n.... Der Proxy entschlüsselt die Anfrage-Bytes.
Hop 4: Backend-Auswahl. Der Proxy konsultiert seinen Upstream-Pool für api.example.com & wählt ein Backend (z. B. 10.0.0.21:8000) anhand seiner Lastverteilungsstrategie aus.
Hop 5: Upstream-Anfrage. Der Proxy öffnet (oder wiederverwendet) eine einfache HTTP-Verbindung zu 10.0.0.21:8000 & leitet die Anfrage weiter. Der Proxy kann dabei Header umschreiben: X-Forwarded-For: <client-ip> hinzufügen, Host: korrekt setzen und hop-by-hop-Header wie Connection entfernen.
Hop 6: Backend-Verarbeitung. Die Backend-Anwendung liest die Anfrage, fragt ihre Datenbank ab und erstellt eine JSON-Antwort.
Hop 7: Upstream-Antwort. Das Backend sendet die Antwort als einfaches HTTP an den Proxy zurück.
Hop 8: Edge-Antwort. Der Proxy kann die Antwort umschreiben oder komprimieren, verschlüsselt sie über die TLS-Session zurück & sendet sie an den Browser.
Hop 9: Verbindungslebenszyklus. Die TLS-Session bleibt in der Regel für die nächste Anfrage offen (HTTP/2 multiplexiert viele Anfragen über eine Verbindung). Die Verbindung vom Proxy zum Backend wird oft gepoolt und wiederverwendet.
Jeder öffentliche Webdienst folgt einer Variante dieser Struktur. Das Wissen um die Hops ermöglicht es, zu analysieren, wo sich Latenz aufsummiert, wo Logging hingehört & wo ein Fehler verborgen sein kann.
Wohin ist die Zeit verschwunden?
Ein Nutzer beschwert sich, dass die API langsam wirkt. Du misst und feststellst, dass die Anfrage von Anfang bis Ende 850 ms dauert. Die Server-Logs im Backend zeigen, dass die Anwendung die Anfrage in 40 ms bearbeitet hat. Die Proxy-Logs zeigen, dass der Proxy 50 ms für seinen Teil der Arbeit benötigt hat (TLS-Handshake + Routing + Schreiben der Antwort).
Entwirf eine minimale Edge-Architektur für einen neuen Dienst
Synthese
Du hast gelernt, was den Unterschied zwischen einem Forward- und einem Reverse-Proxy ausmacht, welche drei Aufgaben ein Reverse-Proxy gleichzeitig übernimmt, warum das Verbergen der Origin-Server bei jeder Änderung Vorteile bringt und wie eine Anfrage Hopp für Hopp durch die Edge schwebt.
Wende es nun an.
Ein kleines Team plant den Start eines neuen Dienstes namens notes.example.com. Nutzer sollen persönliche Notizen lesen und schreiben können. Das Team wird beim Start zwei Backend-VMs betreiben und erwartet, innerhalb eines Jahres auf zehn skalieren zu müssen. Sie wünschen sich HTTPS für die Nutzer, ein schrittweises Rollout für neue Versionen und keine öffentliche Exposition der Backend-IPs.
Wohin dieser Kurs als Nächstes führt
Wohin dieser Kurs als Nächstes führt
Diese Lektion hat die Struktur der Edge-Ebene etabliert. Vier weitere Lektionen in diesem Kurs bauen darauf auf:
- Zustandslose horizontale Skalierung: warum eine Proxy-Ebene (und die Backends dahinter) sich kostengünstig multiplizieren lässt & die Mathematik zur Dimensionierung der Replikanzahl bei Lastspitzen.
- Trennung von Ingress und Egress: warum ein einzelner Proxy-Server, der sowohl eingehenden als auch ausgehenden Verkehr verarbeitet, schließlich auf überraschende Weise versagt, & wie man die Ebenen trennt.
- Fehlerszenarien & Auswirkungsbereich: Wie eine einzelne Konfigurationsänderung zu einem Ausfall führen kann und wie man schuldzuweisungsneutrale Maßnahmenformulierungen erstellt, die ein Wiederkehren verhindern.
- Beobachtbarkeit & Kapazität: Was am Edge gemessen werden sollte, damit man feststellt, dass etwas fehlerhaft ist, bevor es die Nutzer bemerken.
Jede Lektion steht für sich. Zusammen genommen geben sie dir ein funktionierendes mentales Modell eines Web-Scale-Flottens.
Begleitende Lektion: geometry_of_proxies_and_origins fasst alles in dieser Lektion als gerichteten Graphen zusammen und untersucht, was die Graphentheorie über einen Anfragepfad aussagt.
Gut gemacht. Weiter geht's.