un — Proxy e Origini

un

ospite

1 / ?

torna alle lezioni

Cosa si trova davanti a quasi ogni servizio web

Benvenuto

Se digitate example.com in un browser, quasi mai raggiungete la macchina che esegue effettivamente l'applicazione. Raggiungete una macchina che inoltra la richiesta a quella che lo fa. Quella macchina di forwarding porta un nome: un reverse proxy.

Questa lezione insegna cosa fa un reverse proxy, perché quasi ogni servizio web pubblico lo nasconde dietro di sé e cosa tre lavori che lo strato di bordo gestisce contemporaneamente.

Alla fine capirai:

- La differenza tra un cliente, un proxy e un origine

- Perché un proxy davanti a un origine protegge, scala e ti consente di sostituire pezzi senza che nessuno se ne accorga

- I tre lavori che un reverse proxy gestisce contemporaneamente: nascondere l'origine, terminare TLS e distribuire il carico across replicas

- Come una richiesta viaggia dal browser al proxy all'upstream e indietro, tappa per tappa

Alla fine potrai ragionare con fiducia sulla posizione del proxy, la separazione delle preoccupazioni all'edge e perché un tier di proxy stateless si moltiplica a buon mercato mentre un singolo origine non lo fa.

Forward Proxy vs Reverse Proxy

Due direzioni di proxy

Entrambi i tipi di proxy si trovano tra due parti e trasmettono il traffico. Si differenziano in quale parte rappresentano.

Forward proxy: si trova davanti a un gruppo di clienti. I clienti sanno dell'esistenza di un proxy; un server esterno vede un indirizzo proxy, non un indirizzo client.

Reverse proxy: si trova davanti a un gruppo di server. Il mondo esterno (clienti) parla con un indirizzo proxy; i clienti non sanno che un vero server si nasconde dietro.

Mnemonic: un forward proxy nasconde i clienti dai server. Un reverse proxy nasconde i server dai clienti.

Perché preoccuparsi della direzione? Il lavoro, i modi di fallimento e il confine di sicurezza differiscono. Un forward proxy si preoccupa di chi i suoi utenti contattano; un reverse proxy si preoccupa di chi contatta i suoi server.

Un client che invia traffico attraverso entrambi i tipi contemporaneamente viaggia: client -> forward_proxy -> internet -> reverse_proxy -> origin.

Una piccola azienda gestisce un'applicazione di chat. Vogliono che ogni richiesta di un utente esterno arrivi su una macchina che nasconde i veri server chat dietro di essa. Quale tipo di proxy hanno bisogno di, e a cosa si connette effettivamente l'utente esterno?

Perché Ci È Tanto in Gioco all'Edge

Lo Strato di Edge Guadagna il proprio Paniere

Un reverse proxy svolge tre lavori contemporaneamente. Ognuno di essi giustifica il livello; portare tutti e tre sulla stessa address spiega perché quasi ogni architettura web di produzione ha la stessa forma all'avanguardia.

Lavoro 1: Nascondere l'origine. Il proxy risponde su un IP pubblico. I backends si trovano su IP private che l'internet non può raggiungere. Un attaccante che vuole colpire l'origine deve prima compromettere il proxy.

Lavoro 2: Terminare TLS. Il proxy detiene il certificato per example.com e decifra le richieste HTTPS in arrivo. I backends parlano HTTP semplice (o TLS più semplice interno) al proxy su una rete segmentata fidata. La rotazione, la rinnovazione e la politica dei cifrari vivono in un unico posto.

