UDP: cosa si nasconde dietro allo User Datagram Protocol?

La co­mu­ni­ca­zio­ne dei sistemi nelle reti locali do­me­sti­che e aziendali e nelle reti pubbliche come Internet si basa di default sulla famiglia di pro­to­col­li Internet. Il com­po­nen­te più noto di questa gamma di pro­to­col­li è senza dubbio l’Internet Protocol (IP); questo non è solo re­spon­sa­bi­le dell’in­di­riz­za­men­to e della fram­men­ta­zio­ne di pacchetti di dati, ma definisce anche come vengono descritte le in­for­ma­zio­ni relative alla sorgente e alla de­sti­na­zio­ne.

La tra­smis­sio­ne dei dati viene ge­ne­ral­men­te operata dal pro­to­col­lo di trasporto TCP (Tran­smis­sion Control Protocol) con con­nes­sio­ne, da cui deriva la frequente de­no­mi­na­zio­ne delle reti con TCP/IP. TCP ga­ran­ti­sce sì la sicurezza ma è anche causa di un ritardo di tra­smis­sio­ne; così, nel 1980, David Patrick Reed pubblicò la sua idea relativa allo User Datagram Protocol (UDP), un’al­ter­na­ti­va al pro­to­col­lo standard più semplice e veloce.

Lo User Datagram Protocol, ab­bre­via­to UDP, è un pro­to­col­lo che consente l’invio senza con­nes­sio­ne di da­ta­gram­mi nelle reti basate su IP. Per rag­giun­ge­re i servizi de­si­de­ra­ti sugli host di de­sti­na­zio­ne, il pro­to­col­lo ricorre alle porte elencate come uno dei com­po­nen­ti prin­ci­pa­li nell’in­te­sta­zio­ne UDP. Come molti altri pro­to­col­li di rete, UDP rientra nella famiglia di pro­to­col­li Internet, sebbene questo vada clas­si­fi­ca­to nel livello di trasporto e quindi come istanza in­ter­me­dia­ria tra il livello di rete e quello di ap­pli­ca­zio­ne.

Con lo User Datagram Protocol un’ap­pli­ca­zio­ne può inviare delle in­for­ma­zio­ni molto ve­lo­ce­men­te, in quanto non occorre creare una con­nes­sio­ne con il de­sti­na­ta­rio né attendere una risposta. Tuttavia, non vi sono garanzie che i pacchetti arrivino interi e nella stessa sequenza in cui sono stati inviati. Inoltre, questo pro­to­col­lo è esposto a ma­ni­po­la­zio­ni o accessi di terzi. I pacchetti difettosi sono ri­co­no­sci­bi­li da una checksum (somma di controllo) opzionale (ob­bli­ga­to­ria in com­bi­na­zio­ne all’IPv6).

Per com­pren­de­re in dettaglio il fun­zio­na­men­to della tra­smis­sio­ne a pacchetto con il pro­to­col­lo, è im­por­tan­te esaminare con più esattezza le ca­rat­te­ri­sti­che men­zio­na­te in merito allo User Datagram Protocol.

