TCP vs UDP - Protocolli di Trasporto

Cos'e'

#

TCP e UDP operano al Livello 4 (Trasporto) dello stack OSI. Definiscono come i dati vengono impacchettati, spediti e ricevuti tra due macchine. La scelta tra i due dipende da cosa conta di piu': affidabilita' o velocita'.

TL;DR

#

TCP  → come una telefonata
       prima stabilisci la connessione, poi parli,
       poi saluti — ogni parola viene confermata

UDP  → come gridare in una stanza
       lanci il messaggio, non sai se e' arrivato,
       non ti importa — vai avanti

TCP — Transmission Control Protocol

#

Orientato alla connessione. Prima dei dati: handshake. Durante: conferma ogni pacchetto. Alla fine: chiusura ordinata.

Caratteristiche:

• Affidabile — pacchetti persi vengono ritrasmessi
• Ordinato — i dati arrivano nell'ordine in cui sono stati mandati
• ACK-based — ogni pacchetto ricevuto viene confermato
• Piu' lento — overhead del handshake e delle conferme

Usato da: SSH, HTTP/HTTPS, SMTP, FTP — tutto dove la perdita di dati non e' accettabile.

Vedi tcp-handshake per il dettaglio completo dei flag e del three-way handshake.

Porte TCP

#

Ogni pacchetto TCP ha source port e destination port nell'header. Le porte si dividono in due gruppi:

La destination port identifica il servizio sul server (es. 80). La source port è casuale — il server la usa solo per rispondere al client giusto.

MSS — Maximum Segment Size

#

Negoziato durante il SYN del three-way handshake. Indica la dimensione massima del payload che l'host è disposto a ricevere in un singolo segmento TCP. Non include gli header — solo i dati.

Il SYN quindi non è solo "voglio connettermi" — trasporta anche ISN (Initial Sequence Number) e MSS, i parametri che governano tutta la comunicazione successiva.

UDP — User Datagram Protocol

#

Senza connessione. Nessun handshake, nessuna conferma, nessun ordine garantito.

Caratteristiche:

• Veloce — nessun overhead di connessione
• Fire and forget — manda e non aspetta risposta
• Leggero — header 8 byte fissi (TCP ne ha almeno 20)
• Inaffidabile — pacchetti possono perdersi, duplicarsi, arrivare fuori ordine

Usato da: DNS, DHCP, streaming video, gaming, VoIP — dove la latenza conta piu' della precisione.

Perche' DNS usa UDP?
  Una query DNS e' un singolo pacchetto piccolo.
  Fare un handshake TCP per ogni query sarebbe
  tre volte piu' lento senza vantaggi reali.
  Se la risposta non arriva, il client riprova.

Header UDP

#

L'header UDP ha solo 4 campi (8 byte totali):

Niente sequence number, niente ACK, niente flags, niente window size. UDP non ha gli strumenti per garantire nulla — è una scelta deliberata.

Affidabilità in UDP — responsabilità dell'applicazione

#

UDP non garantisce la consegna. Se un'applicazione che usa UDP ha bisogno di affidabilità, deve implementarla da sola a livello applicativo.

Esempi:

• DNS — se la risposta non arriva, il client riprova dopo un timeout
• TFTP — usa un proprio meccanismo di ACK applicativo sopra UDP
• QUIC (usato da HTTP/3) — reimplementa affidabilità e ordine sopra UDP, ma con meno overhead di TCP

Confronto diretto

#

                    TCP                    UDP
Connessione         handshake 3 passi      nessuna
Affidabilita'       garantita              nessuna
Ordine dati         garantito              nessuno
Velocita'           piu' lento             piu' veloce
Header size         20 byte min            8 byte
Uso tipico          SSH, HTTP, SMTP        DNS, streaming, VoIP

Stati delle porte

#

Quando tcpdump o nmap interroga una porta, la risposta dice cosa c'e' dietro:

OPEN      Client --[S]--> Server --[S.]--> Client   servizio presente
CLOSED    Client --[S]--> Server --[R.]--> Client   nessun servizio
FILTERED  Client --[S]--> ...silenzio...             firewall blocca

Filtered e' il piu' difficile da gestire per un attaccante — non sa se la porta esiste o e' bloccata.

TCP Stream vs Pacchetto

#

Due viste dello stesso dato a livelli diversi dello stack:

# Livello RETE (quello che vede tcpdump):
# TCP spezza i dati in pacchetti

# Tu mandi:          "password\n"    (10 byte)
# TCP puo' mandare:  [pac 1: "pass"] [pac 2: "word\n"]
# il kernel decide come spezzare, tu non controlli

# Livello APPLICAZIONE (quello che vede nc, SSH, il tuo codice):
# TCP riassembla tutto in ordine prima di darlo all'app

# nc riceve:         "password\n"    (10 byte, intero)
# non vede i pacchetti, vede lo stream gia' riassemblato

TCP non sa nulla di "messaggi" — sa solo di byte in ordine. Se vuoi separare i messaggi devi farlo tu a livello applicativo:

HTTP usa:    \r\n\r\n  per separare header e body
DNS usa:     primi 2 byte = lunghezza del messaggio
SSH usa:     struttura propria del protocollo

I flag TCP e gli stati delle porte sono collegati ma sono cose diverse:

FLAG TCP          → cosa c'e' dentro un singolo pacchetto
STATO DELLA PORTA → conclusione che trai dalla sequenza di flag

Esempio:

Mandi SYN → ricevi [S.]   → conclusione: porta OPEN
Mandi SYN → ricevi [R.]   → conclusione: porta CLOSED  
Mandi SYN → silenzio      → conclusione: porta FILTERED

I flag sono i mattoni, lo stato e' quello che costruisci leggendoli.

#

Scenario Reale — Blue Team

#

Un attaccante scansiona la rete. Dal punto di vista difensivo:

• Molte porte Closed — il server e' raggiungibile ma la superficie di attacco e' piccola
• Porte Filtered — c'e' un firewall, l'attaccante deve lavorare di piu'
• Porte Open — ogni porta aperta e' una potenziale superficie di attacco

Obiettivo: tenere aperto solo quello che serve. Tutto il resto filtrato o chiuso.

Collegato a

#

• system — categoria
• tcp-handshake — dettaglio flag, handshake, SYN scan, FIN vs RST
• tcpdump — cattura traffico TCP e UDP in diretta
• netcat — tool per testare connessioni TCP e UDP
• nmap — scanner che sfrutta gli stati delle porte
• ss — mostra socket TCP e UDP aperti sulla macchina locale