Wat staat voor bijna elke webdienst
Welkom
Als je example.com intoetst in een browser, kom je bijna nooit rechtstreeks in contact met de machine die de toepassing daadwerkelijk uitvoert. Je komt in contact met een machine die de aanvraag doorstuurt naar een die dat wel doet. Die doorsturende machine draagt een naam: een omgekeerde proxy.
Dit lesje leert wat een omgekeerde proxy doet, waarom bijna elke publieke webdienst er een voor staat, en welke drie taken de randlaag tegelijkertijd uitvoert.
Na het lezen begrijp je:
- De verschillen tussen een klant, een proxy en een oorsprong
- Waarom een proxy voor een oorsprong beschermt, schaalbaar maakt en je stukjes kunt vervangen zonder dat iemand het merkt
- De drie taken die een omgekeerde proxy tegelijkertijd uitvoert: het verbergen van de oorsprong, het beëindigen van TLS en het verdelen van de belasting over replica's
- Hoe een aanvraag reist van de browser naar de proxy, naar upstream en terug, stap voor stap
Na het lezen redeneer je met vertrouwen over de plaatsing van proxies, de scheiding van zorgen op de rand en waarom een stateless proxy laag zich goed vermenigvuldigt terwijl een enkele oorsprong niet doet.
Voorwaartse Proxy vs Omgekeerde Proxy
Twee richtingen van proxy's
Beide soorten proxy staan tussen twee partijen en verlenen verkeer. Ze verschillen in welke partij ze vertegenwoordigen.
Voorwaartse proxy: staat voor een groep klanten. De klanten weten van een proxy; een externe server ziet een proxyadres, niet een klantadres. Corporatieve uitgangsproxys, inhoudsfilteringen en SOCKS proxys passen in dit patroon.
Omgekeerde proxy: staat voor een groep servers. De buitenwereld (klanten) praat met een proxyadres; klanten weten niet dat een echte server achter hem schuilgaat. Bijna elke publieke webdienst maakt gebruik van een.
Herinneringshulpmiddel: een voorwaartse proxy verbergt klanten voor servers. Een omgekeerde proxy verbergt servers voor klanten.
Waarom zou je je druk maken over de richting? De taak, de foutmodi en de beveiligingsgrens verschillen. Een voorwaartse proxy zorgt ervoor wie zijn gebruikers contacteert; een omgekeerde proxy zorgt ervoor wie contact met zijn servers maakt.
Een klant die verkeer verzendt via beide soorten tegelijk reist: klant -> voorwaartse_proxy -> internet -> omgekeerde_proxy -> oorsprong.
Waarom Er Zo Veel Leeft op de Rand
De Randlaag Verdient Zijn Brood
Een omgekeerde proxy verricht drie taken op hetzelfde moment. Elke van hen rechtvaardigt de laag; het uitvoeren van alle drie legt uit waarom bijna elke productie-webarchitectuur hetzelfde uiterlijk heeft aan de voorkant.
Taak 1: Verbergen van de oorsprong. De proxy antwoordt op een openbare IP. Achtersten zitten op private IPs die de internet niet kunnen bereiken. Een aanvaller die de oorsprong wil raken, moet eerst de proxy compromitteren.
Taak 2: Beéùndigen van TLS. De proxy houdt het certificaat voor example.com en decripteert inkomende HTTPS-verzoeken. Achtersten spreken gewoon HTTP (of eenvoudiger interne TLS) met de proxy over een vertrouwde netwerksegment. Certificaatrotatie, hernieuwing en cipherbeleid zijn op een plaats.
Taak 3: Belading verdelen. De proxy kiest welke backend elke aanvraag behandelt. Backends achter een proxy vormen een pool; de proxy kiest er een per aanvraag met een strategie (ronde-robin, minst-verbindingen, hash op een header). Het toevoegen van capaciteit betekent het toevoegen van een backend aan de pool, niet het vertellen aan elk client een nieuwe adres.
Elke taak is een klein programma. Samen leggen ze uit waarom een laag zo eenvoudig als 'Caddy voor een Python-toepassing' meer ontwerpgewicht draagt dan de Python-toepassing zelf.
Ontwerpen voor Alle Drie
Uw team draait een klein API op een enkel Pythonproces dat luistert op poort 8000 op een enkele VM. Verkeer is toegenomen, waardoor een enkele VM niet meer bij kan en een beveiligingsbeoordeling wees dat de VM een openbare IP heeft en zijn eigen TLS-certificaat host.
U besluit een omgekeerde proxy voor te zetten. Schets de opzet: waar wijst DNS naar, waar ligt het certificaat, hoe bereikt de belading de backends en wat verandert er over de oorspronkelijke VM?
Een Component Wisselen Zonder Dat Iemand Het Merkt
Afdwinging Koopt Vrijheid
Een oude computer-wetenschap gezegde luidt: elke probleem kan opgelost worden door een laag indirection toe te voegen (behalve het probleem van te veel lagen indirection). De omgekeerde proxy is een van de nuttigste indirections in gedistribueerde systemen.
Wat het je oplevert:
- Wisselbare achtervoeten. Verplaats de toepassing van Python naar Go? Migreren van één datacenter naar een ander? Implementeer een nieuwe versie met zero downtime? Elk van deze acties vindt plaats achter een stabiele publieke adres. Niets verandert voor de gebruikers.
- Onafhankelijke schaling. De proxy-tier schaalt op bandbreedte & CPU op het TLS-niveau. De achtervoet-tier schaalt op toepassingswerk. Elk groeit op zijn eigen as omdat ze leven op verschillende machines.
- Ongedekte fouten. Een slechte implementatie op de achtervoet doet de publieke adres niet uitvallen. De proxy blijft up; u duwt een oplossing of gaat terug; de wereld herverbindt zich wanneer de achtervoet herstelt.
- Overkoepelende zorgen in één plaats. Beperking van de toegang, blokkeren op basis van locatie, verzoeklogboeken, headerwijzigingen, caching, antwoordcompressie: alles vindt plaats op de proxy. Backend-code blijft zich richten op de toepassing.
Zonder de proxy moet elk van deze problemen leven binnen het toepassingsproces. Met de proxy leven ze op één laag die één team beheert.
De kosten: nog een laag om te beheren. Gevestigde teams accepteren de kosten omdat de proxy-tier zelf staatloos en horizontaal schaalt; vervangen van één proxy door twee vereist geen coördinatie.
Een Blauw/Groen Deploy Door de Proxy
Uw team draait versie 1 van de API op drie achtervoet-VM's (blauwe poel) achter een omgekeerde proxy. U wilt versie 2 implementeren met de mogelijkheid om binnen dertig seconden terug te gaan als iets misgaat.
U lanceert drie nieuwe achtervoet-VM's (groene poel) die versie 2 draaien, naast de blauwe poel, maar u routeert nog geen verkeer naar hen toe.
Van Browser naar Backend & Terug
Volg Één Aanvraag van Begin tot Einde
Volg een enkele HTTPS GET van https://api.example.com/users/42 door een omgekeerde proxy voor een backendpool.
Sprong 1: DNS-oplossing. De browser vraagt een resolver om api.example.com. De resolver geeft de openbare IP van de proxy weer (bijvoorbeeld 203.0.113.10). De browser opent een TCP-verbinding met 203.0.113.10:443.
Sprong 2: TLS-handshake. De proxy presenteert haar certificaat voor api.example.com. De browser valideert het certificaat, de twee partijen komen uit over een sessie-sleutel en opent het versleutelde kanaal.
Sprong 3: HTTP-aanvraag binnen TLS. De browser stuurt GET /users/42 HTTP/1.1\nHost: api.example.com\n.... De proxy versleutelt de aanvraagbytes.
Sprong 4: Backendselectie. De proxy raadpleegt zijn upstream-pool voor api.example.com en kiest een backend (bijvoorbeeld 10.0.0.21:8000) op basis van zijn belastingheffingsstrategie.
Sprong 5: Stroomopwaartse aanvraag. De proxy opent (of hergebruikt) een eenvoudige HTTP-verbinding met 10.0.0.21:8000 en verstuurt de aanvraag. De proxy kan hoofdregels wijzigen op de weg: voeg X-Forwarded-For: <client-ip> toe, zet Host: correct, verwijder sprongetjes-hoofdregels zoals Connection.
Sprong 6: Backendverwerking. De backend-toepassing leest de aanvraag, raadpleegt zijn database en bouwt een JSON-antwoord.
Sprong 7: Stroomopwaartse reactie. De backend stuurt het antwoord terug naar de proxy als eenvoudig HTTP.
Sprong 8: Randantwoord. De proxy kan de reactie herschrijven of comprimeren, versleutelt het opnieuw via de TLS-sessie en stuurt het naar de browser.
Sprong 9: Levenscyclus van de verbinding. De TLS-sessie blijft meestal open voor de volgende aanvraag (HTTP/2 multiplext meerdere aanvragen op één verbinding). De proxy-naar-backendverbinding wordt vaak gepooled voor hergebruik.
Elke openbare webdienst volgt een variant van deze vorm. Het weten van de sprongen laat je redeneren over waar vertraging opbouwt, waar logboeken horen en waar een fout kan verbergen.
Waar Is De Tijd Gebleven?
Een gebruiker klaagt dat de API trager aanvoelt. Je meet en ontdekt dat de aanvraag 850 ms kost van begin tot eind. Serverlogs op de back-end tonen dat de toepassing de aanvraag in 40 ms heeft verwerkt. De proxylogs tonen dat de proxy 50 ms heeft besteed aan zijn kant van de werkzaamheden (TLS-handshake + routing + antwoord schrijven).
Ontwerp een Minimale Rand voor een Nieuwe Service
Samenvatting
Je hebt geleerd wat de verschillen zijn tussen een voorwaarts en een omgekeerd proxy, de drie taken die een omgekeerde proxy tegelijkertijd uitvoert, waarom het verbergen van de oorsprong voordelen oplevert elke keer als je iets moet veranderen, en hoe een aanvraag stap voor stap door de rand heen stroomt.
En nu toepassen.
Een kleine groep plannen om een nieuwe service met de naam notes.example.com te lanceren. Gebruikers zullen persoonlijke notities lezen en schrijven. De groep gaat twee back-end VM's lanceren en verwacht het te schalen naar tien over de volgende jaar. Ze willen HTTPS voor gebruikers, geleidelijke uitrol voor nieuwe versies en geen openbare blootstelling van back-end IPs.
Waar Dit Cursus Naar Toe Gaat
Waar Dit Cursus Naar Toe Gaat
Deze les heeft de vorm van de randlaag vastgesteld. Vier andere lessen in deze cursus bouwen hierop:
- Staatloze Horizontale Schaling: waarom een proxy laag (& de backends erachter) zich goedkoop vermenigvuldigt, & de wiskunde voor het grootten van replica's onder druk.
- Ingress / Egress Splitsing: waarom een enkele proxy box die zowel inkomende als uitgaande verkeer behandelt uiteindelijk faalt op verbazingwekkende manieren, & hoe de lagen te splitsen.
- Foutmodi & Explosiegebied: hoe een enkele configuratie wijziging uitloopt in een storing, & hoe je schuldloze actiepunten kunt schrijven die herhaling voorkomen.
- Zichtbaarheid & Capaciteit: wat op de rand moet worden gemeten zodat je merkt dat iets kapot is voordat de gebruikers dat doen.
Elke les staat apart. Genomen samen geven ze je een functioneel mentaal model van een web-schaal vloot.
Bijles: geometry_of_proxies_and_origins zet alles in deze les om in een gecoordineerde grafiek & verkent wat grafentheorie je vertelt over een verzoek pad.
Goed gedaan. Verder.