Una guida a UDP (User Datagram Protocol)

Il protocollo User Datagram è simile al “Brutto anatroccolo” di Hans Christian Andersen. Dopo decenni di essere trascurato e ridicolizzato, questo semplice protocollo ha attirato improvvisamente gli ammiratori come protocollo di trasporto per le nuove e glamour applicazioni multimediali rese possibili dalle velocità della banda larga. Oggi, qualsiasi applicazione che deve fornire dati sceglie rapidamente UDP rispetto al TCP (Transmission Control Protocol) precedentemente dominante.

Storia UDP

UDP esiste da quasi il tempo di Internet. Internet è nata nel maggio 1974 quando l’Istituto di Ingegneri elettrici ed elettronici pubblicò “Un programma per l’intercomunicazione della rete di pacchetti“Di Vint Cerf e Bob Khan. Il concetto doveva essere sviluppato e sia Khan che Cerf hanno continuato a perfezionare le loro idee mentre lavoravano per il governo degli Stati Uniti Agenzia per i progetti di ricerca avanzata sulla difesa, che è anche noto come DARPA. John Postel è stato coinvolto e ha suggerito di suddividere la singola struttura proposta nell’idea originale di Cerf e Khan. Questo ha creato un concetto a strati. Il programma di controllo della trasmissione originale contenuto nello schema del 1974 è stato suddiviso nel protocollo di controllo della trasmissione a un livello superiore e nel protocollo Internet a un livello inferiore (quindi TCP / IP).

L’approccio modulare di Postel aveva senso quando il team iniziò a pensare all’implementazione della teoria. C’era una chiara divisione del lavoro tra ciò che divenne noto come Livello di trasporto, che è la posizione del protocollo di controllo della trasmissione e Strato Internet, dove risiede il protocollo Internet. Tuttavia, Cerf e Khan hanno previsto la necessità di un’opzione accelerata. Hanno elaborato un diagramma di come i dati sarebbero preparati per la trasmissione passando da uno strato all’altro. Le attività di elaborazione sono state rappresentate come una linea verticale dritta, scendendo attraverso il loro nuovo diagramma a pila che mostra la progressione da applicazione su TCP e su IP.

Quando si trattava di disegnare sulla corsia preferenziale, non volevano tracciare una linea di deviazione curva che evitasse di passare attraverso TCP. Invece, hanno disegnato una forma oblunga che rappresentava lo strato Internet un po ‘più largo del blocco che rappresentava lo strato di trasporto. Con questa regolazione visiva, sia il percorso normale che il percorso di corsia preferenziale potrebbero scendere attraverso lo stack come linee parallele. Tuttavia, questo trucco ha lasciato un vuoto che Postel sentiva di dover colmare. Questo è il motivo per cui è stato inventato il User Datagram Protocol. Era lì solo per rendere equilibrato il diagramma dello stack del protocollo.

I vantaggi di TCP

Il protocollo di controllo della trasmissione fornisce servizi essenziali ai dati in transito. Assicura che tutti i pacchetti in uno stream arrivino effettivamente e controlla che arrivino in ordine. Queste procedure di controllo che assicurano un trasferimento ordinato non sono possibili senza una misura di coordinamento tra le due parti. Pertanto, TCP stabilisce innanzitutto un accordo tra i due dispositivi che intendono scambiare dati. Questo accordo è chiamato una sessione. È anche la definizione stessa di un “connessione.”UDP non ha procedure di creazione di sessioni e quindi è definito”senza connessione.”

La sessione fornisce a entrambi i lati della connessione un numero di riferimento che possono taggare nei loro scambi amministrativi. La sessione consente inoltre di introdurre il concetto di porte. L’ID sessione è in realtà una combinazione di identificatori contenuti nell’intestazione TCP. Con questo ID, i progettisti delle procedure TCP sono stati in grado di elaborare l’idea di un “presa di corrente.”I numeri di porta sono inoltre assegnati a UDP, tuttavia, quel protocollo può utilizzare solo l’IP di destinazione e i numeri di porta come identificatore univoco. Un identificatore derivato da quella combinazione bloccherebbe tutti gli altri processi che tentano di accedere alla stessa porta, anche se erano in esecuzione su computer diversi, quindi UDP è stato creato un sistema di sola consegna, senza procedure per abilitare una finestra di dialogo bidirezionale.

