Networking

Come raggiungere un database che ascolta solo su localhost? Un’istanza Postgres su un server remoto è collegata a 127.0.0.1 di proposito. Nessuno sulla rete può raggiungerla, solo i processi in esecuzione su quella stessa macchina. Il tuo laptop non è quella macchina, quindi psql -h remote-server -p 5432 fallisce prima ancora di arrivare all’autenticazione. Aprire la porta al mondo vanifica il motivo per cui era stata collegata al loopback. Quello che ti serve è prendere in prestito, per qualche minuto e dal tuo terminale, la vista che la macchina remota ha di 127.0.0.1. Quando fai login, SSH ha già una connessione cifrata e autenticata aperta tra le due macchine. Il port forwarding riutilizza quella connessione per trasportare traffico diverso dalla tua shell. ...

Perché nessuno fuori dalla tua rete raggiunge localhost Un provider di webhook ha bisogno di un URL su cui fare POST, e il tuo server è fermo su localhost:3000. Oppure un collega vuole vedere il branch che stai eseguendo, o il tuo telefono deve raggiungere il server di sviluppo per controllare un layout. Il server è su. Ma niente fuori dalla tua rete riesce a raggiungerlo. Il port forwarding sul router funzionerebbe, ma espone il tuo IP di casa e richiede accesso da amministratore che spesso non hai. Cloudflare Tunnel prende la strada opposta. cloudflared, un piccolo demone che fai girare accanto al tuo server, apre una connessione in uscita verso l’edge di Cloudflare, e Cloudflare rimanda il traffico indietro attraverso quella connessione. Non apri nessuna porta in entrata e non ti serve un IP pubblico. ...

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. ...