1. UDP è senza con­nes­sio­ne: il trasporto di dati mediante pro­to­col­lo UDP si con­trad­di­stin­gue per il fatto che avviene senza stabilire una con­nes­sio­ne tra mittente e de­sti­na­ta­rio. I ri­spet­ti­vi pacchetti sono inviati in sequenza all’indirizzo IP preferito, indicando la porta di de­sti­na­zio­ne, senza che il computer che si cela dietro di essa debba fornire una risposta. Se vanno rispediti anche dei pacchetti al mittente, l’in­te­sta­zio­ne UDP può contenere op­zio­nal­men­te anche la porta sorgente.
2. UDP utilizza le porte: UDP ricorre come TCP alle porte per tra­smet­te­re i pacchetti ai giusti pro­to­col­li suc­ces­si­vi o le ap­pli­ca­zio­ni de­si­de­ra­te al sistema di de­sti­na­zio­ne. Le porte sono definite secondo il modello com­pro­va­to per numeri, laddove i numeri compresi tra 0 e 1023 sono assegnati a servizi fissi.
3. UDP consente una co­mu­ni­ca­zio­ne rapida e senza ritardi: il pro­to­col­lo di trasporto è adatto a una tra­smis­sio­ne rapida dei dati, in quanto basato su una con­fi­gu­ra­zio­ne senza con­nes­sio­ne. Ciò deriva dal fatto che la perdita di singoli pacchetti influisce solo sulla qualità della tra­smis­sio­ne. Nei col­le­ga­men­ti TCP, i pacchetti persi vengono richiesti nuo­va­men­te in au­to­ma­ti­co, causando il ristagno dell’intero processo di tra­smis­sio­ne.
4. UDP non offre alcuna garanzia in merito alla sicurezza e alla genuinità dei dati: la rinuncia a un'au­ten­ti­ca­zio­ne reciproca di mittente e de­sti­na­ta­rio permette la straor­di­na­ria velocità del pro­to­col­lo UDP, ma questo non ga­ran­ti­sce né la com­ple­tez­za né la sicurezza dei pacchetti di dati. Anche l'invio dei pacchetti in sequenza corretta non è garantito. Pertanto, i servizi che si avvalgono dell’UDP mettono a di­spo­si­zio­ne misure di cor­re­zio­ne e pro­te­zio­ne proprie.

Come la maggior parte dei pro­to­col­li, i pacchetti UDP si com­pon­go­no ge­ne­ral­men­te di un’in­te­sta­zio­ne (header) e dei dati d’uso effettivi. L’header UDP contiene tutte le in­for­ma­zio­ni ne­ces­sa­rie per la tra­smis­sio­ne dei dati con il pro­to­col­lo di trasporto e un pacchetto UDP iden­ti­fi­ca­bi­le come tale. Suddivisa in due blocchi da 32 bit con 4 diversi campi di dati, la struttura appare come segue:

I primi 16 bit dell’in­te­sta­zio­ne rivelano la porta sorgente mediante cui viene inviato il ri­spet­ti­vo pacchetto di dati. Il de­sti­na­ta­rio ha bisogno di questa in­for­ma­zio­ne per poter ri­spon­de­re al pacchetto. Dato che l’UDP non si avvale di una con­nes­sio­ne e non prevede so­stan­zial­men­te in­te­ra­zio­ni di nessun tipo tra mittente e de­sti­na­ta­rio, questo campo è opzionale. Pertanto, in questa posizione viene impostato ge­ne­ral­men­te il valore “0”.

Nel campo suc­ces­si­vo sono indicati la porta di de­sti­na­zio­ne e il servizio con­trol­la­to. Al contrario della porta sorgente, questa in­for­ma­zio­ne è ob­bli­ga­to­ria, in quanto, al­tri­men­ti, il da­ta­gram­ma non può essere assegnato in modo corretto.

La lunghezza del da­ta­gram­ma viene definita nel campo della lunghezza. Essa include la lunghezza dell’in­te­sta­zio­ne (8 byte) e l’entità dei dati d’uso (massimo teorico: 65.535 byte). Se si impiega un IPv4, il limite effettivo per i dati d’uso è di 65.507 byte, una volta detratte le in­te­sta­zio­ni IP e UDP. Per l’IPv6 sono possibili pacchetti (co­sid­det­ti jumbogram) che superano il massimo. Secondo RFC 2675, in un caso simile, il valore del campo di lunghezza è pari a “0”.

Il com­ple­ta­men­to dell’header UDP co­sti­tui­sce la checksum che serve al ri­co­no­sci­men­to degli errori nella tra­smis­sio­ne. In questo modo è possibile ri­co­no­sce­re le ma­ni­po­la­zio­ne dei dati trasmessi; tuttavia, i pacchetti cor­ri­spon­den­ti vengono scartati senza la necessità di una nuova richiesta. La checksum viene generata unendo parti

• dell’header UDP,
• dei dati d’uso
• e del co­sid­det­to pseudo header (contiene le in­for­ma­zio­ni dell’in­te­sta­zio­ne IP).

