Il confronto definitivo: TCP vs UDP
| 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à | Più lento (overhead di setup e 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ì |
| Half-open connections | Sì (TIME_WAIT, FIN_WAIT) | N/A — nessuna connessione |
| Esempi applicativi | HTTP/S, SSH, FTP, SMTP, database | DNS, VoIP, streaming, gaming, DHCP |
| RFC | RFC 9293 (2022) | RFC 768 (1980) |
Criteri di scelta — quando usare TCP
- 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
- 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?
Limiti di TCP che QUIC risolve
| Problema TCP | Soluzione QUIC |
|---|---|
| Head-of-line blocking: la perdita di un pacchetto blocca tutti gli stream successivi | Stream indipendenti: la perdita su uno stream non blocca gli altri |
| Latenza di setup: 3-way handshake + TLS handshake = 2–3 RTT prima dei dati | 0-RTT o 1-RTT: crittografia e dati nella stessa fase di handshake |
| Ossificazione: i middlebox (firewall, NAT, load balancer) ispezionano TCP e bloccano varianti | Payload completamente cifrato — i middlebox vedono solo UDP |
| Connection migration: cambiare IP (es. WiFi → 4G) rompe la connessione TCP | Connection 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)
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
- 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