Let's build a chatbot

Tuttto parte da un messaggio da un nostro utente o via cellulare o via web, e interroga il chatbot:

"Mi serve aiuto per..."

Il messaggio dell'utente non viaggia "via internet" come se fosse un atto unico.

Ci sono almeno cinque sotto-passi distinti, ognuno gestito da un protocollo diverso.

Il telefono o il browser deve sapere a quale indirizzo IP mandare i dati, e per scoprirlo interroga il DNS.
Una volta noto l'IP, deve aprire una connessione affidabile col nostro server: lo fa col TCP, attraverso un three-way handshake.
La connessione poi viene cifrata con TLS, perché niente di ciò che gli utenti dicono al chatbot deve viaggiare in chiaro.
Solo a questo punto può partire la richiesta HTTP vera e propria, che è una stringa di testo strutturata: un metodo (POST), un path (/chat), degli header, un body che contiene il messaggio.
Il server risponde con un HTTP response, che è una stringa di testo strutturata: un codice di stato (200 OK, 404 Not Found, 500 Internal Server Error), un content-type (text/html, application/json), un body che contiene la risposta del chatbot.
Il browser riceve la risposta e la visualizza.

Definizioni:

Un indirizzo IP è l'identificativo numerico che permette a una macchina connessa a una rete di essere raggiunta da un'altra macchina.
NAT (Network Address Translation): sostituisce il tuo IP privato col suo IP pubblico nel pacchetto in uscita, e quando arriva la risposta fa l'operazione inversa. Tutta la tua famiglia condivide lo stesso IP pubblico.
DNS (Domain Name System): traduce un nome leggibile da un umano (openai.com) in un indirizzo IP utilizzabile da una macchina (104.18.7.105).
TCP (Transmission Control Protocol): protocollo di controllo della trasmissione. Garantisce che il messaggio arrivi intatto e in ordine.
TLS (Transport Layer Security): protocollo di crittografia che protegge la connessione tra il browser e il server.
HTTP (Hypertext Transfer Protocol): protocollo di trasferimento di ipertesto. Gli header e il body sono formati in un modo strutturato, che il server può interpretare e rispondere in modo appropriato.

Approfondimento:

