Cosa fa davvero il DNS a ogni richiesta Ogni richiesta verso example.com inizia con una ricerca che non ha niente a che fare con la tua applicazione: qualcosa deve trasformare quel nome in un indirizzo IP prima che un solo pacchetto TCP lasci la macchina. Quella traduzione è il DNS, il Domain Name System, e gira a ogni richiesta, che il client sia un browser, curl, o un servizio backend che ne contatta un altro tramite hostname. ...
Cosa protegge davvero TLS su una connessione HTTPS Carica una pagina in http:// puro su una rete che non controlli, un aeroporto o il router di un bar, e tutto quello che invii viaggia come testo leggibile. Il percorso dell’URL, i cookie, i campi del form, la password in un POST di login: chiunque su quella rete con uno sniffer di pacchetti li legge mentre passano. TLS, Transport Layer Security, è il protocollo che blocca questo scenario. Si inserisce tra TCP e il protocollo applicativo, quindi quando HTTP inizia a parlare la connessione è già cifrata e legata a un’identità server verificata. HTTPS è semplicemente HTTP eseguito su quella connessione invece che su una in chiaro. ...
Cosa fa davvero una CDN a una richiesta Un utente a Tokyo che carica una pagina ospitata su un server in Virginia paga quella distanza due volte: una per far arrivare la richiesta, una per far tornare la risposta. La fibra ottica viaggia a una frazione fissa della velocità della luce, e quel solo tragitto costa già 150-200 ms di andata e ritorno prima che l’origine abbia fatto qualsiasi lavoro. Aggiungi una query al database e un salto di rete lento, e una pagina che sembra istantanea per chi sta vicino al server diventa lenta dall’altra parte del pianeta. ...
Cosa c’è tra il browser e la tua app Punta il browser su example.com e la richiesta non tocca mai il processo che esegue il tuo codice. Incontra prima qualcos’altro: un server che legge la richiesta, decide quale backend deve rispondere, la inoltra lì e rimanda indietro la risposta come se l’avesse prodotta lui stesso. Quel server è un reverse proxy. Nginx, Caddy, Traefik e HAProxy fanno tutti questo lavoro, così come il load balancer davanti a un cluster Kubernetes. La disposizione non cambia mai: i client parlano con il proxy e con nient’altro. I server reali restano dietro, in qualunque numero e ovunque girino. ...
Perché due container sullo stesso host non si vedono di default Avvia Postgres e la tua API con un semplice docker run e l’API non riesce a raggiungere il database, anche se entrambi i container girano sulla stessa macchina. 1 2 docker run -d --name db postgres:16 docker run -d --name api myapp Entrambi finiscono sulla bridge di default di Docker, quella su cui va a finire ogni container Docker se non specifichi altro. Ricevono un indirizzo IP. Quello che non ricevono è un modo per trovarsi a vicenda per nome: l’API dovrebbe quindi avere l’IP interno del database scritto a mano, un indirizzo che cambia ogni volta che il container riparte. ...