Wat Zit Voor Bijna Elke Webdienst
Welkom
Als je example.com intoetst in een browser, bereik je bijna nooit de machine die de toepassing daadwerkelijk uitvoert. Je bereikt een machine die de aanvraag doorstuurt naar een die dat doet. Die doorvoeringsmachine draagt een naam: een omgekeerde proxy.
Dit les onderwijst wat een omgekeerde proxy doet, waarom bijna elke publieke webdienst erachter verschuilt, en wat drie taken de randlaag tegelijkertijd uitvoert.
Na het einde zult u begrijpen:
- De verschillen tussen een klant, een proxy en een oorsprong
- Waarom een proxy voor een oorsprong beschermt, schaalbaarheid biedt en stukjes kunt wisselen zonder dat iemand dat 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 kopieën
- Hoe een aanvraag reist van browser naar proxy naar upstream en terug, stap voor stap
Na het einde kunt u met vertrouwen redeneren over de plaatsing van proxies, de scheiding van zorgen op de rand en waarom een proxylaag die staatloos is, zich goed deelt, terwijl een enkele oorsprong dat niet doet.
Omvorende Proxy vs Voorwaartse Proxy
Twee Richtingen van Proxy
Beide soorten proxy staan tussen twee partijen en houden verkeer vast. Ze verschillen in welke partij ze vertegenwoordigen.
Voorwaartse proxy: staat voor een groep van klanten. De klanten weten van een proxy; een externe server ziet een proxyadres, niet een klantadres. Egressproxies voor bedrijven, inhoudsfilters en SOCKSproxies passen in dit patroon.
Omvorende proxy: staat voor een groep van servers. De buitenwereld (klanten) praat met een proxyadres; klanten weten niet dat een echte server achter hem verscholen zit. Bijna elke publieke webdienst gebruikt er een.
Mnemonica: een voorwaartse proxy verbergt klanten van servers. Een omvorende proxy verbergt servers van klanten.
Waarom zorgen over de richting? De taak, de faliekolommodi en de veiligheidsgrens verschillen. Een voorwaartse proxy zorgt over wie zijn gebruikers contacten; een omvorende proxy zorgt over wie contact maakt met zijn servers.
Een klant die verkeer door beide soorten heen stuurt: klant -> voorwaartse_proxy -> internet -> omvorende_proxy -> oorsprong.
Waarom Er Zo Veel Leeft aan de Rand
De Edge Laag Verdiend Zijn
Een omgekeerd proxy voert drie banen tegelijk uit. Elke van hen rechtvaardigt de laag; het uitvoeren van alle drie op dezelfde adres verklaart waarom bijna elke productie webarchitectuur dezelfde vorm heeft aan de voorkant.
Baan 1: Verbergen van het oorsprong. De proxy antwoordt op een openbare IP. Achtersten zitten op private IPs die het internet niet kan bereiken. Een aanvaller die het oorspronkelijke doel wil raken, moet eerst de proxy compromitteren.
Baan 2: Beëindigen van TLS. De proxy houdt het certificaat voor example.com en onderschept inkomende HTTPS-verzoeken. Achtersten spreken gewoon HTTP (of eenvoudiger interne TLS) naar de proxy over een vertrouwde netwerksnelheid. Certificaatrotatie, vernieuwing en cipherbeleid zijn op een plek.
Baan 3: Belasting verdelen. De proxy kiest welke backend elke aanvraag behandelt. Backends achter één proxy vormen een pool; de proxy kiest er één per aanvraag uit met een strategie (ronde-rooster, 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 baan is een klein programma. Samen verklaan ze waarom een laag als 'Caddy voor een Python-toepassing' meer ontwerpcapaciteiten draagt dan de Python-toepassing zelf.
Ontwerpen Voor Alle Drie
Je team draait een kleine API op een enkel Pythonproces dat luistert op poort 8000 op een enkel VM. Door het verkeer is de VM niet meer toereikend, & een beveiligheidsreview wees dat de VM een openbare IP heeft & zijn eigen TLS-certificaat aanbiedt.
Je besluit een omgekeerd proxy voor te zetten. Schets de opzet: waar wijst DNS, waar woont het certificaat, hoe bereikt de belasting de backends & wat verandert er over het oorspronkelijke VM?
Zonder dat Iemand Het Merkt een Component Wisselen
Afbakening Koop Vrijheid
Een oude computer-wetenschappelijke spreekwoord houdt: elke probleem kan worden opgelost door een laag afbakening toe te voegen (behalve het probleem van te veel lagen afbakening). De omgekeerde proxy is een van de nuttigste afbakening in gedistribueerde systemen.
Wat het je koopt:
- Wisselbare achterste. Verplaats de toepassing van Python naar Go? Migreren van één datacenter naar een ander? Implementeer een nieuwe versie met zero downtime? Elk gebeurt achter een stabiele publieke adres. Niets verandert voor gebruikers.
- Onafhankelijke schaling. De proxy-laag schaalt op bandbreedte & CPU op het TLS-niveau. De achterste laag schaalt op toepassingswerk. Elke groeit op zijn eigen as omdat ze leven op verschillende machines.
- Ongemak opsluiten. Een slechte implementatie op de achterste doet niet uit. De proxy blijft up; je duwt een correctie of maakt een rollback; de wereld herconnect zich wanneer de achterste herstelt.
- Overkruisende zorgen in één plaats. Beperking, geblokkeerde gebieden, aanvraaglogboeken, headerwijzigingen, caching, responscompressie: allemaal op de proxy. Achterste code blijft zich richten op de toepassing.
Zonder de proxy elke van deze problemen moet leven binnen het toepassingsproces. Met de proxy leven ze op één laag die één team bezit.
De kosten: een andere laag om te bedrijven. Gevestigde teams accepteren de kosten omdat de proxy-laag zelf staatloos en schaalt horizontaal; vervangen van één proxy met twee vereist geen coördinatie.
Een Blauw/Groen Deploy Door de Proxy
Je team runt versie 1 van de API op drie achterste VM's (blauwe poel) achter een omgekeerde proxy. Je wilt versie 2 implementeren met de mogelijkheid om snel terug te rollen als iets misgaat.
Je lanceert drie nieuwe achterste VM's (groene poel) die versie 2 draaien, naast de blauwe poel, maar je stuurt nog geen verkeer naar ze.
Van Browser tot 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 achtervoetpool.
Hop 1: DNS-resolutie. 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.
Hop 2: TLS-handshake. De proxy presenteert zijn certificaat voor api.example.com. De browser valideert het certificaat, en de twee zijden komen overeen over een sessiesleutel, waarna het versleutelde kanaal geopend wordt.
Hop 3: HTTP-aanvraag binnen TLS. De browser stuurt GET /users/42 HTTP/1.1\nHost: api.example.com\n.... De proxy decripteert de aanvraagbytes.
Hop 4: Achtervoetaanvraag. De proxy raadpleegt zijn upstream-pool voor api.example.com en kiest een achtervoet (bijvoorbeeld 10.0.0.21:8000) op basis van zijn belastingsstrategie.
Hop 5: Upstream-aanvraag. De proxy opent (of hergebruikt) een eenvoudige HTTP-verbinding met 10.0.0.21:8000 en verstrekt de aanvraag. De proxy kan hoofdopnamen bijwerken: voeg X-Forwarded-For: <client-ip> toe, zet Host: correct, verwijder hop-op hoofdopnamen zoals Connection.
Hop 6: Achtervoetverwerking. De achtervoettoepassing leest de aanvraag, raadpleegt zijn database, bouwt een JSON-antwoord.
Hop 7: Upstream-antwoord. De achtervoet stuurt het antwoord terug naar de proxy als eenvoudig HTTP.
Hop 8: Randantwoord. De proxy kan het antwoord bewerken of comprimeren, versleutelt het opnieuw via de TLS-sessie en stuurt het naar de browser.
Hop 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-achtervoetverbinding wordt vaak gepooled voor hergebruik.
Elke openbare webdienst volgt een variant van deze vorm. Het weten van de hops laat je redeneren over waar vertraging optreedt, waar logging hoort en waar een fout kan verbergen.
Waar Is De Tijd Gebleven?
Een gebruiker klaagt dat de API trage aanvoelt. Je meet en vindt dat de aanvraag 850 ms in totaal kost. Serverlogs op de back-end tonen dat de aanvraag in 40 ms is verwerkt. De proxylogs tonen dat de proxy 50 ms heeft besteed aan zijn kant van het werk (TLS-handshake + routing + antwoord schrijven).
Ontwerp een Minimale Rand voor een Nieuw Dienst
Samenvatting
Je hebt geleerd wat de verschil is tussen een voorwaartse en omgekeerde 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 hop-by-hop door de rand stroomt.
Nu toepassen.
Een klein team plaatst een nieuw service genaamd notes.example.com. Gebruikers zullen persoonlijke notities lezen en schrijven. Het team zal twee back-end VM's starten en verwacht dat het zal groeien tot tien over de volgende jaar. Ze willen HTTPS voor gebruikers, geleidelijke uitrol voor nieuwe versies en geen openbare blootstelling van back-end IPs.
Waar deze cursus verdergaat
Waar deze cursus verdergaat
Deze les heeft de vorm van de randlaag gevestigd. Vier andere lessen in deze cursus bouwen hierop:
- Staatloze Horizontale Schaling: waarom een proxy laag (& de backends erachter) goedkoop meerdere keren kan worden vermenigvuldigd, & de wiskunde voor het bepalen van de grootte van replica's onder druk.
- Ingress / Egress Splitsing: waarom een enkele proxy box die zowel aankomende als uitgaande verkeer behandelt uiteindelijk faalt op onverwachte manieren, & hoe je de lagen kunt splitsen.
- Foutmodi & Blast Radius: hoe een enkele configuratie wijziging overloopt in een storing, & hoe je schuldeloze actiepunten kunt schrijven die herhaling voorkomen.
- Betrachting & Capaciteit: wat meet je aan de rand om te ontdekken dat iets kapot is voordat gebruikers dat doen.
Elke les staat apart. Neem ze samen, dan krijg je een werkbare mentale model van een web-schaal vloot.
Complimenteer les: geometry_of_proxies_and_origins verzet alles in deze les om een gecoordinate grafiek & onderzoekt wat de grafentheorie je vertelt over een aanvraagpad.
Goed gedaan. Voort.