Porte TCP e UDP su Linux: differenze ed esempi pratici - Orvieto Linux User Group

Porte, TCP e UDP: capire come comunicano i servizi in rete

Quando navighiamo su un sito, ci colleghiamo a un server tramite SSH o utilizziamo un servizio di rete nel nostro homelab, diversi componenti lavorano insieme per far arrivare i dati a destinazione. Tra questi ci sono gli indirizzi IP, le porte e i protocolli di trasporto.

Abbiamo già visto che le porte permettono di distinguere i servizi raggiungibili su una macchina e che strumenti come ss e UFW aiutano a controllare le connessioni. Ma perché troviamo porte TCP e porte UDP? E che cosa cambia concretamente tra i due protocolli?

Capire questa differenza ci aiuta a leggere meglio le informazioni mostrate da Linux, configurare i servizi in modo consapevole e diagnosticare più facilmente i problemi di rete.

Indirizzo IP, porta e protocollo: tre informazioni diverse

Immaginiamo che il nostro computer debba contattare un server. L’indirizzo IP identifica la destinazione nella rete, mentre il numero di porta permette di individuare il servizio o l’endpoint di trasporto coinvolto nella comunicazione.

Il protocollo indica invece come vengono gestiti i dati durante il trasporto. TCP e UDP svolgono questo compito in modi differenti.

Possiamo pensare all’indirizzo IP come all’indirizzo di un edificio e alla porta come al riferimento per raggiungere un determinato servizio. TCP e UDP stabiliscono invece regole diverse per lo scambio dei dati.

Nel caso di TCP e UDP, i numeri di porta vanno da 0 a 65535. È importante sapere che lo stesso numero può essere utilizzato sia da TCP sia da UDP: la porta TCP 53 e la porta UDP 53 appartengono a spazi distinti e non sono automaticamente lo stesso endpoint.

Anche le porte più conosciute sono convenzioni, non vincoli assoluti. SSH utilizza comunemente TCP 22, HTTP TCP 80 e HTTPS TCP 443, ma un amministratore può configurare un servizio per ascoltare su una porta diversa.

TCP: una comunicazione orientata alla connessione

TCP, acronimo di Transmission Control Protocol, è progettato per fornire un flusso di dati affidabile e ordinato tra due endpoint.

Prima di scambiare i dati, normalmente i due estremi stabiliscono una connessione attraverso una procedura chiamata three-way handshake. Durante la comunicazione, TCP utilizza meccanismi per rilevare le perdite, ritrasmettere i segmenti mancanti e consegnare i dati all’applicazione nell’ordine corretto.

Questo non significa che TCP garantisca che un’applicazione abbia elaborato una richiesta o che un’operazione sia andata a buon fine. Garantisce funzionalità di trasporto: il significato e il risultato della comunicazione dipendono anche dal protocollo applicativo e dal servizio coinvolto.

TCP è adatto quando l’ordine e l’affidabilità dei dati sono importanti. Per esempio, SSH lo utilizza per una sessione di amministrazione remota, mentre HTTP e HTTPS tradizionali utilizzano TCP.

Se apriamo una sessione SSH, non vogliamo che i caratteri digitati arrivino in ordine casuale o che il terminale perda parti del flusso di dati. I meccanismi di TCP aiutano a gestire questi aspetti anche quando la rete presenta ritardi o perdite di pacchetti.

UDP: datagrammi senza una connessione TCP

UDP, acronimo di User Datagram Protocol, adotta un approccio più semplice. Invia datagrammi senza stabilire una connessione TCP e senza fornire, a livello di protocollo, le stesse garanzie di consegna e ordinamento.

Questo significa che un datagramma può arrivare, arrivare fuori ordine oppure andare perso. UDP non effettua automaticamente le ritrasmissioni necessarie a recuperare ogni dato mancante.

La semplicità di UDP è utile quando l’applicazione preferisce contenere i ritardi e gestire autonomamente eventuali perdite, oppure quando lo scambio di messaggi brevi non richiede una connessione TCP. Tra gli esempi troviamo molte comunicazioni DNS, alcune applicazioni multimediali in tempo reale e protocolli utilizzati per scoprire o monitorare dispositivi in rete.

Non dobbiamo però concludere che UDP sia sempre più veloce o che TCP sia sempre preferibile. La scelta dipende dal servizio, dalle caratteristiche della rete e dalle funzionalità richieste dall’applicazione. Anche un’applicazione basata su UDP può implementare meccanismi propri di affidabilità e ritrasmissione.

TCP e UDP a confronto

Caratteristica	TCP	UDP
Comunicazione	Orientata alla connessione	Senza connessione TCP
Consegna dei dati	Ritrasmissioni e controllo dell’ordine	Nessuna garanzia intrinseca di consegna o ordine
Struttura	Flusso di byte	Datagrammi distinti
Utilizzi tipici	SSH, HTTP/1.1, HTTP/2 su TCP	DNS in molti casi, streaming in tempo reale, QUIC
Gestione delle perdite	Gestita dal protocollo TCP	Dipende dall’applicazione, se necessaria

Una precisazione importante: HTTP/3 utilizza QUIC, che si basa su UDP e implementa proprie funzionalità di trasporto affidabile. Per questo non basta vedere UDP per concludere che l’applicazione non gestisca l’affidabilità.

