TCP vs UDP: confronto, criteri di scelta e applicazioni reali

// obiettivi di apprendimento
Confrontare sistematicamente TCP e UDP su tutte le caratteristiche principali attraverso la tabella comparativa
Applicare i criteri di scelta tra TCP e UDP in scenari applicativi reali
Comprendere l’architettura e i vantaggi di QUIC (RFC 9000) come evoluzione del trasporto su UDP
Consolidare la visione del livello Transport TCP/IP come insieme coerente di meccanismi a servizio delle applicazioni
🎬
Video
TCP vs UDP e l’evoluzione verso QUIC/HTTP3
Guarda →
📄
Slides
Tabella comparativa, decision tree, architettura QUIC
Scarica →
🧪
Lab
Benchmark TCP vs UDP con iperf3 e analisi latenza
GitHub →
🔗
Risorse
RFC 9000, HTTP/3, QUIC explainer, iperf3 docs
Vedi →

Il confronto definitivo: TCP vs UDP

CaratteristicaTCPUDP
ConnessioneConnection-oriented (3-way handshake)Connectionless — nessun setup
AffidabilitàGarantita: ACK, ritrasmissione, ordineBest-effort — nessuna garanzia
Ordine dei datiGarantito: riordino lato ricevitoreNon garantito
VelocitàPiù lento (overhead di setup e ACK)Più veloce (zero setup, zero ACK)
Dimensione header20–60 byte (opzioni variabili)8 byte fissi
Modello datiByte-stream (nessun confine messaggio)Message-oriented (confini preservati)
Controllo flussoSì — Receive Window (rwnd)No
Controllo congestioneSì — cwnd, Slow Start, CUBIC/BBRNo
Broadcast/MulticastNo (punto-a-punto)
Half-open connectionsSì (TIME_WAIT, FIN_WAIT)N/A — nessuna connessione
Esempi applicativiHTTP/S, SSH, FTP, SMTP, databaseDNS, VoIP, streaming, gaming, DHCP
RFCRFC 9293 (2022)RFC 768 (1980)

Criteri di scelta — quando usare TCP

// scegli TCP se
  • Integrità dei dati è fondamentale: un file corrotto o un’email incompleta è un errore applicativo grave
  • L’ordine dei dati conta: un database deve ricevere le query nell’ordine corretto
  • Nessuna tolleranza alla perdita: transazioni finanziarie, autenticazione, configurazione remota
  • Comunicazione bidirezionale prolungata: sessioni SSH, connessioni DB, API REST

Criteri di scelta — quando usare UDP

// scegli UDP se
  • La latenza è prioritaria: un pacchetto vocale in ritardo è inutile anche se integro
  • Piccole perdite sono tollerabili: il codec VoIP nasconde la perdita di un frame audio
  • L’applicazione gestisce l’affidabilità: TFTP, QUIC, RTP aggiungono i propri meccanismi
  • Serve broadcast/multicast: DHCP, mDNS, protocolli di discovery, streaming multicast
  • Transazioni brevi request/response: DNS, SNMP — il retry è più veloce del setup TCP

Decision tree — quale protocollo?

Stai progettando un'applicazione di rete. Quale protocollo di trasporto?

  ┌─────────────────────────────────────────────┐
  │ Hai bisogno di broadcast o multicast?       │
  └─────────┬─────────────────────────┬─────────┘
            │ SÌ                      │ NO
            ▼                         ▼
          UDP          ┌──────────────────────────────┐
                       │ La perdita di dati è         │
                       │ assolutamente inaccettabile? │
                       └──────────┬───────────┬───────┘
                                  │ SÌ        │ NO
                                  ▼           ▼
                                 TCP     ┌──────────────────────┐
                                         │ La latenza è         │
                                         │ prioritaria?         │
                                         └───────┬──────┬───────┘
                                                 │ SÌ   │ NO
                                                 ▼      ▼
                                               UDP     TCP
                                        (o UDP+custom)

QUIC — l’evoluzione del livello Transport