I concetti di connessione TCP si sono tutti sviluppati in un metodo universale molto sofisticato per garantire che i dati che passano tra i computer non siano stati confusi o confusi. Il socket ha consentito l’apertura simultanea di più connessioni tra gli stessi due computer. Quell’idea ha creato la possibilità di avere più di un canale operativo per passare i dati. Questa è una procedura di uso frequente di cui hanno beneficiato molte delle prime applicazioni di rete. Il File Transfer Protocol, ad esempio, utilizza due canali: uno per passare i dati e un canale separato per le comunicazioni amministrative. I diversi numeri di porta per i dati e i canali di controllo creano due socket distinti.

L’ID univoco per ciascuna sessione indicava che TCP ha aggiunto valore alla comunicazione tra due computer. Alla fine degli anni ’70 e all’inizio degli anni ’80 solo le grandi organizzazioni e istituzioni accademiche avevano computer e reti. Pertanto, era molto probabile che due organizzazioni necessitassero che i loro grandi mainframe si collegassero contemporaneamente tra loro per scopi diversi. Mentre un professore stava inviando un file a un collega di un’altra università, un ricercatore potrebbe anche voler aprire una sessione Telnet al computer nella stessa università remota. Grazie a TCP, due computer sono in grado di mantenere più connessioni contemporaneamente e ciascuna di queste sessioni può gestire più canali contemporaneamente. Tali connessioni simultanee non sarebbero possibili se le comunicazioni fossero regolate solo dal protocollo Internet con l’assegnazione di un indirizzo IP per computer. UDP, senza alcun meccanismo di sessione, non era in grado di gestire le applicazioni che richiedevano a un computer contattato di inviare una risposta.

La sicurezza dei dati

I brillanti costrutti del TCP hanno reso possibili le connessioni tra le reti e Internet ha iniziato ad espandersi oltre il mondo accademico verso il mondo degli affari. La creazione del World Wide Web, che è diventato pubblico nel 1991 era possibile solo a causa della facilità con cui la pagina Web che trasportava Hypertext Transfer Protocol (HTTP) poteva sedere su TCP.

Gli accademici e i tecnici che hanno messo insieme Internet e poi sviluppato il World Wide Web accessibile al pubblico lo erano pensatori di cieli blu. Erano entusiasti della tecnologia e delle sue possibilità di accelerare la ricerca e migliorare l’interazione tra persone di tutto il mondo. Non sono riusciti a rendere conto del fatto che la loro meravigliosa invenzione è stata un dono per ladri, truffatori e terroristi urbani. Né Internet né il World Wide Web avevano alcuna sicurezza.

Ci è voluto per il consumatore Netscape Corporation per individuare questo problema. Netscape ha prodotto il browser Web leader a livello mondiale e lo ha distribuito gratuitamente per incoraggiare l’adozione di Internet da parte del pubblico in generale. Il piano ha funzionato e si sono diffusi scambi di informazioni e canali di contatto, incoraggiando un numero maggiore di cittadini a iscriversi ai servizi Internet. comunque, il la mancanza di sicurezza ha rappresentato un ostacolo alla commercializzazione del Web. Senza la capacità di invogliare le persone a pagare per i servizi online, non vi era alcun incentivo per le imprese a investire nello sviluppo di nuove applicazioni, siti Web o servizi online.