Cos'è un indirizzo IP Un indirizzo IP è l'identificativo numerico che permette a una macchina connessa a una rete di essere raggiunta da un'altra macchina. Punto. La definizione è semplice ma sotto ci sono tre o quattro idee che vale la pena srotolare, perché sono quelle che fanno la differenza tra "so cos'è" e "lo capisco davvero". La prima idea: è un indirizzo, cioè serve a recapitare cose. Esattamente come l'indirizzo di casa tua serve al postino per portarti la posta. Se devo mandare un pacchetto a Roma, scrivo "Via Garibaldi 5, Roma". Se devo mandare un pacchetto di byte a un server di OpenAI, scrivo 104.18.7.105. La rete nel mezzo (router, cavi, antenne) si occupa di farlo arrivare, di nodo in nodo, fino a destinazione. Non importa come ci arriva — nessuno ha la mappa completa di internet — importa solo che ogni nodo intermedio sappia "ah, per quell'indirizzo si va da quella parte". La seconda idea: è un numero, ma scritto in modo strano. L'IP che vedi più spesso è qualcosa come 192.168.1.1 o 8.8.8.8. Quattro numeri da 0 a 255, separati da punti. Non è una scelta estetica: è la rappresentazione "umana" di un numero da 32 bit. 8.8.8.8 in binario è 00001000.00001000.00001000.00001000. I quattro gruppi sono i quattro byte del numero. Questa è la versione 4 del protocollo IP, IPv4, ed è quella che ancora oggi gestisce la maggior parte del traffico. Esiste anche IPv6, che usa 128 bit invece di 32, scritti in esadecimale separati da due punti (2606:4700::6810:765). IPv6 è stato inventato perché 32 bit fanno circa 4 miliardi di indirizzi, e nel 2012 abbiamo finito quelli "nuovi" assegnabili. Per ora IPv4 e IPv6 convivono. La terza idea: gli indirizzi non sono distribuiti a caso, sono organizzati gerarchicamente. Quando un router riceve un pacchetto, non ha una tabella con tutti i 4 miliardi di indirizzi del mondo: ha una tabella con dei prefissi. "Tutti gli indirizzi che iniziano con 104.18 vanno per quella strada lì." Questo permette al sistema di scalare. È lo stesso principio per cui il postino non ha la lista di tutti gli indirizzi del mondo, sa solo che le buste con CAP italiano vanno mandate al centro di smistamento italiano, che a sua volta le smista per provincia, e così via. La quarta idea: ci sono indirizzi pubblici e indirizzi privati. Il tuo computer di casa probabilmente ha un IP tipo 192.168.1.42. Ma quel numero, di per sé, non è raggiungibile da fuori: è un indirizzo privato, valido solo dentro la tua rete domestica. Quando vai su internet, il tuo router fa una cosa che si chiama NAT (Network Address Translation): sostituisce il tuo IP privato col suo IP pubblico nel pacchetto in uscita, e quando arriva la risposta fa l'operazione inversa. Tutta la tua famiglia condivide lo stesso IP pubblico. È un trucco nato per non finire gli indirizzi IPv4 troppo in fretta, ed è uno dei motivi per cui si è andati avanti così tanto con IPv4 invece di passare in massa a IPv6. Cos'è il DNS Il DNS è il servizio che traduce un nome leggibile da un umano (openai.com) in un indirizzo IP utilizzabile da una macchina (104.18.7.105). Il motivo per cui esiste è semplice: gli IP cambiano, sono difficili da ricordare, e un sito web può stare su decine di server diversi a seconda di chi lo sta visitando. I nomi sono stabili e umani. Il DNS è il livello di indirezione che permette di tenere queste due cose disaccoppiate. Come funziona, in pratica. Il tuo browser dice "voglio andare su openai.com, dimmi l'IP". Questa domanda viaggia attraverso una catena gerarchica di server che si chiama risoluzione DNS. Il primo che la riceve è di solito un resolver messo a disposizione dal tuo provider internet (o uno pubblico tipo 8.8.8.8 di Google o 1.1.1.1 di Cloudflare). Il resolver, se non ha già la risposta in cache, parte dall'alto e scende. Chiede ai root servers "chi gestisce i .com?", e i root server rispondono "questo TLD server qui". Il resolver chiede al TLD server "chi gestisce openai.com?", e quello risponde "questi name server qui". Il resolver chiede al name server di OpenAI "qual è l'IP di openai.com?", e quello risponde con un IP. Il resolver lo restituisce al tuo browser, e contemporaneamente lo mette in cache per le richieste future. Sembra macchinoso, ma succede tutto in pochi millisecondi (più spesso decine, in casi peggiori centinaia), e il 99% delle volte il resolver ha già la risposta in cache e salta tutta la trafila. La cosa interessante che spesso si trascura. Il DNS non restituisce un solo IP. Restituisce una lista di IP. Se interroghi google.com, ti torneranno spesso quattro o cinque indirizzi diversi, perché Google ha migliaia di server e il DNS è il primo livello di load balancing del mondo. Inoltre, il DNS può restituire IP diversi a utenti diversi: questa è la base delle CDN (Content Delivery Network). Cloudflare, Akamai, AWS CloudFront fanno tutti questo: quando il tuo browser chiede cdn.example.com, il DNS restituisce l'IP di un server geograficamente vicino a te, non un IP fisso uguale per tutti. Un altro dettaglio importante: i record DNS non sono solo indirizzi. Ce ne sono di vari tipi, ognuno con una funzione. I più comuni: A (un nome → un IPv4), AAAA (un nome → un IPv6), CNAME (un nome → un altro nome, usato come alias), MX (a chi mandare le email per questo dominio), TXT (testo libero, usato per verifiche di proprietà del dominio o configurazioni di sicurezza). Quando configuri un dominio nuovo per il tuo chatbot, ti troverai a manipolare proprio questi. Come si legano al nostro chatbot Adesso il pezzo che chiude il cerchio. Quando i tre utenti del nostro chatbot premono invio, il loro dispositivo deve sapere a quale server mandare il messaggio. Il frontend è hostato a — diciamo — chat.miaapp.com. Il backend potrebbe essere a api.miaapp.com. Per ognuno di questi, prima di qualunque altra cosa, il browser fa una richiesta DNS per ottenere l'IP. Nel 99% dei casi è una operazione invisibile e velocissima. Ma se il DNS è lento, tutto è lento — la tua app non risponderà finché il browser non ha l'IP, non importa quanto è ottimizzato il tuo backend. Una volta noto l'IP, il browser apre una connessione TCP verso quell'indirizzo, ci negozia sopra il TLS, e ci manda l'HTTP. Tutto questo è il pezzo "dal browser al server" del viaggio. Il DNS è il primissimo passo: senza, non si parte. Un caso pratico che ti capiterà presto, lavorando sul deploy del tuo chatbot. Quando vorrai mettere il tuo backend dietro un dominio personalizzato (api.miochatbot.com), dovrai andare nel pannello DNS del tuo provider (Cloudflare, Route53, dove hai comprato il dominio) e creare un record A o un CNAME che punti al server dove gira la tua applicazione. Da quel momento, chiunque digiti api.miochatbot.com finirà sul tuo server. Quel "da quel momento" non è istantaneo: i record DNS hanno un TTL (time to live) che dice ai resolver per quanto tempo possono tenere la risposta in cache. Se il TTL è 1 ora, possono passare fino a 60 minuti prima che il mondo intero veda la modifica. Per cambi importanti, si abbassa il TTL prima del cambio (es. a 5 minuti), si fa il cambio, si rialza il TTL dopo. Trucco da sapere. Un altro caso pratico, di sicurezza. Se il DNS della tua app viene "dirottato" da un attaccante (DNS spoofing, DNS hijacking), gli utenti che cercano di andare sul tuo chatbot finirebbero su un server controllato dall'attaccante, che potrebbe rubare credenziali o conversazioni. Per questo esistono due livelli di difesa: DNSSEC (firma crittografica delle risposte DNS, perché il client possa verificare che vengono davvero dal name server legittimo) e — soprattutto — TLS, che cripta la comunicazione e usa certificati firmati da autorità riconosciute. Anche se il DNS ti mandasse sul server sbagliato, il TLS si accorgerebbe che il certificato non corrisponde al dominio richiesto e il browser bloccherebbe la connessione con un warning grosso. È un sistema a strati, dove ogni strato difende dai fallimenti di quello sotto. La cosa da portarsi a casa Indirizzo IP e DNS sono i due livelli più bassi del viaggio di una qualunque richiesta web, e sono talmente fondamentali da essere invisibili. Quando funzionano, non te ne accorgi. Quando si rompono, di solito rompono tutto, e in modo difficile da debuggare proprio perché sei abituato a darli per scontati. Il modello mentale che mi ha aiutato a chiarirli definitivamente è questo: l'IP è dove sta una macchina, il DNS è come la trovi. Il mondo del software gira su questi due concetti, e tornano a galla in posti dove non te li aspetti — quando configuri un container Docker che deve parlare con un altro container, quando setti un load balancer, quando debugghi perché la tua app non riesce a connettersi al database in produzione mentre in locale funziona. Nove volte su dieci, in quei momenti, il problema è "non sto risolvendo il nome giusto" o "sto risolvendo il nome ma l'IP non è raggiungibile". E saper distinguere quale dei due sia il problema è metà della soluzione.