UDP: caratteristiche, struttura e applicazioni

// obiettivi di apprendimento
Descrivere le caratteristiche principali di UDP e il suo modello connectionless best-effort
Analizzare la struttura dell’header UDP a 8 byte e comprendere il calcolo del checksum
Classificare le applicazioni che preferiscono UDP e spiegare perché la latenza supera l’affidabilità in questi contesti
Comprendere il concetto di UDP come base per protocolli applicativi che implementano affidabilità custom (QUIC, DTLS)
📄
Slides
Header UDP, confronto latenza TCP/UDP, applicazioni
Scarica →

UDP — User Datagram Protocol

Definito in RFC 768 (1980) da Jon Postel, UDP è uno dei protocolli più semplici dell’intera suite TCP/IP. Solo 8 byte di header. Nessuna connessione, nessuna garanzia. Eppure alimenta alcune delle applicazioni più diffuse al mondo: DNS, streaming video, VoIP, gaming online.

// definizione formale
UDP è un protocollo di trasporto connectionless e best-effort: non stabilisce una connessione prima di inviare dati, non garantisce consegna, ordine o deduplicazione, e non implementa controllo del flusso né della congestione. Offre multiplexing/demultiplexing tramite porte e, opzionalmente, rilevamento degli errori tramite checksum (RFC 768).

Le 5 caratteristiche fondamentali di UDP

CaratteristicaDescrizione
ConnectionlessNessun handshake di apertura/chiusura. Ogni datagramma è indipendente
Best-effortNessuna garanzia di consegna, ordine, deduplicazione
LeggeroHeader 8 byte (TCP: min 20 byte). Overhead minimo
VeloceNo RTT di setup, no ACK, no ritrasmissioni, no controllo congestione
Message-orientedPreserva i confini dei messaggi (a differenza di TCP byte-stream)

Struttura dell’header UDP

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Source Port          |       Destination Port        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Length             |           Checksum            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Data (payload)                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CampoDimensioneDescrizione
Source Port16 bitPorta sorgente (facoltativa: può essere 0 se non serve risposta)
Destination Port16 bitPorta destinazione (obbligatoria per il demux)
Length16 bitLunghezza totale header + payload in byte. Valore minimo: 8
Checksum16 bitOpzionale in IPv4, obbligatorio in IPv6. Calcolato su pseudo-header IP + header UDP + dati
// nota — checksum UDP e pseudo-header

Il checksum UDP viene calcolato su un pseudo-header che include IP sorgente, IP destinazione, protocollo (17=UDP) e lunghezza UDP. Questo pseudo-header non viene trasmesso — serve solo per il calcolo. Lo stesso meccanismo è usato da TCP. In IPv4 il checksum UDP è opzionale, ma disabilitarlo è sconsigliato su reti inaffidabili. In IPv6 è obbligatorio (IPv6 non ha checksum header come IPv4).

Applicazioni di UDP — perché la latenza supera l’affidabilità

La scelta di UDP non è una scorciatoia pigra: è una decisione architetturale precisa. In certi contesti, ricevere un dato in ritardo è peggio che non riceverlo affatto.

Applicazione/ProtocolloPortaPerché UDP
DNS53 UDPQuery/risposta brevi (<512 byte), latency-critical. Timeout e retry gestiti dall’applicazione. Usa TCP solo per zone transfer o risposte >512 byte
DHCP67/68 UDPComunicazione a livello di broadcast di rete — TCP è connection-oriented e non applicabile
VoIP / RTPvariabileUna perdita = glitch audio (tollerabile). Un ritardo = conversazione impossibile (intollerabile). Ritardo costante prioritario sull’affidabilità
Streaming video (QUIC)443 UDPNetflix, YouTube usano QUIC (HTTP/3) su UDP. La perdita di un frame è nascosta dal codec; il ritardo della connessione TCP è inaccettabile
Online gamingvariabileLatenza minima critica per la giocabilità. Perdite gestite a livello applicativo (interpolazione, lag compensation)
SNMP161 UDPMonitoring con polling semplice — messaggi brevi, perdita occasionale accettabile
TFTP69 UDPTrasferimento file semplificato — TFTP implementa la propria affidabilità sopra UDP (stop-and-wait)
Tunnel / overlayvariWireGuard VPN usa UDP, VXLAN usa UDP 4789 — il tunnel gestisce la sicurezza/integrità a livello superiore

UDP come fondazione: QUIC e DTLS

Il fatto che UDP sia “inaffidabile” non significa che le applicazioni debbano convivere con la perdita. Molti protocolli moderni implementano affidabilità custom sopra UDP, guadagnando flessibilità rispetto a TCP:

// accenno — QUIC (RFC 9000)

QUIC (Google, 2012 → IETF RFC 9000, 2021) è un protocollo di trasporto che implementa affidabilità, ordine e crittografia TLS direttamente sopra UDP. Vantaggi rispetto a TCP+TLS: handshake 0-RTT/1-RTT (vs 3-way+TLS), nessun head-of-line blocking tra stream, migrazione di connessione (cambia IP senza rinegoziare). È la base di HTTP/3. Dettagli nella lezione L09.

// nota — DTLS

DTLS (Datagram TLS) adatta TLS per funzionare su UDP: aggiunge numeri di sequenza, retransmission timer e un meccanismo di riordino per gestire la natura datagram. Usato da WebRTC, VoIP sicuro (SRTP), VPN aziendali. La perdita di un record DTLS non blocca i successivi — a differenza di TLS su TCP.

📌 Riepilogo — Punti chiave
  • UDP è connectionless, best-effort, message-oriented: 8 byte di header, nessuna garanzia di consegna o ordine
  • Header: Source Port, Dest Port, Length, Checksum (16 bit ciascuno). Checksum opzionale in IPv4, obbligatorio in IPv6
  • UDP vince dove la latenza è più importante dell’affidabilità: DNS, VoIP, streaming, gaming, tunnel
  • A differenza di TCP, UDP è message-oriented: preserva i confini dei messaggi — ogni datagramma è un’unità atomica
  • UDP supporta broadcast e multicast: TCP no (è point-to-point connection-oriented)
  • UDP è la fondazione di protocolli moderni che implementano affidabilità custom: QUIC (HTTP/3), DTLS, TFTP, RTP

Lascia un commento