Sistemi e Reti - Anno 4 - Modulo 3 - Lezione 09 - TCP vs UDP, Confronto, QUIC e HTTP/3

Sistemi e Reti · Anno 4 · Modulo 3 · Lezione 09

✍ Autore: profgiagnotti · Materia: Sistemi e Reti

TCP vs UDP: confronto, criteri di scelta e QUIC

Chiusura del Modulo 3: confrontiamo TCP e UDP su tutte le dimensioni, impariamo a scegliere il protocollo giusto e scopriamo QUIC, il trasporto moderno di HTTP/3 che unisce affidabilità e velocità.

⏱ 60 min 📚 Anno 4 🧠 TCP vs UDP 💻 QUIC HTTP/3 🧪 Lab Wireshark → 🧪 Lab netstat → 🧪 Lab netcat →

// obiettivi di apprendimento

✓Confrontare sistematicamente TCP e UDP su tutte le caratteristiche principali attraverso la tabella comparativa definitiva

✓Applicare i criteri di scelta tra TCP e UDP in scenari applicativi reali (web, streaming, DNS, gaming)

✓Comprendere l'architettura e i vantaggi di QUIC (RFC 9000) come evoluzione del trasporto su UDP

✓Analizzare i trade-off tra affidabilità, latenza, overhead e chi gestisce il recupero errori

✓Consolidare la visione del livello Transport TCP/IP come insieme coerente di meccanismi a servizio delle applicazioni

// Indice della lezione

1. Il confronto definitivo: tabella TCP vs UDP 2. Quando scegliere TCP o UDP: criteri decisionali 3. QUIC (RFC 9000): il meglio di entrambi i mondi 4. HTTP/3 vs HTTP/2: stack e vantaggi prestazionali 5. Riepilogo visivo del Modulo 3: il livello Transport 6. Verifica e laboratorio 7. Riepilogo e concetti chiave

1. Il confronto definitivo: tabella TCP vs UDP

📌 Definizione da ricordare

TCP è affidabilità totale a costo di overhead; UDP è velocità e semplicità a costo zero garanzie. La scelta è un trade-off architetturale, non una preferenza personale.

Arrivati all'ultima lezione del Modulo 3 abbiamo studiato ogni meccanismo del Transport: multiplexing, porte, segmentazione TCP, handshake, ACK, SACK, flow control, congestion control e la semplicità di UDP. Ora li mettiamo fianco a fianco.

Caratteristica	TCP	UDP
Connessione	Connection-oriented (3-way handshake)	Connectionless — nessun setup
Affidabilità	Garantita: ACK, ritrasmissione, ordine	Best-effort — nessuna garanzia
Ordine dei dati	Garantito: riordino lato ricevitore	Non garantito
Velocità / Latenza	Più lento (overhead setup + ACK)	Più veloce (zero setup, zero ACK)
Dimensione header	20–60 byte (opzioni variabili)	8 byte fissi
Modello dati	Byte-stream (nessun confine messaggio)	Message-oriented (confini preservati)
Controllo flusso	Sì — Receive Window (rwnd)	No
Controllo congestione	Sì — cwnd, Slow Start, CUBIC/BBR	No
Broadcast / Multicast	No (punto-a-punto)	Sì — ideale per discovery
Stati half-open	Sì (TIME_WAIT, FIN_WAIT, CLOSE_WAIT)	N/A — nessuna connessione
Overhead kernel	Elevato (TCB, buffer, timer)	Minimo
Applicazioni tipiche	HTTP, FTP, SMTP, SSH	DNS, DHCP, VoIP, gaming, streaming live

🎯 Esempio in classe

Apri netstat -tunap su Linux: vedrai decine di righe TCP in ESTABLISHED/TIME_WAIT e poche UDP senza stato. Ogni socket TCP mantiene un TCB; UDP no. È la prova visiva del costo dell'affidabilità.

2. Quando scegliere TCP o UDP: criteri decisionali

Scegliere il protocollo giusto significa rispondere a 4 domande: i dati possono essere persi? La latenza è più importante della correttezza? Serve broadcast? Chi deve ritrasmettere?

01 · USA TCP SE

Devi garantire tutti i byte

File transfer, email, web, database. Non puoi perdere neppure un byte, l'ordine conta. Accetti overhead.

02 · USA UDP SE

La latenza vale più della perdita

VoIP, videocall, gaming, DNS, DHCP: meglio un pacchetto perso che 200ms di attesa per ritrasmissione.

03 · CRITERIO BROADCAST

Serve one-to-many?

Discovery di rete, streaming live locale, DHCP: solo UDP supporta broadcast e multicast nativo.

04 · CRITERIO CONTROLLO

Chi gestisce l'affidabilità?

Con TCP lo fa il kernel. Con UDP lo fa l'applicazione: tu decidi timeout, ACK applicativi, codec adattivo.

💬 Tip del docente

