Vad som står framför nästan varje webbtjänst
Välkommen
Om du skriver in example.com i en webbläsare når du sällan maskinen som faktiskt kör applikationen. Du når en maskin som framför begäran till en som gör det. Den maskinen som förfaller begäran kallas för en revers proxy.
Den här lektionen lär dig vad en revers proxy gör, varför nästan varje publikt webbtjänst döljer sig bakom en och vilka tre uppgifter kantlagret hanterar samtidigt.
Efteråt kommer du att förstå:
- Skillnaden mellan en klient, en proxy och en ursprung
- Varför en proxy framför en ursprung skyddar, skalar och låter dig byta delar utan att någon märker det
- De tre uppgifter en revers proxy hanterar samtidigt: dölja ursprunget, avsluta TLS och fördela belastningen över repliker
- Hur en begäran reser sig från webbläsare till proxy till upstream och tillbaka, hopp för hopp
Efteråt kommer du att kunna resonera säkert om placering av proxyer, separation av orostillstånd på kanten och varför en stateless proxy tier multipliceras billigt medan en enda ursprung inte gör det.
Forward Proxy vs Revers Proxy
Två Proxy Riktningar
Båda typerna av proxy står mellan två parter och överför trafik. De skiljer sig åt vilken part de representerar.
Forward proxy: står framför en grupp av klienter. Klienterna vet om en proxy; en extern server ser en proxyadress, inte en klientadress. Korporativa utgångsproxies, innehållsfiltret och SOCKS proxyn passar in i detta mönster.
Revers proxy: står framför en grupp av servrar. Den yttre världen (klienter) pratar med en proxyadress; klienterna har ingen aning om att en riktig server döljer sig bakom den. Nästan varje publikt webbtjänst använder en.
Mnemoniskt hjälpmedel: en forward proxy döljer klienter från servrar. En revers proxy döljer servrar från klienter.
Varför bry dig om vilken riktning? Jobbet, felmoderna och säkerhetsgränsen skiljer sig åt. En forward proxy orkar om vilka dess användare kontaktar; en revers proxy orkar om vilka kontakter dess servrar.
En klient som skickar trafik genom båda typerna samtidigt reser: klient -> forward_proxy -> internet -> revers_proxy -> ursprung.
Varför Så Mycket Finns på Kanten
Kantskiktet Får Sitt Uppehälle
En omvänd proxy utför tre jobb samtidigt. Varje av dem förtjänar lagret; att utföra alla tre på samma adress förklarar varför nästan varje produktionssida ser ut samma form på framsidan.
Jobb 1: Dölj ursprunget. Proxy-anropet svarar på en offentlig IP. Bakänderna ligger på privata IP:er som internet inte kan nå. En attacker som vill träffa ursprunget måste först kompromissa proxy.
Jobb 2: Avsluta TLS. Proxy-håller certifikatet för example.com & avkrypterar inkommande HTTPS-ansökningar. Bakänderna talar enkelt HTTP (eller enklare inre TLS) till proxy över en förtroendeinrättad nätverkssegment. Certifikatuppdatering, förlängning & chifferpolicy finns på en plats.
Jobb 3: Fördela belastningen. Proxy väljer vilken bakänd som hanterar varje begäran. Bakänderna bakom en proxy bildar en pool; proxy väljer en per begäran enligt en strategi (rund-tur, minst-anslutningar, hash på en rubrik). Att lägga till kapacitet innebär att lägga till en bakänd i poolen, inte berätta för varje klient en ny adress.
Varje jobb är ett litet program. Tillsammans förklarar de varför en våning som enkel som 'Caddy framför en Python-app' bär mer designvikt än Python-appen själv.
Designa för Alla Tre
Ditt team kör en liten API på en enda Python-process som lyssnar på port 8000 på en enda VM. Traffiken har växt så att en enda VM inte kan hålla tempo & en säkerhetsgranskning flaggade att VM har en offentlig IP & hanterar sin egen TLS-certifikat.
Du bestämmer dig för att sätta in en omvänd proxy framför. Teckna layouten: var pekar DNS, var ligger certifikatet, hur når belastningen bakänderna & vad förändras det om den ursprungliga VM?
Byt Ut En Komponent Utan Att Någon Märker Av Det
Indirektionskraft Köper Frihet
En gammal datorvetenskaplig adag har: varje problem kan lösas genom att lägga till en lager av indirektions (utom problemet med för många lager av indirektions). Den reverserade proxy är ett av de mest användbara indirektionerna i distribuerade system.
Vad det köper dig:
- Bytebara backends. Flytta applikationen från Python till Go? Migrera från ett datacenter till ett annat? Rolla ut en ny version med noll nedtida? Varje en sker bakom en stabil offentlig adress. Inget ändras för användarna.
- Oberoende skalning. Proxytjänsten skalar på bandbredd och CPU på TLS-nivån. Back-end-tjänsten skalar på applikationsarbete. Båda växer på egna axlar eftersom de finns på olika maskiner.
- Felcontainment. Ett dåligt distribuering på back-end gör inte nätverksadressen obrukbar. Proxy-nivån stannar kvar; du drar en åtgärd eller återvänder; världen kopplar återigen samman när back-end återhämtar sig.
- Tvärfunktionsuppgifter på ett ställe. Hastighetsgräns, geo-blockering, begäran logga, rubrik omskrivning, cachning, svars komprimering: allt finns på proxy. Back-end-koden håller sig fokuserad på applikationen.
utan proxy måste varje problem finnas inne i applikationsprocessen. Med proxy finns de på en nivå som en team äger.
Kostnaden: ett annat lager att driva. Mognade team accepterar kostnaden eftersom proxy-tjänsten själv körs stateless och skalar horisontellt; ersätter du en proxy med två krävs ingen koordinering.
En Blå/Green Distribuering Genom Proxy
Ditt team kör version 1 av API:et på tre back-end-VM:er (blå pool) bakom en reverserad proxy. Du vill deploya version 2 med möjlighet att dra tillbaka inom trettio sekunder om något går fel.
Du startar tre nya back-end-VM:er (gröna pool) som kör version 2, sida vid sida med den blå poolen, men du riktar ännu inte någon trafik till dem.
Från Browser till Backend & Tillbaka
Följ En Begäran Från Start till Mållinje
Spårade en enda HTTPS GET av https://api.example.com/users/42 genom en reversproxy framför en bakomliggande pool.
Hopp 1: DNS-upplösning. Browsern frågar en upplösare om api.example.com. Upplösaren returnerar proxyns offentliga IP (säg, 203.0.113.10). Browsern öppnar en TCP-anslutning till 203.0.113.10:443.
Hopp 2: TLS-handskaken. Proxyn presenterar sin certifikat för api.example.com. Browsern validerar certifikatet, och sidorna kommer överens om en sessionsnyckel, och den krypterade kanalen öppnas.
Hopp 3: HTTP-begäran inom TLS. Browsern skickar GET /users/42 HTTP/1.1\nHost: api.example.com\n.... Proxyn krypterar begäran bytes.
Hopp 4: Bakåtval. Proxyn råder över sin uppsättning bakåt för api.example.com och väljer en bakåt (säg 10.0.0.21:8000) enligt sin belastningsutjämningstrategi.
Hopp 5: Uppströmsbegäran. Proxyn öppnar (eller återanvänder) en vanlig HTTP-anslutning till 10.0.0.21:8000 och skickar över begäran. Proxyn kan ändra huvudrubrikerna under vägen: lägga till X-Forwarded-For: <client-ip>, ställa in Host: korrekt, ta bort hopp-av-hopp-huvudrubriker som Connection.
Hopp 5: Uppströmsbegäran. Proxyn öppnar (eller återanvänder) en vanlig HTTP-anslutning till 10.0.0.21:8000 och skickar över begäran. Proxyn kan ändra huvudrubrikerna under vägen: lägga till X-Forwarded-For: <client-ip>, ställa in Host: korrekt, ta bort hopp-av-hopp-huvudrubriker som Connection.
Hopp 6: Bakåtbehandlig. Bakåtapplikationen läser begäran, frågar sin databas och bygger en JSON-svar.
Hopp 7: Uppströms-svar. Bakåtappen skickar svar tillbaka till proxyn som vanlig HTTP.
Hopp 8: Kanten svar. Proxyn kan ändra eller komprimera svaret, krypterar det tillbaka genom TLS-sessionen och skickar tillbaka till browsern.
Varje publikt webbtjänst följer någon variant av denna form. Vet du hopp kan du resonera om var latensen ackumuleras, var loggning hör hemma och var en fel kan dölja.
Var Har Tiden Gått?
En användare anmäler att API:et känns trångt. Du mäter och hittar att begäran tar 850 ms från och med slutförandet. Serverloggar på backend visar att applikationen hanterade begäran på 40 ms. Proxyloggar visar att proxy:n använde 50 ms för sitt arbete (TLS-handskak, routing och svarsskrivning).
Designa en Minimal Edge för ett Nytt Tjänst
Sammanfogning
Du har lärt dig skillnaden mellan en forward- och en reversproxy, de tre jobb en reversproxy hanterar samtidigt, varför du döljer ursprunget varenda gång du behöver ändra något, och hur en begäran flyter hopp efter hopp genom kanten.
Använd det nu.
En liten grupp planerar att lansera ett nytt tjänst kallad notes.example.com. Användarna kommer att läsa och skriva personliga anteckningar. Lagret kommer att köra två backend-VM: er vid lansering och förväntar sig att skala till tio under nästa år. De vill ha HTTPS för användare, successiva rollout för nya versioner och ingen offentlig exponering av backend-IP: er.
Vart den här kursen går vidare
Vart den här kursen går vidare
Den här lektionen etablerade formen på kantlagret. Fyra fler lektioner i den här kursen bygger på det:
- Stateless Horisontell Skalning: varför en proxy-nivå (& de bakända som ligger bakom den) multipliceras billigt, & matematiken för att dimensionera replikantal under storm.
- Ingress / Egress Separation: varför en enda proxy-enhet som hanterar både inkommande & utgående trafik slutar att fungera på oväntade sätt, & hur man skiljer lager.
- Felsläpp & Spridningsområde: hur en enda konfigurationsändring sprider sig till en avstängning & hur man skriver utan skyldighet åtgärder som förebygger upprepning.
- Övervakbarhet & Kapacitet: vad du ska mäta på kanten så att du upptäcker att något är trasigt innan användarna gör det.
Varje lektion står själv. Tagna tillsammans ger de dig en fungerande mental modell för en webb-skala flotta.
Kompletterande lektion: geometry_of_proxies_and_origins omformar allt i denna lektion till en riktad graff & utforskar vad grafteori berättar för dig om en begäran väg.
Bra jobbat. Vidare.