Protocollo UDP

UDP (User Datagram Protocol) è il protocollo di base per scambiare dati impacchettati al livello di trasporto. È un protocollo senza connessione (connectionless) e non affidabile: non aggiunge niente ai servizi di IP (Datagramma IP e frammentazioneIPv4 è un servizio senza connessione, non affidabile, best effort: i pacchetti (datagrammi) possono essere persi, corrotti, riordinati o ritardati. L'intestazione ha 20-60 byte (HLen conta parole da 4 byte, da 5 a 15); il campo Total Length (16 bit) dà la lunghezza totale fino a 65 535 byte; TTL limita i salti, Protocol identifica il protocollo trasportato (1 ICMP, 6 TCP, 17 UDP), il checksum copre solo l'intestazione. Se un datagramma è più grande dell'MTU del collegamento viene frammentato: solo il payload si divide, ogni frammento ha un'intestazione propria; l'Offset (13 bit) è in unità di 8 byte, MF=1 in tutti i frammenti tranne l'ultimo, e il riassemblaggio avviene solo a destinazione.Datagramma IP e frammentazione →) tranne la comunicazione da processo a processo invece che da host a host, cioè i numeri di porta (Livello di trasporto - porte e multiplexingIl livello di trasporto (transport layer) offre la comunicazione logica end-to-end tra processi applicativi di host diversi, ed è realizzato solo negli host finali, non nei router. Il livello di rete consegna al computer giusto (indirizzo IP), il trasporto consegna al processo giusto (numero di porta di 16 bit, 0-65535). Una porta più un indirizzo IP formano un socket; la quaterna (IP sorgente, porta sorgente, IP destinazione, porta destinazione) identifica una connessione. I servizi sono: comunicazione processo-processo, indirizzamento, incapsulamento/decapsulamento, multiplexing/demultiplexing e, se il protocollo è affidabile, controllo di errore, di flusso e di congestione. I protocolli sono UDP (senza connessione, inaffidabile), TCP (con connessione, affidabile) e SCTP (combina i due).Livello di trasporto - porte e multiplexing →). I segmenti UDP possono quindi andare persi o arrivare fuori ordine all'applicazione.

Se è così "debole", perché usarlo?

Un processo che vuole inviare un breve messaggio e non si cura molto dell'affidabilità ci mette molto meno con UDP che con TCP, perché c'è molta meno interazione tra mittente e destinatario:

• niente instaurazione della connessione, che aggiungerebbe ritardo: la "connessione" si considera aperta quando arriva il primo datagramma;
• niente controllo di congestione: UDP può inviare alla velocità che l'applicazione vuole;
• semplice: nessuno stato di connessione né al mittente né al destinatario (stateless);
• intestazione piccola: 8 byte contro i 20 (almeno) di TCP, quindi meno overhead e ritardo minimo;
• permette il multicast (un pacchetto IP verso molti destinatari).

Formato del pacchetto

I pacchetti UDP (user datagram) hanno un'intestazione di 8 byte, divisa in quattro campi da 16 bit:

• Porta sorgente e porta destinazione (16 bit ciascuna): i numeri di porta dei processi.
• Lunghezza (16 bit): lunghezza totale, intestazione più dati, in byte. Con 16 bitcon k bit si rappresentano i numeri da 0 a 2^k − 1Sistemi di numerazione posizionali → il valore massimo sarebbe $2^{16}-1=65\,535$; poiché il datagramma UDP viaggia dentro un datagramma IP, che ha almeno 20 byte di intestazione ed è lungo al massimo $65\,535$ byte, i dati UDP sono al massimo $65\,535-20-8=65\,507$ byte (dal totale IP si tolgono i $20$ byte dell'intestazione IP e gli $8$ di UDP). Il valore minimo è 8 (nessun dato).
• Checksum (16 bit): controllo d'errore, facoltativo.

Formula (dati utili in un datagramma UDP). $\text{dati}=\text{lunghezza UDP}-8$.

Esempio. Un datagramma con lunghezza $12$ trasporta $12-8=4$ byte di dati. Un messaggio più grande di $65\,507$ byte non si può inviare con un solo UDP: UDP non spezza un flusso in datagrammi correlati, quindi può essere usato solo da processi che inviano messaggi brevi.

I servizi di UDP

• Processo-processo: usa gli indirizzi di socket $\langle\text{IP},\text{porta}\rangle$.
• Senza connessione: ogni user datagram è indipendente dagli altri, non è numerato (nessun numero di sequenza), non c'è apertura né chiusura della connessione e ogni datagramma può seguire un percorso diverso.
• Controllo di flusso: assente. Non c'è finestra, e il ricevente può essere sommerso dai messaggi.
• Controllo di errore: nessuno, tranne il checksum. Il mittente non sa se un messaggio è andato perso; se il checksum rivela un errore, il datagramma viene scartato.
• Controllo di congestione: assente. UDP presume che i pacchetti siano piccoli e sporadici e non possano creare congestione (non sempre è vero: un flusso video in UDP non rallenta quando la rete è carica, a scapito dei flussi TCP: TCP - controllo di congestioneLa congestione nasce quando collegamenti veloci alimentano un collegamento lento: le code dei router si riempiono, i pacchetti si perdono o ritardano e, nel caso peggiore, la rete collassa (quasi solo ritrasmissioni). TCP controlla la propria finestra di congestione cwnd con il feedback delle perdite (timeout o tre ACK duplicati): slow start (cwnd raddoppia a ogni RTT) fino alla soglia ssthresh, poi congestion avoidance (+1 MSS per RTT); a ogni perdita ssthresh = W/2. Le varianti si distinguono per come reagiscono ai tre dupACK: Tahoe riparte da cwnd = 1 dopo la ritrasmissione rapida; Reno usa il fast recovery (ssthresh = cwnd/2, cwnd = ssthresh + 3, +1 per ogni altro dupACK); NewReno gestisce gli ACK parziali e recupera più perdite nella stessa finestra; SACK riscontra i blocchi ricevuti e ritrasmette solo quello che manca.TCP - controllo di congestione →).
• Incapsulamento e decapsulamento: aggiunge e toglie l'intestazione di 8 byte.
• Multiplexing e demultiplexing: in un host c'è un solo UDP ma molti processi che lo usano; UDP smista i datagrammi in arrivo in base alla coppia (IP destinazione, porta destinazione).

Il checksum e la pseudo-intestazione

Il checksum UDP si calcola su tre parti: una pseudo-intestazione, l'intestazione UDP e i dati dell'applicazione. La pseudo-intestazione è un pezzo dell'intestazione del pacchetto IP in cui il datagramma UDP verrà incapsulato, con alcuni campi riempiti con zeri; non viene trasmessa, serve solo per il calcolo:

Perché la pseudo-intestazione? Mettere nel controllo anche le informazioni di IP è una protezione in più: un datagramma consegnato all'host sbagliato (indirizzo corrotto) o al protocollo sbagliato viene rivelato. Però viola il principio dei livelli: UDP deve conoscere informazioni di IP che in teoria non dovrebbe vedere (per esempio il numero di protocollo, che il livello IP del ricevente deve passargli). È un caso in cui la stratificazione rigida è stata sacrificata alla praticità.

Formula (checksum UDP). Si sommano tutte le parole da 16 bit di pseudo-intestazione, intestazione (con il campo checksum posto a $0$) e dati (se i byte sono dispari si aggiunge un byte di zeri in fondo); i riporti oltre il sedicesimo bit si sommano al risultato (aritmetica a complemento a uno); il checksum è il complemento a uno (NOT bit a bit) della somma. Il ricevente somma tutte le parole, checksum compreso: se non ci sono errori ottiene $\texttt{FFFF}$.

Perché funziona: se $S$ è la somma (a 16 bit, con il riporto riportato in coda, vedi Aritmetica binariaSomma e sottrazione in binario, overflow per senza segno (riporto) e per complemento a 2 (segni), flag del processore, moltiplicazione per somme e scorrimenti, algoritmo di Booth, divisione, shift logici e aritmetici.Aritmetica binaria →) e il checksum è $\overline S$ (NOT bit a bit, Algebra di Boole e porte logicheVariabili booleane, operatori AND, OR, NOT e derivati (NAND, NOR, XOR, XNOR) con tabelle di verità; assiomi e teoremi dell'algebra di Boole, De Morgan; porte logiche e completezza di NAND e NOR; semplificazione algebrica con esempio.Algebra di Boole e porte logiche →), allora in ogni posizione di bit uno dei due vale $1$ e l'altro $0$: $S+\overline S$ ha tutti i bit a $1$, cioè $\texttt{FFFF}$. Se durante il viaggio un bit cambia, la somma cambia e il risultato del ricevente non è più $\texttt{FFFF}$. Il riporto oltre il sedicesimo bit si riaggiunge perché l'addizione è fatta modulo $2^{16}-1$ (complemento a uno), non modulo $2^{16}$.

Esempio completo. Un host $192.168.0.1$ invia dalla porta $5000$ alla porta $53$ dell'host $192.168.0.199$ i quattro byte Ciao (in esadecimale $43\,69\,61\,6F$). Lunghezza UDP $=8+4=12=\texttt{000C}$. Conversioni in esadecimale (Basi di numerazione e conversioni - binario, ottale ed esadecimaleUn numero in base $r$ vale $\sum a_i r^i$ (cifre $a_i\in{0,\dots,r-1}$). Conversioni: base $r\to$ decimale con la somma pesata; decimale $\to$ base $r$ per divisioni successive (parte intera, resti letti dal basso) e moltiplicazioni successive (parte frazionaria, parti intere lette dall'alto); binario $\leftrightarrow$ ottale/esadecimale a gruppi di 3/4 bit. Somma, differenza e prodotto binari seguono le regole decimali con cifre 0 e 1; la differenza ha prestiti, il prodotto somma prodotti parziali traslati.Basi di numerazione e conversioni - binario, ottale ed esadecimale →): ogni byte dell'IP si scrive con due cifre, $192=12\cdot16+0=\texttt{C0}$, $168=10\cdot16+8=\texttt{A8}$, $199=12\cdot16+7=\texttt{C7}$; le porte: $5000=1\cdot4096+3\cdot256+8\cdot16+8=\texttt{1388}$, $53=3\cdot16+5=\texttt{0035}$; i caratteri sono in ASCII (Codici binari - BCD, ASCII, Unicode, parità e GrayUn codice binario a $n$ bit distingue $2^n$ elementi. BCD: una cifra decimale ogni 4 bit (1010–1111 non usati; 10 richiede 8 bit, non è il binario del numero). ASCII: 7 bit per 128 caratteri, la cifra ASCII è 011 seguito dal BCD. Unicode/UTF-8: da 1 a 4 byte, compatibile con ASCII. Bit di parità: rileva errori su un numero dispari di bit. Distanza di Hamming = numero di bit diversi. Codice Gray: numeri consecutivi differiscono di un solo bit (sensori di posizione); si costruisce per riflessione o con $g_i=b_i\oplus b_{i+1}$.Codici binari - BCD, ASCII, Unicode, parità e Gray →): C$=\texttt{43}$, i$=\texttt{69}$, a$=\texttt{61}$, o$=\texttt{6F}$. Parole:

Somma della pseudo-intestazione, passo per passo: $\texttt{C0A8}+\texttt{0001}=\texttt{C0A9}$; $+\texttt{C0A8}=\texttt{18151}$; $+\texttt{00C7}=\texttt{18218}$; $+\texttt{0011}=\texttt{18229}$; $+\texttt{000C}=\texttt{18235}$. Somma di intestazione e dati: $\texttt{1388}+\texttt{0035}=\texttt{13BD}$; $+\texttt{000C}=\texttt{13C9}$; $+\texttt{0000}$ resta $\texttt{13C9}$; $+\texttt{4369}=\texttt{5732}$; $+\texttt{616F}=\texttt{B8A1}$. Totale: $\texttt{18235}+\texttt{B8A1}=\texttt{23AD6}$ (cinque cifre: il riporto è la cifra più a sinistra). Il riporto oltre i 16 bit (il "2") si somma al resto: $\texttt{3AD6}+2=\texttt{3AD8}$. Complemento: $\texttt{FFFF}-\texttt{3AD8}=\texttt{C527}$ (sottrarre da $\texttt{FFFF}$ equivale a negare ogni bit), che è il checksum da scrivere nell'intestazione. Controllo del ricevente: $\texttt{3AD8}+\texttt{C527}=\texttt{FFFF}$ ✓.

Checksum facoltativo e valori speciali

Il checksum UDP è facoltativo: se non lo si vuole, il campo si pone tutto a $0$. Questo crea un'ambiguità: se il mittente lo calcola e il risultato è proprio $0000$, si trasmette $\texttt{FFFF}$ al suo posto (nel complemento a uno $0$ e $\texttt{FFFF}$ sono la stessa quantità, "zero con segno").

Esempio. Se i dati fossero $\texttt{4369}\ \texttt{2697}$ invece di $\texttt{4369}\ \texttt{616F}$, la somma totale diventerebbe $\texttt{FFFF}$ dopo il riporto; il complemento è $\texttt{0000}$ e al suo posto si invia $\texttt{FFFF}$. Il caso opposto, risultato $\texttt{FFFF}$, non può capitare: richiederebbe una somma uguale a $0$, ma la pseudo-intestazione contiene $\texttt{0011}\neq0$.

Il checksum rivela errori ma non li corregge, e si limita a scartare il datagramma: l'applicazione non viene avvisata.

Applicazioni tipiche di UDP

UDP è adatto a:

• un processo che ha bisogno di una semplice comunicazione richiesta-risposta, con poca attenzione al controllo di flusso e di errore (per esempio DNS, Livello applicazione - DNSIl DNS (Domain Name System) traduce i nomi (www.amazon.com) negli indirizzi IP, perché le persone preferiscono i nomi e i protocolli TCP/IP usano gli indirizzi. È un database distribuito e gerarchico: albero rovesciato con radice, domini di primo livello e sottodomini (al più 128 livelli); le informazioni sono su tanti server (13 server radice) e i nuovi domini si registrano presso un registrar accreditato ICANN. Ogni ISP ha un DNS locale, il cui indirizzo l'host riceve con DHCP: l'host (resolver) gli manda la richiesta, di solito su UDP, e il DNS locale interroga radice, dominio di primo livello e server dell'organizzazione. Ogni server che impara un'associazione la tiene in cache, marcando la risposta non autoritativa, e la scarta dopo il TTL. Record (nome, tipo, valore, classe, TTL). Con il NAT il DNS deve restituire l'indirizzo pubblico. Quattro attacchi: macchina compromessa, risposta falsa all'host, avvelenamento della cache del DNS locale, server DNS malevolo.Livello applicazione - DNS →);
• un processo con meccanismi interni di controllo di flusso e di errore: il TFTP (Trivial File Transfer Protocol) li ha già, quindi può usare UDP;
• il multicast;
• processi di gestione di rete come SNMP;
• alcuni protocolli di aggiornamento delle tabelle di instradamento, come RIP, porta $520$ (Protocolli di instradamento - RIP, OSPF e BGPIn Internet l'instradamento non si può fare con un solo protocollo, per scalabilità (tabelle troppo grandi) e per autonomia amministrativa: ogni ISP è un sistema autonomo (AS) con il proprio algoritmo. All'interno di un AS si usano i protocolli IGP: RIP (distance vector, numero di salti, massimo 15, aggiornamenti ogni circa 30 s, su UDP porta 520) e OSPF (link state con Dijkstra, aree collegate all'area 0, cinque tipi di LSA, messaggi direttamente in IP). Tra AS si usa BGP4 (path vector, su TCP porta 179, eBGP tra AS e iBGP dentro l'AS, scelta del percorso per politica: preferenza locale, AS-PATH più corto, origine; i cicli si evitano scartando i cammini che contengono già il proprio AS; quattro messaggi: Open, Keepalive, Notification, Update).Protocolli di instradamento - RIP, OSPF e BGP →);
• l'assegnazione degli indirizzi con DHCP, porte $67$ e $68$ (Protocollo DHCPDopo che a un'organizzazione è stato assegnato un blocco di indirizzi, configurare a mano IP e netmask di ogni host non è efficiente. BOOTP (obsoleto) associa in modo statico un indirizzo MAC a un indirizzo IP; DHCP (Dynamic Host Configuration Protocol) assegna gli indirizzi in modo dinamico, a prestito (lease) per un tempo limitato, anche a sistema operativo già avviato. Il dialogo client-server è su UDP (porta 67 server, 68 client) e usa quattro messaggi: DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, DHCPACK (più DHCPRELEASE a fine uso). Nell'ACK arrivano IP, netmask, default gateway e server DNS.Protocollo DHCP →): il client non ha ancora un IP e non potrebbe aprire una connessione TCP;
• le applicazioni interattive in tempo reale (audio, video, giochi) che non tollerano ritardi irregolari tra le parti di un messaggio: spesso implementano un loro controllo di flusso e di errore e usano tecniche per interpolare i dati mancanti;
• traceroute, che invia datagrammi UDP verso una porta volutamente inesistente per provocare gli errori ICMP che gli servono (Protocollo ICMPIPv4 non ha meccanismi per segnalare o correggere gli errori né per interrogare host e router: li fornisce l'ICMP (Internet Control Message Protocol), un protocollo di rete i cui messaggi viaggiano dentro datagrammi IP con campo Protocol $=1$. I messaggi sono di errore (destination unreachable, tipo 3; time exceeded, tipo 11; redirect, tipo 5; parameter problem, tipo 12), sempre inviati alla sorgente originale e con l'intestazione IP più i primi 8 byte del datagramma che ha causato l'errore, oppure di interrogazione (echo request 8 e reply 0, timestamp 13-14). ICMP segnala ma non corregge. Con l'echo si fanno ping (RTT) e scoperta dell'MTU (bit D, codice 4, payload massimo $1500-20-8=1472$ byte); con time exceeded e port unreachable si fa traceroute ($n+1$ messaggi con TTL crescente). Attacchi: smurf e redirect.Protocollo ICMP →).

Esempio (overhead). Un pacchetto di voce con $160$ byte di audio ha $8$ byte di UDP e $20$ di IP: l'efficienza al livello di trasporto e rete, cioè byte utili diviso byte totali, è $\eta=\frac{L}{L+H}=160/(160+8+20)=85{,}1\%$. Con TCP (intestazione $20$ byte) sarebbe $160/(160+20+20)=160/200=80\%$, ma con in più l'attesa dell'handshake e gli ACK. Il grafico mostra come $\eta=L/(L+28)$ per UDP e $L/(L+40)$ per TCP (intestazioni di trasporto e rete) cresce con il payload $L$: i pacchetti piccoli, tipici della voce, pagano di più l'intestazione.