Come vedere TCP e UDP su Linux

Su Linux possiamo utilizzare ss per osservare i socket di rete. Per mostrare quelli TCP e UDP, compresi quelli in ascolto, possiamo eseguire:

sudo ss -tulpen

Le opzioni -t e -u selezionano rispettivamente TCP e UDP; -l mostra i socket in ascolto; -p prova a indicare i processi associati; -e aggiunge informazioni estese e -n mostra indirizzi e porte in formato numerico.

L’output cambia in base ai servizi presenti sulla macchina. Potremmo trovare, per esempio, una riga TCP con stato LISTEN associata alla porta 22, se è attivo un server SSH configurato sulla porta standard. Per UDP, invece, possiamo incontrare socket indicati come UNCONN: è normale, perché UDP non stabilisce una connessione TCP prima di inviare datagrammi.

Se vogliamo concentrarci sulle connessioni TCP già stabilite, possiamo usare:

ss -tn

Questo comando mostra i socket TCP senza risolvere i nomi, facilitando la lettura degli indirizzi e delle porte. Non è però un elenco completo di tutte le comunicazioni di rete: per esempio, non mostra i datagrammi UDP come se fossero connessioni TCP stabilite.

Ricordiamo che un socket in ascolto non dimostra, da solo, che un servizio sia raggiungibile da un altro computer. Per raggiungerlo devono essere corretti anche l’indirizzo su cui ascolta, il routing e le regole di filtraggio.

Una stessa porta può esistere sia in TCP sia in UDP

Consideriamo la porta 53, comunemente associata al DNS, il servizio che aiuta a tradurre i nomi di dominio in indirizzi IP.

Le richieste DNS utilizzano spesso UDP, ma TCP è utilizzato in diverse situazioni, per esempio per trasferimenti di zona e quando occorre gestire risposte che richiedono una comunicazione TCP. Per questo un server DNS può utilizzare entrambi i protocolli.

Non dobbiamo quindi parlare genericamente di “porta 53 aperta” senza specificare il protocollo e il contesto. Una regola che consente UDP 53 non equivale a una regola che consente TCP 53.

Lo stesso principio vale quando configuriamo un firewall. Se un’applicazione richiede una determinata combinazione di porta e protocollo, dobbiamo autorizzare quella necessaria, non aprire indiscriminatamente tutte le varianti.

Come interpretare una regola firewall

Se vogliamo permettere connessioni SSH sulla porta standard con UFW, possiamo utilizzare:

sudo ufw allow 22/tcp

La parte finale, /tcp, indica esplicitamente il protocollo. La regola non apre genericamente la porta 22 per qualsiasi tipo di traffico: autorizza il traffico TCP previsto dalla regola.

Prima di modificare le regole di un sistema già configurato, controlliamo lo stato del firewall:

sudo ufw status verbose

Se stiamo amministrando una macchina da remoto, dobbiamo prestare particolare attenzione a non bloccare la nostra stessa connessione. Inoltre, consentire una porta sul firewall non avvia automaticamente il servizio e non garantisce che sia raggiungibile da Internet: devono essere corretti anche la configurazione del servizio e il percorso di rete.

Per approfondire il controllo delle porte in ascolto e la gestione delle regole, possiamo consultare la nostra guida su firewall Linux, porte e UFW.

Quando conoscere TCP e UDP aiuta nella diagnosi

Immaginiamo di avere un servizio che non risponde. Se sappiamo che dovrebbe ascoltare su TCP 443, possiamo verificare con ss se il socket è presente e poi controllare la configurazione del firewall e il percorso di rete.

Se invece stiamo verificando un servizio basato su UDP, non dobbiamo aspettarci necessariamente lo stato LISTEN tipico dei socket TCP. La visualizzazione può mostrare UNCONN, e la verifica del funzionamento richiede strumenti e test appropriati al protocollo applicativo.

Questa distinzione evita una conclusione sbagliata piuttosto comune: non vedere una connessione TCP stabilita non significa necessariamente che il servizio sia spento. Potrebbe non esserci una connessione attiva in quel momento, il servizio potrebbe utilizzare UDP oppure la comunicazione potrebbe essere bloccata prima di raggiungere la macchina.

La diagnosi migliore parte quindi da una domanda concreta: quale servizio stiamo controllando, quale protocollo utilizza e da quale indirizzo dovrebbe essere raggiungibile?

Conclusioni

TCP e UDP sono due protocolli fondamentali per comprendere il funzionamento delle reti. TCP gestisce una comunicazione orientata alla connessione e offre meccanismi di affidabilità e ordinamento; UDP invia datagrammi senza fornire le stesse garanzie, lasciando all’applicazione la gestione di eventuali esigenze aggiuntive.

Su Linux possiamo osservare i socket con ss e verificare le regole del firewall, ma per interpretare correttamente i risultati dobbiamo sempre considerare insieme protocollo, porta, indirizzo e servizio.

Con queste basi diventa più semplice capire perché due applicazioni utilizzano porte diverse, perché una regola firewall specifica TCP o UDP e come individuare il punto in cui una comunicazione smette di funzionare. È un passaggio importante per amministrare server Linux, container e macchine virtuali con maggiore sicurezza e consapevolezza.