Il principale ostacolo alla raccolta di pagamenti sul Web è stata la sua mancanza di sicurezza. Alcuni titoli sul furto di dati sulle trasmissioni su Internet escludono la possibilità di rendere Internet commercialmente praticabile. tuttavia, Netscape ha inventato HTTPS – una versione sicura di HTTP che proteggeva la trasmissione. La posizione ideale nello stack TCP / IP per queste procedure di sicurezza era durante i processi di creazione della sessione di TCP. Così, TCP è diventato ancora più essenziale per le operazioni di Internet e sembrava ancora più probabile che UDP non sarebbe mai stato usato.

UDP decolla

Pur esistendo dal 1980, UDP è stato completamente trascurato fino a quando i servizi Internet a banda larga non furono disponibili all’inizio di questo secolo. Il protocollo User Datagram Protocol è stato in gran parte ignorato mentre il web e altre applicazioni Internet hanno ampliato le funzionalità di TCP.

tuttavia, la capacità di avere conversazioni vocali e videoconferenze su Internet ha sempre attratto le aziende. Queste applicazioni esistevano prima della banda larga, ma solo per l’uso su reti private più veloci. Con la tecnologia di passaggio audio e video su reti stabilite, le velocità più elevate della banda larga hanno offerto la possibilità di rendere tali applicazioni disponibili al pubblico divenne un’idea fattibile. Tuttavia, le velocità disponibili su Internet non erano abbastanza buone.

La soluzione immediata per spremere appena la velocità extra da Internet era di abbandonare tutte le procedure amministrative di TCP e passare al quasi dimenticato UDP.

I problemi con TCP

Le applicazioni interattive preferirebbero affrontare alcuni dei problemi riscontrati durante la trasmissione stessa. Una delle caratteristiche principali di TCP che queste applicazioni non vogliono davvero è il buffering.

TCP si assicura che i pacchetti arrivino in sequenza. Se un pacchetto manca dallo stream, l’implementazione TCP ricevente invierà una richiesta al programma TCP mittente per inviare nuovamente quel pacchetto specifico. Nel frattempo, quel pacchetto potrebbe arrivare in ritardo. TCP utilizza un sistema a frame scorrevole per elaborare i pacchetti in arrivo e se un segmento è in ritardo o perso, la diapositiva viene bloccata. La memorizzazione temporanea di un numero di frame in memoria è ciò che è noto come buffering. TCP attende di poter riempire lo slot vuoto con il pacchetto che porta il numero di sequenza mancante. Nel caso della telefonia via Internet, un’azione del genere renderebbe silenziosa la linea. Nello streaming video, l’attesa di un pacchetto mancante bloccherebbe il lettore video.

Le applicazioni interattive non hanno procedure per aggirare il buffering TCP. Il principale dietro i livelli dello stack è che i livelli superiori richiedono un servizio e lo lasciano al livello inferiore per fornirlo. Non vi è alcun segnale di “accettazione” che un’applicazione può inviare al livello di trasporto.

Se un pacchetto viene perso in una conversazione telefonica digitale, i chiamanti avvertiranno un breve silenzio, ma l’applicazione su entrambi i lati andrà avanti e continuerà a inviare e ricevere i seguenti pacchetti. Al momento del recupero di un pacchetto mancante, la conversazione interattiva sarebbe già passata, quindi non ha senso tentare di reinserirlo nel flusso; è solo meglio cancellare la perdita e andare avanti. Allo stesso modo, un pacchetto perso significherebbe solo un breve salto in un flusso video live e gli spettatori preferirebbero piuttosto che il video continuasse ad avanzare piuttosto che sostenere la trama per un millisecondo dei fotogrammi.

Probabilmente hai visto una pausa del lettore video e sovrapporre il messaggio “il buffering“Sopra l’immagine. Di solito c’è anche un contatore che mostra la percentuale di buffering che è stata completata. Questo buffering si verifica se la velocità di trasferimento della connessione è inferiore alla frequenza dei fotogrammi della riproduzione video. Il punto cruciale di quel messaggio, tuttavia, è che mostra che il buffering è gestito dal player e non dal protocollo di trasporto.