Il dibattito TCP vs UDP ha portato negli anni 2010 a una domanda radicale: e se potessimo combinare l’affidabilità di TCP con la velocità di UDP, aggiungendo la crittografia nativa?

// definizione formale — QUIC
QUIC (RFC 9000, 2021) è un protocollo di trasporto multiplexato e sicuro costruito su UDP. Implementa affidabilità, controllo del flusso, controllo della congestione e TLS 1.3 nativamente, eliminando i limiti strutturali di TCP. È la base di HTTP/3 (RFC 9114).

Limiti di TCP che QUIC risolve

Problema TCPSoluzione QUIC
Head-of-line blocking: la perdita di un pacchetto blocca tutti gli stream successiviStream indipendenti: la perdita su uno stream non blocca gli altri
Latenza di setup: 3-way handshake + TLS handshake = 2–3 RTT prima dei dati0-RTT o 1-RTT: crittografia e dati nella stessa fase di handshake
Ossificazione: i middlebox (firewall, NAT, load balancer) ispezionano TCP e bloccano variantiPayload completamente cifrato — i middlebox vedono solo UDP
Connection migration: cambiare IP (es. WiFi → 4G) rompe la connessione TCPConnection ID indipendente dall’IP — migrazione trasparente

Stack HTTP/3 vs HTTP/2

HTTP/2:                      HTTP/3:
┌─────────────┐             ┌─────────────┐
│   HTTP/2    │             │   HTTP/3    │
├─────────────┤             ├─────────────┤
│    TLS 1.3  │             │    QUIC     │ ← include TLS 1.3 nativamente
├─────────────┤             ├─────────────┤
│    TCP      │             │    UDP      │
├─────────────┤             ├─────────────┤
│    IP       │             │    IP       │
└─────────────┘             └─────────────┘

Vantaggi HTTP/3 su HTTP/2:
  ✓ Nessun head-of-line blocking a livello transport
  ✓ Handshake 1-RTT (vs 2-3 RTT TCP+TLS)
  ✓ 0-RTT per connessioni a server già visitati
  ✓ Migrazione di connessione (mobile: WiFi → 4G senza drop)
// stato di 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 parte fondamentale dell’infrastruttura web globale.

Riepilogo visivo del Modulo 3

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

APPLICAZIONE
  │  usa socket (5-tupla)
  ▼
LIVELLO TRANSPORT
  ├── Multiplexing/Demultiplexing (L01-L02)
  ├── TCP: affidabilità totale
  │   ├── Header e struttura segmento (L03)
  │   ├── Handshake / chiusura (L04)
  │   ├── Error recovery: ACK, SACK, retransmit (L05)
  │   ├── Flow control: rwnd, Nagle (L06)
  │   └── Congestion control: cwnd, CUBIC, BBR (L07)
  └── UDP: velocità e semplicità
      ├── Header 8 byte, best-effort (L08)
      └── QUIC: il meglio di entrambi (L09) ←── siamo qui
  │
  ▼
LIVELLO NETWORK (IP) — Modulo 2
📌 Riepilogo — Punti chiave del Modulo 3
  • TCP garantisce affidabilità, ordine, controllo del flusso e della congestione a costo di overhead e latenza di setup
  • UDP è leggero, veloce, connectionless — nessuna garanzia ma minima latenza; supporta broadcast/multicast
  • La scelta TCP vs UDP dipende da: tolleranza alla perdita, priorità della latenza, necessità di broadcast, chi gestisce l’affidabilità
  • QUIC (RFC 9000) è il protocollo di nuova generazione: affidabilità TCP + velocità UDP + TLS nativo + no head-of-line blocking
  • HTTP/3 usa QUIC su UDP e risolve i limiti strutturali di TCP: handshake 1-RTT, migrazione di connessione, stream indipendenti
  • Il livello Transport è il confine tra la rete (IP, unreliable) e le applicazioni: TCP e UDP sono i suoi due strumenti fondamentali

Lascia un commento