TCP, UDP e porte

Un numero di porta è di 16 bit, quindi va da 0 a 65535. I server web che usano HTTPS ascoltano sulla porta 443.

Prima due indovinelli. In una videochiamata un pezzettino della voce del tuo amico si perde per strada. La tua app dovrebbe richiederlo? Ora stai scaricando un file per i compiti, e un pezzo del file si perde. Stessa domanda. Decidi tutte e due le risposte prima di andare avanti.

Due pezzi persi, due risposte diverse

Se hai detto no per la chiamata e sì per il file, hai già scelto tra i due protocolli di trasporto. Un pezzo di suono che arriva mezzo secondo in ritardo non serve a niente. La conversazione è andata avanti, quindi è meglio saltare quel pezzo e suonare il successivo. Un file con un pezzo mancante è rotto, quindi vale la pena aspettare quel pezzo. Internet ha un trasporto per ogni caso: TCP aspetta e rispedisce, UDP manda e va avanti. Prima che uno dei due possa aiutare, però, un pacchetto deve arrivare al programma giusto.

Quale programma riceve il pacchetto: le porte

Un indirizzo IP porta un pacchetto al computer giusto. Ma un computer fa girare molti programmi insieme: un browser con diverse schede, un'app di chat, un'app di musica. Le intestazioni TCP e UDP portano entrambe una porta di origine e una porta di destinazione, ciascuna un numero di 16 bit da 0 a 65535, e la porta dice a quale programma è destinato un pacchetto. Un programma server ascolta su una porta concordata: 80 per l'HTTP semplice, 443 per HTTPS, 53 per il DNS, 25 per la posta tra server. La RFC 6335 divide l'intervallo in porte di sistema da 0 a 1023, porte utente da 1024 a 49151 e porte dinamiche da 49152 a 65535. Il tuo computer sceglie una porta di origine temporanea per ogni conversazione, spesso nell'intervallo dinamico. Un indirizzo e una porta insieme, come 198.51.100.20:443, indicano con precisione un capo di una conversazione.

TCP spunta ogni byte

TCP (RFC 9293) trasforma un flusso inaffidabile di pacchetti in qualcosa di simile a una linea telefonica per i byte. Prima i due lati stabiliscono una connessione con una stretta di mano in tre passi (three-way handshake): il client manda SYN, il server risponde SYN-ACK e il client replica ACK. Da quel momento ogni byte ha un numero di sequenza. Chi riceve manda conferme (ACK) che dicono fin dove è arrivato, e rimette al loro posto i pezzi arrivati in disordine. Se chi invia non riceve un ACK entro un tempo limite (timeout), rispedisce i dati. La RFC 6298 fissa il primo timeout a 1 secondo e poi lo adatta al tempo di andata e ritorno misurato. TCP rallenta anche quando vede delle perdite, così un collegamento carico non viene sommerso.

UDP manda e va avanti

UDP (RFC 768, 1980) fa molto meno. La sua intestazione è di soli 8 byte: due porte, una lunghezza e una somma di controllo. Non c'è handshake, non c'è numero di sequenza e non c'è ritrasmissione. Per la videochiamata del primo indovinello è proprio quello che serve. Anche le brevi domande DNS usano UDP, perché una domanda e una risposta sono più rapide senza handshake. QUIC, il trasporto sotto HTTP/3, funziona su UDP e ci costruisce sopra la propria ritrasmissione.

Quattro numeri tengono separate due schede

Quattro numeri insieme identificano una connessione TCP: indirizzo di origine, porta di origine, indirizzo di destinazione e porta di destinazione. È così che un server sulla porta 443 può parlare con migliaia di browser alla volta senza confonderli, ed è così che il tuo portatile tiene separate due schede sullo stesso sito, perché la connessione di ogni scheda usa una porta di origine diversa. Tocca un pacchetto nel simulatore e leggi la sua intestazione. Prima del router di casa l'origine è 192.168.0.12 porta 51000. Dopo, il NAT ha cambiato entrambi i numeri, e il router ricorda lo scambio perché le risposte tornino alla scheda giusta.