Protocolli di partenariato

Sebbene l’applicazione interattiva non volesse i ritardi causati da TCP, volevano alcune delle funzionalità di quel protocollo. Volevano più di quanto UDP potesse fornire. Quindi sono stati inventati altri protocolli per riempire parti delle capacità di TCP.

Il protocollo di avvio della sessione

Il protocollo SIP (Session Initiation Protocol) è stato inventato per le applicazioni Voice over IP (VoIP). La telefonia via Internet non voleva il buffering del TCP, ma doveva emulare le tradizionali procedure di creazione delle chiamate dei telefoni – comporre, squillare, occupato, rispondere e terminare la chiamata. Tuttavia, SIP non gestisce l’intera sessione, si occupa solo della creazione della connessione e delle funzioni di smontaggio di TCP. Ogni chiamata che viene eseguita su Internet utilizza SIP. Tanto che “SIP” è quasi diventato un termine intercambiabile con “VoIP.”

L’esecuzione del traffico vocale su connessioni digitali ad alta velocità in blocco è nota come “Trunking SIP.”Il passaggio di una chiamata da Internet a un normale telefono fisso si chiama”Terminazione SIP.”L’industria della telefonia digitale utilizza SIP per identificare la sua tecnologia, ma il vero fondamento di tutte le loro attività è UDP.

Il protocollo di trasporto in tempo reale

Nonostante la decisione che TCP fosse un sovraccarico per il traffico interattivo e dovrebbe essere abbandonato, gli ingegneri della comunicazione continuavano a tornare alle strutture fornite da TCP e desideravano poterli avere con UDP. Il protocollo Real-Time Transport Protocol (RTP) compensa gran parte della carenza di funzionalità riscontrata durante l’utilizzo di UDP.

Una caratteristica chiave di questi protocolli aggiuntivi che rendono UDP rilevante per lo streaming multimediale è che consentono di trasferire alcuni dei processi tradizionalmente gestiti da TCP all’applicazione. RTP gestisce alcune delle funzioni di gestione del traffico di TCP, ma non tutte.

RTP è in grado di riordinare i pacchetti fuori sequenza e notare i pacchetti persi. Tuttavia, non è necessario implementare la funzione di sequenziamento ed è impossibile implementarla senza buffering a livello di trasporto.

Il protocollo di controllo RTP

RTP collabora sempre con RTCP, che è il protocollo di controllo RTP. RTPC emula alcune delle funzioni di gestione della sessione di TCP, tranne per il principio guida del protocollo che non deve intromettersi nel flusso e non rallentare la trasmissione multimediale; quindi le sue attività sono poco frequenti. Il protocollo raccoglierà i dati sulle prestazioni, inclusa la perdita di pacchetti, e informazioni sulla velocità di trasferimento. Il giocatore ricevente può utilizzare queste informazioni per decidere se passare a una risoluzione video inferiore o a uno standard di codifica video diverso.

Se si utilizza un’applicazione audio e video è quasi certo che siano coinvolti sia RTP che RTCP. C’è un “interleaving“Opzione nella definizione di RTSP (vedi sotto) che sposterebbe le trasmissioni RTP su TCP. Tuttavia, questa è una proposta insolita che non è mai stata implementata oltre il laboratorio. Senza tale specifica, tutte le attività RTP e RTCP sono svolte da UDP.

Il protocollo di streaming in tempo reale

Il Real Time Streaming Protocol (RTSP) è quasi sempre coinvolto nella riproduzione di video e audio o nelle applicazioni di registrazione. Questo protocollo fornisce pulsanti di controllo sul lettore e sul registratore. Questi sono Pausa, Registra / Riproduci, Avanzamento rapido e Riavvolgi. Curiosamente, sebbene RTSP possa funzionare su UDP, di solito viene trasportato su TCP, anche se sta collaborando con un flusso video o audio supportato da UDP.

Applicazioni solo UDP

