UDP e' un protocollo di trasporto semplice, senza connessione, basato sul trasferimento di datagrammi.
Ogni operazione di output di un processo che usa il trasporto UDP produce esattamente un datagramma UDP, che viene incapsulato in un datagramma IP.
UDP non e' affidabile: invia i datagrammi ma non garantisce che arrivino a destinazione. E' l'applicativo che deve preoccuparsi dell'affidabilita' del servizio.
La testata UDP e' relativamente semplice.
I campi Porto Sorgente e Porto Destinazione identificano i punti terminali di comunicazione tra i processi comunicanti e la rete. Il campo Lunghezza e' dell'intero datagramma UDP (testata + dati) in byte. Il valore minimo e' 8, ma in realta' questo campo non viene gestito dal protocollo, che sa' che la lunghezza totale e' la lunghezza di un datagramma IP meno i 20 byte della testata IP. Il campo Checksum e' anch'esso opzionale.
Quando sono calcolati (per TCP e' obbligatorio) i campi Checksum di TCP e UDP vengono formati in un modo speciale, dovuto al fatto che il protocollo IP ha un campo checksum della sola testata IP.
Innanzi tutto la lunghezza del campo dati e' estesa ad un confine di 16 bit usando se necessario un campo finale di Pad posto a zero.
Viene formato uno pseudo-pacchetto composto da:
Il campo Checksum e' calcolato su questo pseudo-pacchetto come complemento a 1 della somma dei complementi a 1 di tutte le parole a 16 nit del pseudo-pacchetto.
Il checksum e' un campo di controllo end-to-end: e' calcolato dal mittente e verificato dal ricevitore del pacchetto. Se il pacchetto UDP e' errato, viene scartato silenziosamente, senza generazione di messaggi d'errore.
L'opzionalita' dei checksum di UDP implica una velocita' maggiore delle operazioni se disabilitata, ma puo' naturalmente fornire sorgenti irrecuperabili d'errori, specie su una rete non Ethernet o quando il datagramma UDP transiti da router.
E'molto facile che i datagrammi UDP siano frammentati in piu' pacchetti. Molti applicativi che usano UDP tendono ad impiegare messaggi molto lunghi (NFS usa buffer di 8 kbyte) per tentare di far entrare molte informazioni in un singolo datagramma.
Teoricamente la massima dimensione di un pacchetto IP e' 65535 byte; con in piu' le testate UDP e IP si arriva ad un massimo teorico di 65507 byte di dati in un datagramma UDP.
Il limite pratico puo' essere inferiore per due motivi:
Un effetto perverso si ha quando la rete supporta l'invio di datagrammi grandi ma l'applicativo ricevente ha un buffer di ricezione molto limitato. Molti applicativi che lavorano con UDP in questo caso semplicemente troncano il datagramma in ricezione, scartando i dati in eccesso.
Alcune versioni antiche di Berkley UNIX addirittura non notificano l'applicativo che il datagramma e' stato troncato.
Versioni derivate da UNIX SVR4 non scartano i dati in eccesso ma eseguono piu' letture del datagramma per incamerare tutti i dati in arrivo. A volte l'applicativo non e' conscio di aver eseguito piu' letture.
L'interfaccia TLI (Transport Level Interface) della AT&T non scarta i dati, ma ritorna un flag all'applicativo per indicare la necessita' di ulteriori operazioni di lettura.
Naturalmente, dato il volume di dati che UDP puo' generare su rete e la possibilita' elevata di frammentazione, il caso piu' frequente e' la generazione di messaggi ICMP:
Uno strano effetto di interazione tra UDP ed ARP si verifica quando i datagrammi sono appena superiori in dimensione a 8192 byte e abbisognano di frammentazione. Piu' frammenti sono generati e ciascuno di essi causa l'invio di una richiesta ARP. ARP scarta tutti i frammenti tranne l'ultimo (e' parte delle specifiche), ma genera le richieste troppo velocemente (non e' parte delle specifiche, che dicono di attendere circa un secondo tra due richieste successive alla stessa stazione). Quando un responso ARP arriva, lo ARP della stazione inviante ha gia' scartato tutti i pacchetti, tranne l'ultimo che viene inviato. Lo strato UDP del ricevente non ha la testata UDP in questo pacchetto e, non sapendo a quale porto destinarlo, lo scarta silenziosamente. Dopo un tempo di timeout, l'applicativo inviante ripete la trasmissione, che questa volta passa immediatamente poiche' lo ARP inviante gia' possiede la destinazione nella sua cache.
Attenzione che in questo caso, se il tempo di validita' della cache ARP e' inferiore al tempo di ritrasmissione dell'applicativo inviante, l'effetto malefico viene ripetuto e forse il datagramma non arrivera' mai a destinazione.