All'interrogazione non dire "TCP è meglio di UDP". Di': "TCP se mi serve affidabilità totale e posso pagare in latenza; UDP se la mia app tollera perdite e deve essere reattiva o supportare broadcast. Se voglio entrambi: QUIC".

Scenario	Scelta	Perché
Navigazione web (HTTP/2)	TCP + TLS	Documento deve arrivare integro, ordine garantito
DNS query	UDP	Query singola, piccola, deve essere velocissima; se persa ritenta il client
Zoom / Meet	UDP	Meglio scartare un frame che bloccare lo stream per ritrasmetterlo
Git clone / download ISO	TCP	Un bit sbagliato corrompe tutto
Streaming live esports	QUIC su UDP	Bassa latenza + affidabilità selettiva + migrazione IP

3. QUIC (RFC 9000): il meglio di entrambi i mondi

QUIC nasce da Google nel 2013 e diventa standard IETF nel 2021 con RFC 9000. Idea chiave: reimplementare in userspace, sopra UDP, tutto ciò che serve: affidabilità, controllo flusso, congestion control, TLS 1.3 e multiplexing di stream.

📌 Definizione da ricordare

QUIC è un protocollo di trasporto affidabile, multiplexato e sicuro costruito su UDP che integra nativamente TLS 1.3 ed elimina l'head-of-line blocking di TCP.

01 · PROBLEMA TCP

Head-of-line blocking

In HTTP/2, un pacchetto perso blocca tutti gli stream sulla stessa connessione TCP, anche se indipendenti.

02 · SOLUZIONE QUIC

Stream indipendenti

QUIC gestisce N stream QUIC dentro una connessione UDP. La perdita su uno stream non blocca gli altri: niente HOL blocking.

03 · MIGRAZIONE

Connection ID

TCP identifica la connessione con 4-tupla. QUIC usa un Connection ID: puoi passare da WiFi a 4G senza rompere la connessione.

Problema di TCP	Come lo risolve QUIC
Handshake 2-3 RTT: TCP SYN + TLS 1.3 = 2-3 round-trip prima di inviare dati HTTP	Handshake QUIC+TLS in 1-RTT, 0-RTT se server già visitato (dati già nel primo pacchetto)
Head-of-line blocking transport: perdita di 1 pacchetto blocca tutto	Stream indipendenti con flow control per-stream e connection-wide
Ossificazione middlebox: firewall/DPI bloccano nuove opzioni TCP	QUIC è su UDP, cifrato: middlebox vede solo UDP, innovazione in userspace senza aggiornare kernel
Connection migration: cambiare IP (es. WiFi → 4G) rompe la connessione TCP	Connection ID indipendente dall'IP — migrazione trasparente
Loss recovery lento	ACK più ricchi, packet number monotono, SACK migliorato, ritrasmissione precisa

QUIC · LOGICA

QUIC packet = Header (Connection ID + Packet Number) + Frames
Frames: STREAM (dati), ACK, CRYPTO (TLS), CONNECTION_CLOSE, PADDING, etc.

Client  ──► Initial( CRYPTO ClientHello ) ──► Server       // 1-RTT
Client  ◄── Handshake( CRYPTO ServerHello ) ── Server
Client  ──► 1-RTT( STREAM: GET /index.html )  ──► Server   // dati applicativi già al 2° RTT
Client  ◄── 1-RTT( STREAM: HTTP 200 ) ──────── Server

Se client rivisita: 0-RTT -> può inviare GET già nel primo pacchetto Initial
Cifratura: quasi tutto il pacchetto è cifrato (tranne pochi bit invarianti) -> anti-ossificazione

⚠️ Errore comune

QUIC NON è "UDP affidabile" nel senso che rende UDP affidabile a livello IP. È un protocollo completo che gira SOPRA UDP ma reimplementa affidabilità in userspace. Dire "metto ACK su UDP = QUIC" è riduttivo: QUIC ha stream, flow control, TLS, migrazione, QPACK.

4. HTTP/3 vs HTTP/2: stack e vantaggi prestazionali

HTTP/3 è semplicemente HTTP su QUIC. Il mapping è diretto: ogni richiesta HTTP/3 è uno stream QUIC bidirezionale.

CONFRONTO · RTT

HTTP/2 (TCP + TLS 1.3):
  RTT1: SYN -> SYN-ACK -> ACK (TCP handshake)
  RTT2: ClientHello -> ServerHello ... (TLS 1.3)
  RTT3: GET / -> primo byte HTTP
  Totale: 2-3 RTT

HTTP/3 (QUIC):
  RTT1: Initial[CRYPTO+TLS ClientHello + 0 o più STREAM] -> Server risponde con Handshake + dati
  Se sessione già nota: 0-RTT -> GET nel primo pacchetto!
  Totale: 1 RTT (o 0 RTT)

Per mobile: passare da WiFi a 4G = QUIC mantiene CID, TCP resetta

💬 Stato adozione — aprile 2026