Numerose applicazioni di supporto di rete leggere utilizzano UDP senza altri protocolli che costituiscono una simulazione delle funzioni TCP. Queste funzioni sono destinate quasi esclusivamente esclusivamente all’uso su reti private perché non includono alcuna procedura di autenticazione o crittografia di trasmissione.

Se gestisci una rete, avrai familiarità con Network Time Protocol (NTP), il Domain Name System (DNS), il DHCP (Dynamic Host Configuration Protocol), e il Trivial File Transfer Protocol (TFTP). Tutti questi servizi di amministrazione funzionano su UDP. Oltre a queste applicazioni di rete private, è molto difficile trovare qualsiasi applicazione che funziona solo su UDP.

UDP vs TCP

Un confronto tra la struttura dell’intestazione UDP e la struttura dell’intestazione TCP mostra i limiti di UDP.

L’intestazione UDP ha solo quattro campi. Di quei quattro, il Porta di origine il campo è facoltativo e può essere lasciato in bianco. In IPv4, il checksum Anche il campo è facoltativo, sebbene sia obbligatorio per le implementazioni IPv6. Ciò significa che nel caso delle trasmissioni IPv4, l’intestazione UDP deve contenere solo due informazioni.

L’intestazione TCP è in grado di trasportare molte più informazioni.

Come puoi vedere dall’illustrazione, l’intestazione del pacchetto TCP ha una serie di nove flag che adattano il significato dell’intestazione. L’evento ha un campo “urgente”. Ciò offre al sistema TCP molta più flessibilità di UDP e mostra che è stato investito molto più tempo nelle procedure per TCP e nella struttura della sua intestazione di pacchetto rispetto a quanto è stato impiegato nello sviluppo di UDP.

Il fatto che l’intestazione TCP debba includere la porta di origine consente di creare un socket più unico, creando un ID di sessione dagli indirizzi IP di origine e di destinazione e dai numeri di porta di origine e di destinazione. Con UDP, in quanto non dispone di procedure per creare una sessione, ogni messaggio viene trattato come un’attività completata, e il protocollo non tenta di mettere insieme i pacchetti. Pertanto, le applicazioni che utilizzano USP devono gestire da sole tale continuità.

Sicurezza per UDP

I metodi TCP orientati alla connessione rendono molto più semplice l’implementazione della sicurezza in quel protocollo in UDP. Tuttavia, ci sono standard di crittografia disponibili per UDP. L’opzione principale che mira direttamente alla sicurezza UDP è il protocollo Datagram Transport Layer Security o DTLS.

per fortuna, DTLS è disponibile in numerose librerie open source gratuite, quindi non è necessario esaminare la definizione del protocollo e scrivere il programma aperto per implementarlo. OpenSSL, che è una libreria di codice open source, è la fonte più comune per un’implementazione di Transport Layer Security, che è il sistema di sicurezza più ampiamente implementato per TCP. Anche questa biblioteca include un’implementazione DTLS, quindi dovresti essere in grado di trovare opzioni UDP sicure nelle stesse applicazioni che offrono connessioni TCP sicure.

Un’altra opzione per gli utenti UDP è quella di fare affidamento su un sistema di sicurezza progettato per funzionare a livello di Internet. Questo è IPSec, o Internet Protocol Security. Poiché IPSec opera al di sotto del livello di trasporto, non è in grado di lavorare con le porte e quindi il fatto che UDP non sia in grado di sostenere una sessione non importa quando IPSec è impegnato – Neanche i protocolli IP Layer possono creare sessioni. Come sistema di livello inferiore, IPSec è in grado di supportare qualsiasi protocollo del livello di trasporto, incluso UDP.