Lavoro 3: Distribuire il carico. Il proxy sceglie quale backend gestisca ogni richiesta. I backends dietro un solo proxy formano una piscina; il proxy sceglie uno per richiesta usando una strategia (robin, meno connessioni, hash su un'intestazione). Aggiungere capacità significa aggiungere un backend alla piscina, non dire a ogni client un nuovo indirizzo.

Ogni lavoro è un piccolo programma. Insieme spiegano perché un livello così semplice come 'Caddy davanti a un'app Python' ha più peso progettuale dell'app Python stessa.

Reverse proxy che svolge tre lavori: nascondere l'origine, terminare TLS, distribuire il carico

Progettare per Tutti e Tre

Il tuo team gestisce una piccola API su un unico processo Python che ascolta sulla porta 8000 su una sola VM. Il traffico è cresciuto abbastanza che una sola VM non può più tenere il passo e una revisione di sicurezza ha segnalato che la VM ha un IP pubblico e gestisce il suo certificato TLS.

Decidi di mettere un reverse proxy davanti. Schizza lo schema: dove punta il DNS, dove vive il certificato, come il carico raggiunge i backends e cosa cambia riguardo la VM originale?

Passa in rassegna l'architettura nuova. Tratta tutti e quattro i pezzi: target DNS, ubicazione della terminazione TLS, strategia di distribuzione del carico e cosa la VM originale mantiene o perde.

Scambia una Componente Senza Che Nessuno Se Ne Accorga

L'Indirizzo Compra Libertà

Un vecchio adagio dell'informatica afferma: ogni problema può essere risolto aggiungendo un livello di indirezione (eccetto il problema di troppi livelli di indirezione). Il reverse proxy è uno degli indirezioni più utili nei sistemi distribuiti.

Cosa ti compra:

- Backends scambiabili. Passi dall'uso di Python a Go? Effettui un migrazione da un datacenter all'altro? Rilasci una nuova versione con downtime zero? Ogni cosa avviene dietro un indirizzo pubblico stabile. Nulla cambia per gli utenti.

- Scala indipendente. La tier del proxy scala su banda e CPU al livello TLS. La tier dei backends scala su lavoro dell'applicazione. Ogni cosa cresce su un proprio asse perché vivono su macchine diverse.

- Contenimento degli errori. Una cattiva distribuzione sul backend non fa cadere l'indirizzo pubblico. Il proxy rimane in esecuzione; puoi apportare una correzione o fare un rollback; il mondo si riconnette quando il backend riprende.

- Preoccupazioni incrociate in un unico posto. Limitazione di velocità, blocco geografico, registrazione richieste, modifica intestazioni, caching, compressione risposta: tutte vivono sul proxy. Il codice backend si concentra sull'applicazione.

Senza il proxy ogni uno di questi problemi deve vivere all'interno del processo dell'applicazione. Con il proxy vivono su un unico livello che una sola squadra gestisce.

Il costo: un altro livello da gestire. Squadre mature accettano il costo perché la tier del proxy stesso si esegue senza stato e scala orizzontalmente; sostituire un proxy con due richiede nessuna coordinazione.

Un Deploy Blu/Cinese Attraverso il Proxy

Il tuo team gestisce la versione 1 dell'API su tre VM backend (pool blu) dietro un reverse proxy. Vuoi distribuire la versione 2 con la possibilità di fare un rollback in meno di trenta secondi se qualcosa va storto.

Lanci tre nuove VM backend (pool verde) che eseguono la versione 2, accanto al pool blu, ma non ancora si dirige alcun traffico verso di loro.

Spiega come il reverse proxy ti consente di passare da blu a verde e fare un rollback veloce, e spiega cosa non sarebbe possibile se l'applicazione fosse direttamente esposta ai clienti senza un proxy.

Da Browser a Backend e Ritorno

Segui una Richiesta HTTPS fino alla Fine

Segui una singola richiesta GET HTTPS di https://api.example.com/users/42 attraverso un reverse proxy davanti a una piscina di backend.

Salto 1: Risoluzione DNS. Il browser chiede al risolutore api.example.com. Il risolutore restituisce l'IP pubblica del proxy (ad esempio, 203.0.113.10). Il browser apre una connessione TCP a 203.0.113.10:443.

Salto 2: Mano di pace TLS. Il proxy presenta il suo certificato per api.example.com. Il browser valuta il certificato, le due parti concordano su una chiave di sessione e si apre il canale crittografato.

Salto 3: Richiesta HTTP all'interno TLS. Il browser invia GET /users/42 HTTP/1.1\nHost: api.example.com\n.... Il proxy decifra i byte della richiesta.

Salto 4: Selezione backend. Il proxy consulta la sua piscina upstream per api.example.com e sceglie un backend (ad esempio 10.0.0.21:8000) utilizzando la sua strategia di bilanciamento carico.

Salto 5: Richiesta upstream. Il proxy apre (o reutilizza) una connessione HTTP normale a 10.0.0.21:8000 e invia la richiesta. Il proxy può riscrivere gli intervalli di testo lungo il percorso: aggiungere X-Forwarded-For: <client-ip>, impostare correttamente Host:, eliminare intervalli di testo come Connection.

Salto 6: Elaborazione backend. L'applicazione backend legge la richiesta, consulta il database, costruisce una risposta JSON.

Salto 7: Risposta upstream. Il backend invia la risposta al proxy come HTTP normale.

Salto 8: Risposta di taglio. Il proxy può riscrivere o comprimere la risposta, la crittografa di nuovo attraverso la sessione TLS e la invia al browser.

Salto 9: Ciclo di vita della connessione. La sessione TLS rimane di solito aperta per la prossima richiesta (HTTP/2 multiplexa molte richieste su una connessione). La connessione proxy-to-backend spesso poola per il riutilizzo.

Ogni servizio web pubblico segue una variante di questa forma. Conoscere i salti ti consente di ragionare su dove si accumula la latenza, dove appartiene il logging e dove può nascondersi un errore.

Ciclo di vita della richiesta: browser, DNS, proxy, TLS, upstream, backend, risposta

Dove è Passato il Tempo?

Un utente si lamenta del fatto che l'API sembra lenta. Misuri e scopri che la richiesta richiede 850 ms dal inizio alla fine. I log del server sul backend mostrano che l'applicazione ha servito la richiesta in 40 ms. I log del proxy mostrano che il proxy ha trascorso 50 ms dal suo lato del lavoro (mano di pace TLS + routing + scrittura della risposta).

Dove è andato il resto dei 760 ms? Nomina almeno due candidati che vivono fuori dal tempo di elaborazione del proxy e del backend, e spiega come ognuno di essi si manifesterebbe nelle misurazioni.

Progetta un Minimal Edge per un Nuovo Servizio

Sinossi

Hai imparato la differenza tra un forward e un reverse proxy, i tre lavori che un reverse proxy gestisce contemporaneamente, il perché nascondere l'origine è un guadagno ogni volta che hai bisogno di cambiare qualcosa e come una richiesta fluisce salto dopo salto attraverso l'edge.

Ora applicalo.

Una piccola squadra intende lanciare un nuovo servizio chiamato notes.example.com. Gli utenti leggeranno e scriveranno note personali. La squadra eseguirà due VM backend all'avvio e prevede di crescere a dieci nel corso dell'anno. Vogliono HTTPS per gli utenti, rilascio graduale per le nuove versioni e nessuna esposizione pubblica degli IP backend.

Progetta l'architettura dell'edge per notes.example.com. Address: dove punta il DNS, dove vive il certificato TLS, come le richieste raggiungono un backend, cosa cambia quando crescono da due a dieci backends, e una preoccupazione incrociata (limitazione del tasso, logging, modifica degli intervalli, ecc) che aggiungeresti all'edge invece che all'interno dell'applicazione.

Dove va questo corso

Questa lezione ha stabilito la forma della layer edge. Quattro lezioni successive in questo corso si basano su di esso:

- Scaling orizzontale senza stato: perché un livello di proxy (& i backends dietro di esso) si moltiplica a buon mercato, & la matematica per dimensionare i conti di replica sotto sopraccarico.

- Separazione di Ingress / Egress: perché una singola casella di proxy che gestisce sia il traffico in arrivo che quello in uscita fallisce in modo sorprendente, & come dividere le sfere.

- Modalità di errore & raggio di esplosione: come un cambiamento di configurazione si riversa in un'interruzione, & come scrivere elementi di azione senza colpe che preven-gono la ricorrenza.

- Osservabilità & capacità: cosa misurare all'edge per scoprire che qualcosa è rotto prima che gli utenti lo facciano.

Ogni lezione sta da sola. Prese insieme danno una tua mentalità di lavoro su una flotta a livello web.

Lezione correlata: geometry_of_proxies_and_origins ridisegna tutto in questa lezione come un grafo diretto & esplora cosa il calcolo dei grafi ti dice su un percorso richiesta.

Ben fatto. Avanti.