Vad som ligger framför nästan varje webbaserad tjänst
Välkommen
Om du skriver in example.com i en webbläsare når du nästan aldrig den maskin som faktiskt kör applikationen. Du når en maskin som vidarebefordrar förfrågan till den som gör det. Den vidarebefordrande maskinen har ett namn: en omvänd proxy.
I denna lektion lär du dig vad en omvänd proxy gör, varför nästan varje offentlig webbaserad tjänst gömmer sig bakom en, och vilka tre uppgifter kantlagret sköter samtidigt.
Till slut kommer du att förstå:
- Skillnaden mellan en klient, en proxy och ett ursprung
- Varför en proxy framför ett ursprung skyddar, skalar och låter dig byta ut komponenter utan att någon märker det
- De tre uppgifterna som en reverse proxy hanterar samtidigt: att dölja ursprunget, att avsluta TLS och att fördela lasten mellan repliker
- Hur en begäran reser från webbläsare till proxy till upstream och tillbaka, hopp för hopp
Till slutet kommer du att resonera självförtroende om proxy-placering, separation of concerns vid kanten och varför en stateless proxy-tier multipliceras billigt medan ett enskilt ursprung inte gör det.
Forward Proxy vs Reverse Proxy
Två proxyriktningar
Båda typerna av proxy står mellan två parter och vidarebefordrar trafik. De skiljer sig åt i vilken part de representerar.
Forward proxy: står framför en grupp klienter. Klienterna känner till proxyn; en extern server ser en proxyadress, inte en klientadress. Företagens utgående proxys, innehållsfilter och SOCKS-proxys passar in i detta mönster.
Reverse proxy: står framför en grupp servrar. Utanför världen (klienterna) kommunicerar med en proxyadress; klienterna har ingen aning om att en riktig server döljer sig bakom den. Nästan varje offentlig webbtjänst använder en.
Minneshjälp: en forward proxy döljer klienter från servrar. En reverse proxy döljer servrar från klienter.
Varför bryr man sig om vilken riktning? Uppgiften, felmoderna och säkerhetsgränsen skiljer sig åt. En forward proxy bryr sig om vem dess användare kontaktar; en reverse proxy bryr sig om vem som kontaktar dess servrar.
En klient som skickar trafik genom båda typerna samtidigt reser: client -> forward_proxy -> internet -> reverse_proxy -> origin.
Varför så mycket finns på kanten
Kantlagret rättfärdigar sitt värde
En reverse proxy sköter tre uppgifter samtidigt. Var och en av dem rättfärdigar lagret; att sköta alla tre på samma adress förklarar varför nästan varje produktionswebbarkitektur ser ut på samma sätt i främre delen.
Uppgift 1: Dölj originalet. Proxyn svarar på en offentlig IP. Bakändar ligger på privata IP-adresser som internet inte kan nå. En angripare som vill träffa originalet måste först kompromettera proxyn.
Uppdrag 2: Avsluta TLS. Proxyn innehåller certifikatet för example.com och avkryptar inkommanda HTTPS-förfrågningar. Bakändarna kommunicerar via ren HTTP (eller enklare intern TLS) med proxyn över ett betroddt nätverkssegment. Certifikatrotation, förnyelse och krypteringspolicy hanteras alltså på en och samma plats.
Uppdrag 3: Fördela lasten. Proxyn väljer vilken bakänd som hanterar varje förfrågan. Bakänderna bakom en proxy bildar en pool; proxyn väljer en per förfrågan med hjälp av en strategi (round-robin, minst anslutningar, hash på en header). Att öka kapaciteten innebär att lägga till en bakänd i poolen, inte att informera varje klient om en ny adress.
Varje uppgift är ett litet program. Tillsammans förklarar de varför ett lager så enkelt som 'Caddy framför en Python-app' bär på mer designvikt än Python-appen själv.
Design för alla tre
Ditt team driver en liten API på en enda Python-process som lyssnar på port 8000 på en enda VM. Trafiken har ökat tillräckligt mycket så att en enda VM inte klarar av att hålla uppe takten, och en säkerhetsgranskning har flaggat att VM:en har en publik IP-adress och kör sitt eget TLS-certifikat.
Du bestämmer dig för att placera en reverse proxy framför. Skissa upp layouten: vart pekar DNS, var ligger certifikatet, hur når lasten bakänderna, och vad ändras med den ursprungliga VM:en?
Byt ut en komponent utan att någon märker det
Indirekthet köper frihet
En gammal sanning inom datavetenskapen säger att varje problem kan lösas genom att lägga till ett lager av indirektion (undantaget problemet med för många lager av indirektion). Reverse proxy är en av de mest användbara formerna av indirektion i distribuerade system.
Vad det ger dig:
- Utbytbara bakändar. Flytta applikationen från Python till Go? Migrera från ett datacenter till ett annat? Rulla ut en ny version med noll nedtid? Varje händelse sker bakom en stabil publik adress. Ingenting ändras för användarna.
- Oberoende skalning. Proxy-lagret skalar baserat på bandbredd och CPU på TLS-lagret. Bakändelagret skalar baserat på applikationens arbete. Varje del växer på sin egen axel eftersom de finns på olika maskiner.
- Felskärmande. En dålig deploy på bakänden slår inte ut den publika adressen. Proxyn håller sig uppe; du skickar en fix eller gör en rollback; världen återansluts när bakänden återhämtar sig.
- Tvärgående frågor på ett ställe. Rate limiting, geo-blockering, request-loggning, header-omskrivning, caching, svarskomprimering: allt finns på proxyn. Bakändekoden håller sig fokuserad på applikationen.
Utan proxyn måste varje ett av dessa problem finnas inuti applikationsprocessen. Med proxyn finns de på ett lager som ett team äger.
Kostnaden: ett lager till att driva. Mognade team accepterar kostnaden eftersom proxy-lagret självt körs stateless och skalar horisontellt; att byta ut en proxy mot två kräver ingen samordning.
En blå/grön deployment via proxy
Ditt team kör version 1 av API:t på tre bakändes-VM:er (blå pool) bakom en reverse proxy. Ni vill deploya version 2 med möjlighet att rulla tillbaka på under trettio sekunder om något går fel.
Ni startar tre nya bakändes-VM:er (grön pool) som kör version 2, parallellt med den blå poolen, men ni routar ännu ingen trafik till dem.
Från webbläsare till backend och tillbaka
Följ en förfrågan från början till slut
Följ en enskild HTTPS GET-förfrågan av https://api.example.com/users/42 genom en omvänd proxy framför en backend-pool.
Hopp 1: DNS-uppslagning. Webbläsaren frågar en resolver om api.example.com. Returnerar proxyns publika IP-adress (t.ex. 203.0.113.10). Webbläsaren öppnar en TCP-anslutning till 203.0.113.10:443.
Hopp 2: TLS-handskakning. Proxyn presenterar sitt certifikat för api.example.com. Webbläsaren validerar certifikatet, parterna kommer överens om en sessionsskyl och den krypterade kanalen öppnas.
Hopp 3: HTTP-förfrågan inuti TLS. Webbläsaren skickar GET /users/42 HTTP/1.1\nHost: api.example.com\n.... Proxyn avkrypterar förfrågnets byte.
Hopp 4: Backendval. Proxyn konsulterar sin pool av upstream-mål för api.example.com & väljer en backend (t.ex. 10.0.0.21:8000) med hjälp av sin lastbalanseringsstrategi.
Hopp 5: Upstream-anfrågan. Proxyn öppnar (eller återanvänder) en vanlig HTTP-anslutning till 10.0.0.21:8000 & vidarebefordrar anfrågan. Proxyn kan skriva om huvuden under vägen: lägga till X-Forwarded-For: <client-ip>, sätta Host: korrekt, ta bort hop-by-hop-huvuden som Connection.
Hopp 6: Backendbehandling. Backendapplikationen läser anfrågan, frågar sin databas & bygger ett JSON-svar.
Hopp 7: Upstream-svar. Backenden skickar svaret tillbaka till proxyn som vanlig HTTP.
Hopp 8: Edge-svar. Proxyn kan skriva om eller komprimera svaret, krypterar det tillbaka via TLS-sessionen & skickar det till webbläsaren.
Hopp 9: Anslutningens livscykel. TLS-sessionen hålls vanligtvis öppen för nästa anfrågan (HTTP/2 multiplexerar många anfrågningar på en anslutning). Anslutningen mellan proxy och backend poolas ofta för återanvändning.
Alla publika webbaserade tjänster följer någon variant av denna struktur. Att känna till hopparna gör att du kan resonera om var latens ackumuleras, var loggning hör hemma & var ett fel kan dölja sig.
Vart tog tiden vägen?
En användare klagar på att API:et känns långsamt. Du mäter och upptäcker att förfrågan tar 850 ms från början till slut. Serverloggar på bakänden visar att tillämpningen hanterade förfrågan på 40 ms. Proxyloggarna visar att proxyn tillbringade 50 ms med sitt arbete (TLS-handskakning + routning + skrivning av svarsdata).
Designa en minimal kant för en ny tjänst
Sammanfattning
Du har lärt dig skillnaden mellan en framåt- och en omvänd proxy, de tre uppgifter som en omvänd proxy hanterar samtidigt, varför att dölja ursprunget ger fördelar varje gång du behöver ändra något, och hur en begäran flödar hopp för hopp genom kanten.
Nu tillämpar du det.
Ett litet team planerar att lansera en ny tjänst som heter notes.example.com. Användare kommer att läsa och skriva personliga anteckningar. Teamet kommer att köra två bakändeservrar (VM) vid lanseringen och förväntar sig att skala upp till tio under det kommande året. De vill ha HTTPS för användare, gradvis rullning ut för nya versioner, och ingen offentlig exponering av bakändens IP-adresser.
Vart denna kurs går vidare
Vart denna kurs går vidare
Denna lektion etablerade formen av kantlagret. Ytterligare fyra lektioner i denna kurs bygger på det:
- Stateless horisontell skalning: varför en proxytjänst (och bakändarna bakom den) multipliceras billigt, & matematiken för att dimensionera antalet repliker vid lastspikar.
- Separation av ingress/egress: varför en enda proxybox som hanterar både inkommande & utgående trafik till slut misslyckas på överraskande sätt, & hur man delar upp lagren.
- Felmoder & spridningsomfång: hur en enda konfigurationsändring kan leda till ett systemavbrott, och hur man skriver skuldfrifriande åtgärder som förhindrar att problemet upprepas.
- Observabilitet & kapacitet: vad man ska mäta vid kanten så att man upptäcker att något är trasigt innan användarna gör det.
Varje lektion står på egna ben. Tagna tillsammans ger de dig en fungerande mental modell av en webbskala-flottilla.
Systerlektion: geometry_of_proxies_and_origins omformulerar allt i denna lektion som en riktad graf och utforskar vad grafteori säger om en begärningsväg.
Bra jobbat. Framåt.