IPSec include metodi di autenticazione e crittografa anche i pacchetti per proteggerli dagli intercettatori telefonici. L’IT offre la stessa sicurezza del popolare TLS, ma è implementato in modo meno diffuso. IPSec utilizza il sistema Internet Key Exchange (IKEv2) per impostare l’autenticazione, quindi abbastanza spesso, IPSec viene fatturato come IKEv2. Utilizza la metodologia IKEv2 Procedure di scambio di chiavi Diffie-Hellman, che è esattamente lo stesso sistema utilizzato da TLS per la metodologia della sessione della pagina Web protetta HTTPS.

Kerberos e Kerberized Internet Negotiation of Keys (KINK) sono due elementi di un sistema di sicurezza che di solito viene chiamato Kerberos. Le procedure di creazione della sessione Kerberos utilizzano un sistema di “ticket” che è simile al metodo TLS di utilizzare “certificati”. Nella parte inferiore dello stack, Kerberos è sostenuto da IPSec. L’omonimo strato Kerberos si trova in cima a UDP e impiega socket UDP per facilitare la comunicazione. Quindi questo è un sistema di sicurezza compatibile con UDP. Una straordinaria funzionalità di Kerberos è che ti consente di utilizzare la crittografia AES per proteggere i tuoi trasferimenti UDP. AES è probabilmente la cifra più sicura di uso comune oggi ed è il metodo di sicurezza consigliato per i migliori sistemi di protezione della privacy VPN al mondo.

Nonostante le apparenti difficoltà di negoziazione delle chiavi di crittografia in un ambiente che non fornisce alcuna gestione della connessione, UDP offre opzioni di sicurezza. Pertanto, quando si implementa un’applicazione basata su UDP, non abbandonare il compito di proteggere le trasmissioni.

Il futuro di UDP

Le applicazioni pure basate su UDP che non prevedono protocolli secondari per imitare il TCP sono rare e probabilmente diventeranno ancora più rare. Le utility di rete leggere che utilizzano UDP prosperano su reti locali sicure. Tuttavia, poiché le minacce alla sicurezza dei nuovi attacchi zero-day aumentano ogni settimana, il concetto di avere protocolli non sicuri che gestiscono i servizi cruciali di gestione e indirizzamento della configurazione sembra follemente compiacente.

Man mano che le reti trasferiscono il loro servizio sul cloud, i servizi di TFTP e DHCP basati su UDP inizieranno a essere sostituiti da alternative più sicure. La semplice soluzione delle applicazioni di navigazione su HTTPS per offrire loro sicurezza senza sforzi di programmazione aggiuntivi inclina il futuro verso TCP, che trasporta HTTPS e allontana le opportunità dall’elenco delle competenze UDP.

È probabile che la nicchia UDP di supportare le trasmissioni mediatiche durerà. Sono già stati proposti molti sistemi di trasporto concorrenti per il supporto di applicazioni interattive, ma nessuno di questi ha eliminato UDP dalla sua posizione di prima scelta per VoIP e streaming video. Questo elenco di rivali include:

RUDP (Reliable User Datagram Protocol), che ha implementazioni Cisco e Microsoft.

Lo Stream Control Transmission Protocol (SCTP), che è stato proposto senza successo in sostituzione della combinazione UDP / RTP / RTCP, ma non è mai del tutto decollato.

Questo brutto anatroccolo chiamato UDP è stato scoperto essere un cigno, grazie ai magici poteri trasformativi della banda larga e delle applicazioni interattive. Questa stella rivitalizzata continuerà a scivolare senza sforzo attraverso le acque di Internet.

Quali metodi di trasmissione usi? Vedi il brutto anatroccolo UDP come un cigno? Scrivi le tue esperienze nella sezione Commenti qui sotto.

Relazionato:
Guida definitiva a TCP / IP
Che cos’è TCPdump?
Revisione del server TFTP di SolarWinds
TFTPD32 Revisione del server TFTP

Immagini:
Header of UDP by Devarshi presso Wikibooks in inglese concesso in licenza in base a CC BY-SA 2.5
Layout del pacchetto TCP con bit scale di Quliyevferman via Wikimedia Commons. Concesso in licenza in base a CC BY-SA 4.0