UDP fa qualcosa?
Mi risulta che TCP abbia una logica per garantire una comunicazione affidabile, ma UDP invia semplicemente le informazioni lungo il canale impostato per esso utilizzando IP e cose a livelli inferiori.
UDP fa davvero qualcosa? Sono un po 'confuso dal motivo per cui ha anche un nome.
Risposte
Prospettiva e domanda interessanti!
Sì, la maggior parte di ciò che fa UDP è fornire un mezzo standard per la coesistenza di più applicazioni utilizzando lo stesso indirizzo IP, definendo il concetto di porte UDP .
La parte interessante di UDP non è tanto il protocollo di rete, ma l'API implementata dai sistemi operativi e dalle librerie di socket. Sebbene non faccia parte delle specifiche UDP stesse, la capacità di utilizzare astrazioni come l'API socket POSIX per sviluppare facilmente software su protocolli come UDP è la chiave del successo dello stack del protocollo Internet.
UDP è un protocollo di trasporto, come TCP. Ciò significa che fornisce un protocollo per un'applicazione per utilizzare l'IP. Come il TCP, UDP ha indirizzi (porte) a cui si collegano le applicazioni in modo che i datagrammi destinati alle applicazioni associate vengano inviati da UDP alle applicazioni corrette. UDP per IPv4 fornisce anche un checksum opzionale, ma il checksum è richiesto per IPv6.
UDP è un protocollo basato su messaggi, dove TCP è un protocollo basato su flussi. UDP può essere utile affinché i protocolli a livello di applicazione forniscano alcune, ma non tutte, le funzionalità di TCP, e molte applicazioni o protocolli a livello di applicazione non possono utilizzare, o sono addirittura danneggiate, dall'affidabilità del TCP. Ad esempio, i protocolli in tempo reale, come VoIP, video o persino giochi, non possono utilizzare i datagrammi persi dopo che non sono più utili, quindi se il TCP reinvia i dati avrebbe un risultato negativo. Quando usi il VoIP e l'altra persona risponde, vuoi sentire "Ciao", non "Oh, diavolo".
Altre cose, come il multicast, sono unidirezionali, ma TCP richiede l'impostazione di una connessione bidirezionale tra due applicazioni, mentre un'applicazione multicast invia i dati a molti ricevitori. TCP non può davvero farlo, ma è facile usare UDP con multicast.
Vorrei incoraggiarti a vedere come i protocolli di livello superiore che utilizzano UDP lo utilizzano effettivamente. Esempi classici e ben documentati sono DNS (nella maggior parte dei casi, almeno, è possibile eseguire DNS su TCP ma è davvero raro), DHCP, NTP e PTP.
Tutti questi protocolli hanno alcune cose specifiche in comune:
- A loro interessa poter coesistere con altri servizi sullo stesso sistema.
- Si preoccupano di un certo grado di integrità dei dati dei loro messaggi.
- Sono orientati al messaggio , non al flusso .
- Si tratta principalmente di scambi di dati molto brevi e spesso poco frequenti.
I primi due punti sono banalmente coperti da qualsiasi protocollo di livello di trasporto ragionevole (anche cose esotiche come TIPC), incluso TCP. Tuttavia, TCP è orribile per gli altri due punti, perché richiede di eseguire il roll del proprio protocollo di framing dei messaggi in cima ai suoi flussi per i protocolli orientati ai messaggi e il significativo avvio della connessione e il sovraccarico di manutenzione significa che è molto inefficiente per scambi di dati brevi e poco frequenti .
In altre parole, la "caratteristica" di UDP per cui vale la pena preoccuparsi è che fornisce il minimo indispensabile per quei primi due punti senza intralciarti come fa il TCP per questi tipi di applicazioni. Ha anche un piccolo vantaggio su TCP in quanto è banaleda implementare puramente in hardware o su un sistema minuscolo con meno di 1Kb di RAM e una quantità minuscola di spazio di archiviazione per il codice (questo fa parte del motivo per cui BOOTP, RARP, TFTP e altri protocolli di bootstrap lo utilizzavano originariamente). Lo svantaggio è l'affidabilità e la suscettibilità a determinati tipi di attacchi se si utilizzano `` connessioni '' stateful di lunga durata senza una gestione molto attenta, ma i protocolli che lo usano e si preoccupano di gestirlo da soli (vedere TFTP per un esempio di come trattare il problema di affidabilità, anche se a scapito della velocità).
Ora, ci sono opzioni che possono ottenere set di funzionalità simili (o anche set di funzionalità più completi) a TCP con un sovraccarico molto inferiore e consentendo comunque la comunicazione orientata ai messaggi (gli esempi principali includono RUDP, DCCP e SCTP), ma non hanno davvero ha preso piede per una combinazione di ragioni, quindi UDP rimane in giro.
C'è un punto importante che UDP non richiede la creazione di una "connessione" .
Ad esempio, sarebbe difficile e complesso, se non impossibile, implementare DHCP su TCP, dove un client non ha indirizzo IP e non conosce l'ambiente di rete esistente. Non ha quindi senso "impostare una connessione", poiché il client non conosce l'indirizzo di destinazione e non ha un indirizzo di origine. UDP lo rende facile consentendo una trasmissione di una richiesta DHCP alla rete esistente e un server DHCP (e si spera solo uno) risponderà con un'offerta.
Allo stesso modo, la maggior parte delle azioni di trasmissione di rete ha poco senso con TCP *, perché non è possibile avere una "connessione" con una "destinazione di trasmissione" in cui ogni singolo host accetta e risponde. Cose come numeri di sequenza e checksum non si sommano.
* Non stiamo parlando di cose come MPI_Bcast(). Sono davvero fuori portata per questa domanda.
Per me la cosa fondamentale che fa UDP è fornire sia i numeri di porta di origine che di destinazione e quindi consentire non solo più protocolli di applicazione diversi, ma anche più istanze dello stesso protocollo di applicazione.
In linea di principio è possibile creare il protocollo dell'applicazione direttamente su IP e ottenere un numero di protocollo per esso. Funziona bene se si dispone di una sola istanza del protocollo dell'applicazione su ciascun host, tuttavia non funziona così bene se si desidera avere più istanze dello stesso protocollo dell'applicazione su ciascun host.
Avendo numeri di porta di origine e di destinazione separati e stabilendo le convenzioni secondo cui i client utilizzano porte temporanee mentre i server utilizzano porte note e che le risposte scambiano i numeri di porta, UDP supporta più istanze dello stesso protocollo applicativo sullo stesso host.
Offre servizi di multiplexing / demultiplexing ai livelli superiori (App) in modo da poter gestire i dati da processi diversi. Con il checksum, ti porterà anche il rilevamento degli errori.
UDP, essendo un protocollo così semplice, è utile per i protocolli di livello superiore che preferiscono una comunicazione veloce, senza la necessità di stabilire una connessione o un trasferimento dati affidabile.
Inoltre, alcuni protocolli come il DNS utilizzano UDP per i loro scopi ...
Penso che sia importante notare che DHCP si basa su UDP al 100% ed è estremamente ampiamente utilizzato.
Anche DNS storicamente utilizzava UDP e utilizza TCP solo quando la risposta è troppo grande per un pacchetto UDP.