HTTP/3 è supportato da tutti i browser moderni (Chrome, Firefox, Safari, Edge) e da CDN principali (Cloudflare, Google, Fastly, Akamai). Google usa QUIC per la maggior parte del suo traffico. YouTube e Netflix sfruttano QUIC per ridurre il buffering video. QUIC è ormai infrastruttura web globale.

5. Riepilogo visivo del Modulo 3: il livello Transport

Guardando all'indietro l'intero Modulo 3, il livello Transport è il luogo dove la rete diventa utile per le applicazioni:

MODULO 3 · MAPPA

APPLICAZIONE
  │  usa socket (5-tupla: IPsrc, PORTsrc, IPdst, PORTdst, proto)
  ▼
LIVELLO TRANSPORT
  ├── Multiplexing/Demultiplexing (L01-L02) -> porte, socket, ephemerial ports
  ├── TCP: affidabilità totale
  │   ├── Header e struttura segmento (L03) -> 20-60B, seq/ack, flag
  │   ├── Handshake / chiusura (L04) -> SYN, FIN, TIME_WAIT, 4-way
  │   ├── Error recovery: ACK, SACK, retransmit (L05) -> Go-Back-N, Selective Repeat
  │   ├── Flow control: rwnd, Nagle (L06) -> evita di inondare receiver
  │   └── Congestion control: cwnd, Slow Start, CUBIC, BBR (L07) -> evita di inondare rete
  └── UDP: velocità e semplicità
      ├── Header 8 byte, best-effort (L08) -> message-oriented, broadcast
      └── QUIC: il meglio di entrambi (L09) ←── siamo qui
          ├── 1-RTT, 0-RTT, Connection ID
          ├── Stream indipendenti, no HOL
          └── TLS 1.3 nativo, cifrato, userspace
  │
  ▼
LIVELLO NETWORK (IP) — Modulo 2 (unreliable, best-effort) -> Transport lo rende utile

🎯 Analogia finale

IP è il servizio postale che può perdere lettere. UDP è consegnare la lettera così com'è, senza ricevuta. TCP è raccomandata con ricevuta di ritorno, riordino e assicurazione. QUIC è un corriere privato su moto (UDP) che ti offre tutti i servizi della raccomandata ma più veloce, con tracking crittografato e cambio indirizzo al volo.

6. Verifica e laboratorio

🔬 Attività Wireshark + netstat + netcat

Metti in pratica il confronto e preparati alla verifica pratica:

Lab Wireshark: avvia cattura, apri https://example.com e nslookup example.com. Filtra tcp e udp. Confronta handshake TCP (SYN,SYN-ACK,ACK) vs singola query DNS UDP. Identifica SACK e window scaling.
Lab netstat: esegui ss -tunap e netstat -an. Classifica socket LISTEN, ESTABLISHED, TIME_WAIT. Quanti sono TCP vs UDP? Perché?
Lab netcat: lancia nc -l -p 9000 e nc -u -l -p 9001. Invia messaggi con client TCP e UDP. Osserva confini messaggio preservati in UDP ma non in TCP (byte-stream).
Quiz scelta: per ciascuna app scegli TCP/UDP/QUIC motivando: live F1, chat di trading, trasferimento firmware OTA su 10.000 IoT, DNSSEC.

✅ Soluzione ragionata

F1 live: QUIC/UDP – latenza imperativa, perdita tollerata. Trading chat: TCP – ordine e affidabilità critica. Firmware OTA: TCP o QUIC con congestion control per non saturare rete. DNSSEC: UDP con fallback TCP se risposta >512B; ora anche DoQUIC/DoH su QUIC per privacy.

7. Riepilogo e concetti chiave

✓TCP garantisce affidabilità, ordine, controllo flusso (rwnd) e congestione (cwnd) a costo di overhead, stati e latenza di setup

✓UDP è leggero (8B), veloce, connectionless — nessuna garanzia ma minima latenza; supporta broadcast/multicast, message-oriented

✓La scelta TCP vs UDP dipende da: tolleranza perdita, priorità latenza, necessità broadcast, chi gestisce affidabilità (kernel vs app)

✓QUIC (RFC 9000) su UDP offre affidabilità TCP + velocità UDP + TLS 1.3 nativo + stream senza HOL blocking + Connection ID per migrazione

✓HTTP/3 usa QUIC: handshake 1-RTT, 0-RTT per rivisite, adozione globale su browser e CDN

✓Il livello Transport è il confine tra rete unreliable (IP) e applicazioni: TCP e UDP sono i suoi due strumenti fondamentali, QUIC la loro evoluzione

📚 Modulo 3 completato — verso il livello Application

Hai chiuso il Transport: sai come i socket multiplexano, come TCP rende affidabile una rete inaffidabile e perché UDP resta insostituibile dove conta la reattività. Prossimo modulo: DNS, HTTP, API e sicurezza applicativa. Porta con te questa domanda: “chi deve occuparsi del pacchetto perso?”

← Lezione precedenteL08 – UDP caratteristiche