La checksum è opzionale nell’IPv4, ma viene impiegata come standard dalla maggior parte delle ap­pli­ca­zio­ni. Se la checksum è assente, questo campo va impostato con valore “0”. Se l’UDP viene impiegato in com­bi­na­zio­ne all’IPv6, la checksum è ob­bli­ga­to­ria.

Per via della sua struttura mi­ni­ma­li­sta e del­l'as­sen­za di mec­ca­ni­smi per garantire una tra­smis­sio­ne completa e di successo, lo User Datagram Protocol non è im­pie­ga­bi­le come pro­to­col­lo di trasporto uni­ver­sa­le. In un primo momento era stato pro­get­ta­to prin­ci­pal­men­te per ap­pli­ca­zio­ni che non ne­ces­si­ta­va­no (ancora) di un servizio di tra­smis­sio­ne af­fi­da­bi­le. Il campo d’impiego dell’UDP è pertanto limitato, ma va evi­den­zia­to l’enorme valore di questo pro­to­col­lo, come di­mo­stra­no le seguenti classi di ap­pli­ca­zio­ne per UDP:

• Ap­pli­ca­zio­ni “Best-Effort-Delivery”: lo scenario d’impiego classico per l’UDP è rap­pre­sen­ta­to da ap­pli­ca­zio­ni basate su una “consegna di dati con il massimo sforzo”. Ai programmi che sfruttano lo User Datagram Protocol come servizio di “best effort”, è suf­fi­cien­te una tra­smis­sio­ne non af­fi­da­bi­le delle in­for­ma­zio­ni, perché ripetono le in­for­ma­zio­ni re­go­lar­men­te. Sono un esempio le ap­pli­ca­zio­ni che tra­smet­to­no i valori di misura o che eseguono di continuo gli stessi incarichi di lavoro.
• Ap­pli­ca­zio­ni leggere: l’overload ridotto del pro­to­col­lo di trasporto offre un supporto ottimale per ap­pli­ca­zio­ni di facile co­stru­zio­ne. Insieme alla rinuncia a una struttura di con­nes­sio­ne, questi programmi be­ne­fi­cia­no di una per­for­man­ce par­ti­co­lar­men­te elevata nell’ela­bo­ra­zio­ne e nell’inoltro di pacchetti di dati nelle reti.
• Ap­pli­ca­zio­ni con mec­ca­ni­smi propri per una tra­smis­sio­ne af­fi­da­bi­le: l’UDP può essere in­te­res­san­te anche per ap­pli­ca­zio­ni che si basano su una con­di­vi­sio­ne af­fi­da­bi­le delle in­for­ma­zio­ni, ma con mec­ca­ni­smi propri per ri­spon­de­re ai pacchetti. Il vantaggio di tali servizi è che non sono vincolati da schemi fissi per garantire la com­ple­tez­za e la cor­ret­tez­za dei pacchetti di dati inviati. Potrete decidere au­to­no­ma­men­te come e quando reagire a in­for­ma­zio­ni errate o non clas­si­fi­ca­te.
• Ap­pli­ca­zio­ni multicast: mentre i pro­to­col­li di trasporto af­fi­da­bi­li come TCP sono limitati all’uso della co­mu­ni­ca­zio­ne end-to-end, il pro­to­col­lo UDP supporta anche con­nes­sio­ni IP multicast. Se un’ap­pli­ca­zio­ne deve inviare dei pacchetti IP in modo rapido ed ef­fi­cien­te a tanti de­sti­na­ta­ri in con­tem­po­ra­nea, l’UDP co­sti­tui­sce una base adeguata.
• Ap­pli­ca­zio­ni in tempo reale (Real-time Ap­pli­ca­tions): infine, l’UDP è adatto anche come pro­to­col­lo di trasporto per servizi che operano con requisiti in tempo reale, come tra­smis­sio­ni audio o video. Questi devono essere in grado di con­trol­la­re au­to­no­ma­men­te l’invio, la ricezione e la ri­pro­du­zio­ne dei flussi di dati, il che è possibile senza dif­fi­col­tà con la tra­smis­sio­ne UDP senza con­nes­sio­ne.