Was vor fast jedem Web-Service steht
Willkommen
Wenn Sie "example.com" in einen Browser eingeben, erreichen Sie in der Regel nie die Maschine, die die Anwendung tatsächlich ausführt. Sie erreichen eine Maschine, die das Anforderungsdatum an eine, die es tut, weiterleitet. Diese Maschine, die das Weiterleiten ausführt, trägt einen Namen: ein umgekehrter Proxy.
Diese Lektion lehrt, was ein umgekehrter Proxy tut, warum fast jeder öffentliche Web-Service hinter einem versteckt ist und was gleichzeitig drei Aufgaben von der Kantenlage erfüllt werden.
Am Ende werden Sie verstehen:
- Die Unterschiede zwischen einem Klienten, einem Proxy und einer Ursprungseite
- Warum ein Proxy vor einer Ursprungseite schützt, skalieren und Teile austauschen lässt, ohne dass jemand etwas merkt
- Die drei Aufgaben, die ein umgekehrter Proxy gleichzeitig erfüllt: das Verbergen der Ursprungseite, das Beenden von TLS und das Verteilen der Last über Replicas hinweg
- Wie eine Anfrage von Browser zu Proxy zu "oben" und zurück reist, Schritt für Schritt
Am Ende werden Sie mit Vertrauen über die Platzierung von Proxies, die Trennung von Sorgen im Edge und die Gründe dafür argumentieren können, warum ein stateless Proxy-Tier sich leicht multipliziert, während eine einzelne Ursprungseite nicht tut.
Forward Proxy vs Reverse Proxy
Zwei Proxy- Richtungen
Beide Arten von Proxy stehen zwischen zwei Parteien und leiten Daten weiter. Sie unterscheiden sich in welche Partei sie vertreten.
Forward Proxy: steht vor einer Gruppe von Clients. Die Clients wissen von einem Proxy; ein externer Server sieht eine Proxy-Adresse, nicht eine Client-Adresse. Korporative Egress-Proxies, Inhaltsfilter und SOCKS-Proxies passen in dieses Muster.
Reverse Proxy: steht vor einer Gruppe von Servern. Die Außenwelt (Clients) spricht mit einer Proxy-Adresse; die Clients haben keine Ahnung, dass ein echter Server hinter ihr verborgen ist. Fast jeder öffentliche Web-Service verwendet einen.
Merke: Ein Forward-Proxy versteckt Clients vor Servern. Ein Reverse-Proxy versteckt Server vor Clients.
Warum sollte man sich um die Richtung kümmern? Die Arbeit, die Fehlerarten und der Sicherheitsbereich unterscheiden sich. Ein Forward-Proxy kümmert sich darum, mit wem seine Benutzer kommunizieren; ein Reverse-Proxy kümmert sich darum, mit wem seine Server kommunizieren.
Ein Client, der Daten durch beide Arten gleichzeitig sendet, reist: client -> forward_proxy -> Internet -> reverse_proxy -> Ursprung.
Warum so viel am Rand lebt
Die Kanten-Schicht verdient ihr Geld
Ein umgekehrter Proxy führt gleichzeitig drei Aufgaben aus. Jede einzelne rechtfertigt die Schicht; die Ausführung aller drei an derselben Adresse erklärt, warum fast jede Produktions-Web-Architektur die gleiche Form am Front hat.
Aufgabe 1: Versteck die Ursprungsschicht. Die Proxy antwortet auf eine öffentliche IP. Die Backends befinden sich auf privaten IP-Adressen, die das Internet nicht erreichen kann. Ein Angreifer, der die Ursprungsschicht angreifen möchte, muss zuvor den Proxy kompromitieren.
Aufgabe 2: Beenden des TLS. Die Proxy hält das Zertifikat für example.com und entschlüsselt eingehende HTTPS-Anfragen. Die Backends sprechen im flachen Netzwerk über ein vertrauenswürdiges Segment HTTP (oder einfacheren internen TLS) zur Proxy. Zertifikatsrotation, -erneuerung und -Politik sind an einem Ort.
Aufgabe 3: Lastverteilung. Die Proxy entscheidet, welche Backend jede Anfrage bearbeitet. Backends hinter einer Proxy bilden eine Pool; die Proxy wählt eine pro Anfrage, indem sie eine Strategie verwendet (Rundenwiederholung, least-connections, Hash in einem Header). Hinzufügen von Kapazität bedeutet Hinzufügen eines Backends zum Pool, nicht erzählen Sie jedem Client eine neue Adresse.
Jede Aufgabe ist ein kleines Programm. Zusammen erklären sie, warum eine Ebene so einfach wie 'Caddy vor einer Python-Anwendung' mehr Design-Weight trägt als die Python-Anwendung selbst.
Entwerfen für alle drei
Ihr Team betreibt eine kleine API auf einer einzelnen Python-Prozess, der auf Port 8000 einer einzelnen VM lauscht. Der Verkehr hat so stark zugenommen, dass eine VM nicht mehr mitbekommt, und eine Sicherheitsprüfung hat festgestellt, dass die VM eine öffentliche IP hat und selbst TLS-Zertifikat verwaltet.
Sie entscheiden sich für den Einsatz eines umgekehrten Proxys vorne. Skizziere die Layout: Wo zeigt DNS hin, wo liegt das Zertifikat, wie erreicht die Last die Backends und was ändert sich an der ursprünglichen VM?
Ohne dass jemand merkt, einen Bestandteil auszutauschen
Indirektheit kauft Freiheit
Ein altes computerwissenschaftliches Sprichwort besagt: Jedes Problem kann gelöst werden, indem man eine Schicht Indirektheit hinzufügt (außer dem Problem zu viele Schichten von Indirektheit). Der umgekehrte Proxy ist einer der nützlichsten Indirektheiten in verteilten Systemen.
Was es dir gibt:
- Verteilter Backend-Server. Bewegt man die Anwendung von Python zu Go? Migrates von einem Datacenter zu einem anderen? Rollt man eine neue Version mit Null-Downtime aus? Jedes Mal geschieht dies hinter einer stabilen öffentlichen Adresse. Nichts ändert sich für die Benutzer.
- Unabhängiges Skalieren. Die Proxy-Schicht skaliert auf Basis von Bandbreite und CPU auf der TLS-Ebene. Die Backend-Schicht skaliert auf Basis der Anwendung. Jedes wächst auf eigenen Achsen, weil sie auf verschiedenen Maschinen leben.
- Fehlerschließung. Eine schlechte Bereitstellung auf dem Backend bringt die öffentliche Adresse nicht zum Zusammenbrechen. Der Proxy bleibt hoch; man drückt eine Reparatur oder rollt zurück; die Welt verbindet sich wieder, wenn der Backend wiederhergestellt ist.
- Querverknüpfende Aspekte an einem Ort. Geschwindigkeitsbegrenzung, geografische Blockierung, Anforderungsprotokollierung, Kopf-Überschreibung, Zwischenspeicherung, Antwortkomprimierung: All dies befindet sich auf dem Proxy. Backend-Code bleibt auf die Anwendung fokussiert.
Ohne den Proxy müsste jedes dieser Probleme innerhalb des Anwendungprozesses leben. Mit dem Proxy leben sie auf einer Ebene, die eine Team verantwortet.
Der Preis: Eine weitere Schicht zu betreiben. Reife Teams akzeptieren den Preis, weil die Proxy-Schicht selbst stateless ist und horizontal skaliert; durch den Austausch eines Proxys gegen zwei erfordert keine Koordination.
Ein blauer/grüner Deploy durch den Proxy
Dein Team läuft Version 1 der API auf drei Backend-VMs (blaue Pool) hinter einem umgekehrten Proxy. Du möchtest Version 2 bereitstellen, die die Möglichkeit bietet, innerhalb von weniger als dreißig Sekunden zurückzurollt, wenn etwas schiefgeht.
Du startest drei neue Backend-VMs (grüne Pool) mit Version 2, nebenbei mit dem blauen Pool, du leitest aber noch keine Verkehr zu ihnen.
Von Browser zu Backend und zurück
Folgen Sie einer einzelnen HTTPS-GET-Anfrage von https://api.example.com/users/42 durch einen Reverse-Proxy vor einer Backend-Pool.
Spur 1: DNS-Auflösung. Der Browser fragt einen Resolver nach api.example.com . Der Resolver gibt die öffentliche IP-Adresse des Proxys aus (z. B. 203.0.113.10). Der Browser öffnet eine TCP-Verbindung zu 203.0.113.10:443.
Spur 2: TLS-Handshake. Der Proxy stellt sein Zertifikat für api.example.com vor. Der Browser validiert das Zertifikat, die beiden Seiten einigen sich über eine Sitzungsschlüssel und der verschlüsselte Kanal wird geöffnet.
Spur 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.
Spur 4: Auswahl des Backends. Der Proxy fragt seinen Pool für api.example.com nach und wählt ein Backend (z. B. 10.0.0.21:8000) unter Verwendung seiner Lastverteilungsstrategie.
Spur 5: Anfrage an das Backend. Der Proxy öffnet (oder nutzt) eine einfache HTTP-Verbindung zu 10.0.0.21:8000 und leitet die Anfrage weiter. Der Proxy kann Kopfereignisse entlang des Weges umbenennen: fügen Sie X-Forwarded-For: <client-ip> hinzu, stellen Sie Host: korrekt ein, streichen Sie Kopfereignisse wie Connection.
Spur 6: Backend-Verarbeitung. Die Backend-Anwendung liest die Anfrage, fragt die Datenbank ab und erstellt eine JSON-Antwort.
Spur 7: Antwort des Backends. Die Backend sendet die Antwort an den Proxy als einfache HTTP.
Spur 8: Kantenantwort. Der Proxy kann die Antwort umbenennen oder komprimieren, verschlüsselt sie erneut über den TLS-Sitzungsschlüssel und sendet sie an den Browser.
Spur 9: Lebensdauer der Verbindung. Die TLS-Sitzung bleibt in der Regel geöffnet für die nächste Anfrage (HTTP/2 multiplext viele Anfragen über eine Verbindung). Die Proxy-zu-Backend-Verbindung wird oft gepooled für erneute Verwendung.
Jede öffentliche Webdienst folgt einer Variante dieses Musters. Das Verständnis der Sprünge ermöglicht es Ihnen, Latenz zu verstehen, wo Logging gehört und wo ein Fehler verbergen kann.
Wo war die Zeit geblieben?
Ein Benutzer beschwert sich, dass die API langsam fühlt. Sie messen und finden, dass die Anfrage 850 ms von Beginn bis Ende dauert. Server-Logs auf der Backend-Seite zeigen, dass die Anwendung die Anfrage in 40 ms bedient hat. Die Proxy-Logs zeigen, dass der Proxy 50 ms für seine Arbeit (TLS-Handshake + Routing + Antwort-Schreiben) benötigt hat.
Entwerfen Sie ein Minimal-Edge für ein neues Service
Synthese
Sie haben gelernt, was der Unterschied zwischen einem Forward- und Reverse-Proxy ist, die drei Aufgaben, die ein Reverse-Proxy gleichzeitig erledigt, warum das Verstecken des Ursprungs jedes Mal einen Vorteil bringt, wenn Sie etwas ändern müssen, und wie eine Anfrage hop by hop durch die Edge fließt.
Wenden Sie es an.
Ein kleines Team plant die Einrichtung einer neuen Dienst, genannt notes.example.com. Die Benutzer werden persönliche Notizen lesen und schreiben. Das Team wird zwei Backend-VMs bei der Markteinführung betreiben und im Laufe des nächsten Jahres auf zehn erweitern. Sie möchten HTTPS für die Benutzer, eine schrittweise Einführung für neue Versionen und keine öffentliche Offenlegung von Backend-IPs.
Wohin dieses Kurs weitergeht
Wohin geht dieser Kurs weiter
Dieser Unterricht hat die Form der Edge-Schicht festgelegt. Vier weitere Unterrichtseinheiten in diesem Kurs bauen darauf auf:
- Staatenlose Horizontale Skalierung: warum ein Proxy-Tier (& die hinteren Backend-Systeme dahinter) kostengünstig multipliziert werden kann, & die Mathematik für die Größenangaben der Kopien unter Überlastung.
- Trennung von Ingress / Egress: warum eine einzelne Proxy-Box, die sowohl eingehendes als auch ausgehendes Traffic verarbeitet, letztendlich in überraschender Weise versagt und wie man die Schichten trennen kann.
- Fehlertoleranzmodi & Auswirkungsbereich: wie eine einzelne Konfigurationsänderung in einen Ausfall mündet und wie man schuldlose Handlungsempfehlungen erstellt, die eine Wiederholung verhindern.
- Nachverfolgbarkeit & Kapazität: was an der Peripherie messen, um herauszufinden, dass etwas kaputt ist, bevor die Benutzer es merken.
Jeder Lesestand ist unabhängig. Zusammen geben sie dir ein funktionierendes mentalisches Modell einer Flotte im Web-Scale.
Kommunales Lektion: geometry_of_proxies_and_origins stellt alles in dieser Lektion als gerichteten Graphen dar und erkundet, was die Graphentheorie über einen Anforderungsweg erzählt.
Gut gemacht. Weiter so.