Quando è appropriato utilizzare UDP anziché TCP? [chiuso]

Poiché TCP garantisce la consegna dei pacchetti e quindi può essere considerato "affidabile", mentre UDP non garantisce nulla e i pacchetti possono andare persi. Quale sarebbe il vantaggio di trasmettere dati usando UDP in un'applicazione piuttosto che su un flusso TCP? In quale tipo di situazioni l'UDP sarebbe la scelta migliore e perché?

Suppongo che UDP sia più veloce poiché non ha il sovraccarico di creare e mantenere un flusso, ma non sarebbe irrilevante se alcuni dati non raggiungessero mai la loro destinazione?

Questa è una delle mie domande preferite. UDP è così frainteso.

In situazioni in cui si desidera ottenere rapidamente una risposta semplice a un altro server, UDP funziona al meglio. In generale, si desidera che la risposta sia contenuta in un pacchetto di risposta e si è pronti a implementare il proprio protocollo per affidabilità o a rinviare. DNS è la descrizione perfetta di questo caso d'uso. I costi delle impostazioni di connessione sono troppo elevati (tuttavia, DNS supporta anche una modalità TCP).

Un altro caso è quando si stanno fornendo dati che possono essere persi perché i nuovi dati in arrivo sostituiranno i dati / lo stato precedenti. Vengono in mente dati meteorologici, streaming video, un servizio di quotazioni di borsa (non utilizzato per il trading reale) o dati di gioco.

Un altro caso è quando si sta gestendo un'enorme quantità di stato e si desidera evitare di utilizzare TCP perché il sistema operativo non è in grado di gestire così tante sessioni. Questo è un caso raro oggi. In effetti, ora ci sono stack TCP land-user che possono essere utilizzati in modo che il writer dell'applicazione possa avere un controllo più fine sulle risorse necessarie per quello stato TCP. Prima del 2003, UDP era davvero l'unico gioco in città.

Un altro caso riguarda il traffico multicast. UDP può essere multicast su più host mentre TCP non può farlo.

Se un pacchetto TCP viene perso, verrà reinviato. Ciò non è utile per le applicazioni che si basano sulla gestione dei dati in un ordine specifico in tempo reale.

Gli esempi includono lo streaming video e in particolare VoIP (ad esempio Skype ). In quei casi, tuttavia, un pacchetto rilasciato non è un grosso problema: i nostri sensi non sono perfetti, quindi potremmo anche non notare. Ecco perché questi tipi di applicazioni utilizzano UDP anziché TCP.

L '"inaffidabilità" di UDP è un formalismo. La trasmissione non è assolutamente garantita. In pratica, quasi sempre riescono. Non vengono riconosciuti e riprovati dopo un timeout.

L'overhead nella negoziazione di un socket TCP e nell'handshaking dei pacchetti TCP è enorme. Davvero enorme. Non vi è alcun apprezzabile sovraccarico UDP.

Ancora più importante, è possibile integrare facilmente UDP con un affidabile scuotimento manuale delle consegne meno costoso del TCP. Leggi questo: http://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol

UDP è utile per la trasmissione di informazioni in un'applicazione di tipo pubblicazione-abbonamento. IIRC, TIBCO fa un uso pesante dell'UDP per la notifica del cambio di stato.

Qualsiasi altro tipo di "evento significativo" o attività di "registrazione" a senso unico può essere gestito in modo ottimale con i pacchetti UDP. Vuoi inviare una notifica senza costruire un intero socket. Non ti aspetti alcuna risposta dai vari ascoltatori.

Anche i messaggi "heartbeat" o "I'm alive" di sistema sono una buona scelta. Manca uno non è una crisi. Ne manca una mezza dozzina (di fila).

Lavoro su un prodotto che supporta sia la comunicazione UDP (IP) che TCP / IP tra client e server. È iniziato con IPX oltre 15 anni fa con il supporto IP aggiunto 13 anni fa. Abbiamo aggiunto il supporto TCP / IP 3 o 4 anni fa. Immaginazione selvaggia in arrivo: il rapporto tra il codice UDP e TCP è probabilmente di circa 80/20. Il prodotto è un server di database, quindi l'affidabilità è fondamentale. Dobbiamo gestire tutti i problemi imposti da UDP (perdita di pacchetti, raddoppio dei pacchetti, ordine dei pacchetti, ecc.) Già menzionati in altre risposte. Raramente ci sono problemi, ma a volte si verificano e quindi devono essere gestiti. Il vantaggio di supportare UDP è che siamo in grado di personalizzarlo un po 'per il nostro uso e ottimizzarne un po' più le prestazioni.

Ogni rete sarà diversa, ma il protocollo di comunicazione UDP è generalmente un po 'più veloce per noi. Il lettore scettico si chiederà giustamente se abbiamo implementato tutto correttamente. Inoltre, cosa puoi aspettarti da un ragazzo con un rappresentante di 2 cifre? Tuttavia, ho appena eseguito un test per curiosità. Il test ha letto 1 milione di record (selezionare * tra quelli possibili). Ho impostato il numero di record da restituire con ogni singola richiesta client su 1, 10 e quindi 100 (tre test eseguiti con ciascun protocollo). Il server era a soli due hop su una LAN da 100 Mbit. I numeri sembravano concordare con ciò che altri hanno trovato in passato (UDP è circa il 5% più veloce nella maggior parte delle situazioni). I tempi totali in millisecondi sono stati i seguenti per questo particolare test:

1. 1 record
   • IP: 390.760 ms
   • TCP: 416.903 ms
2. 10 registrazioni
   • IP: 91.707 ms
   • TCP: 95.662 ms
3. 100 registrazioni
   • IP: 29.664 ms
   • TCP: 30.968 ms

La quantità totale di dati trasmessi è stata pressoché identica sia per IP che per TCP. Abbiamo un sovraccarico extra con le comunicazioni UDP perché abbiamo alcune delle stesse cose che ottieni "gratis" con TCP / IP (checksum, numeri di sequenza, ecc.). Ad esempio, Wireshark ha mostrato che una richiesta per il prossimo set di record era 80 byte con UDP e 84 byte con TCP.

Ci sono già molte buone risposte qui, ma vorrei aggiungere un fattore molto importante oltre a un riepilogo. UDP può raggiungere un throughput molto più elevato con la regolazione corretta perché non utilizza il controllo della congestione . Il controllo della congestione in TCP è molto moltoimportante. Controlla la velocità e la velocità effettiva della connessione al fine di ridurre al minimo la congestione della rete cercando di stimare la capacità corrente della connessione. Anche quando i pacchetti vengono inviati tramite collegamenti molto affidabili, come nella rete principale, i router hanno buffer di dimensioni limitate. Questi buffer si riempiono fino alla loro capacità e quindi i pacchetti vengono eliminati e TCP nota questo calo a causa della mancanza di un riconoscimento ricevuto, limitando così la velocità della connessione alla stima della capacità. TCP impiega anche qualcosa chiamato slow start , ma il throughput (in realtà la finestra di congestione) viene aumentato lentamente fino a quando non vengono rilasciati i pacchetti, quindi viene abbassato e nuovamente aumentato lentamente fino a quando non vengono rilasciati i pacchetti, ecc. Ciò provoca la fluttuazione del throughput TCP. Puoi vederlo chiaramente quando scarichi un file di grandi dimensioni.

Poiché UDP non utilizza il controllo della congestione, può essere sia più rapido che con meno ritardi poiché non cercherà di massimizzare i buffer fino al punto di rilascio, ovvero i pacchetti UDP trascorrono meno tempo nei buffer e ci arrivano più velocemente con meno ritardo. Poiché UDP non utilizza il controllo della congestione, ma TCP lo fa, può togliere la capacità dal TCP che produce flussi UDP.

UDP è comunque vulnerabile alla congestione e alla caduta di pacchetti, quindi l'applicazione deve essere pronta a gestire queste complicazioni in qualche modo, probabilmente utilizzando codici di ritrasmissione o correzione errori.

Il risultato è che UDP può:

• Ottieni una velocità di trasmissione maggiore rispetto a TCP, purché la velocità di caduta della rete rientri nei limiti che l'applicazione è in grado di gestire.
• Consegna pacchetti più velocemente di TCP con meno ritardi.
• Configura le connessioni più velocemente in quanto non vi è alcuna stretta di mano iniziale per impostare la connessione
• Trasmettere pacchetti multicast, mentre TCP deve utilizzare più connessioni.
• Trasmettere pacchetti di dimensioni fisse, mentre TCP trasmette i dati in segmenti. Se trasferisci un pacchetto UDP di 300 byte, riceverai 300 byte all'altra estremità. Con TCP, puoi alimentare il socket di invio a 300 byte, ma il destinatario legge solo 100 byte e devi capire in qualche modo che ci sono altri 200 byte sulla strada. Ciò è importante se l'applicazione trasmette messaggi di dimensioni fisse anziché un flusso di byte.

In sintesi, UDP può essere utilizzato per ogni tipo di applicazione TCP, purché si attui anche un meccanismo di ritrasmissione adeguato. UDP può essere molto veloce, ha meno ritardi, non è influenzato dalla congestione su una base di connessione, trasmette datagrammi di dimensioni fisse e può essere utilizzato per il multicast.

UDP ha un sovraccarico minore ed è buono per fare cose come lo streaming di dati in tempo reale come audio o video, o comunque dove va bene se i dati vengono persi.

UDP è un protocollo senza connessione e viene utilizzato in protocolli come SNMP e DNS in cui i pacchetti di dati fuori servizio sono accettabili e la trasmissione immediata dei pacchetti di dati è importante.

Viene utilizzato in SNMP poiché la gestione della rete deve spesso essere eseguita quando la rete è sotto stress, ovvero quando è difficile ottenere un trasferimento dei dati affidabile e controllato dalla congestione.

Viene utilizzato in DNS poiché non comporta la creazione di connessioni, evitando in tal modo ritardi nella creazione di connessioni.

Saluti

Una delle migliori risposte che conosco per questa domanda proviene dall'utente zAy0LfpBZLC8mAC di Hacker News . Questa risposta è così buona che sto per citarla così com'è.

TCP ha il blocco della coda, in quanto garantisce la consegna completa e in ordine, quindi quando un pacchetto viene perso durante il trasporto, deve attendere una ritrasmissione del pacchetto mancante, mentre UDP consegna i pacchetti all'applicazione appena arrivano , compresi i duplicati e senza alcuna garanzia che arrivi un pacchetto o quale ordine arrivano (in realtà è essenzialmente IP con numeri di porta e un checksum (opzionale) di payload aggiunto), ma va bene per la telefonia, ad esempio, dove di solito semplicemente non importa quando mancano pochi millisecondi di audio, ma il ritardo è molto fastidioso, quindi non ti preoccupi dei ritrasmissioni, lascia semplicemente cadere i duplicati, ordina i pacchetti riordinati nell'ordine giusto per alcune centinaia di millisecondi di buffer di jitter e se i pacchetti non vengono visualizzati in tempo o per niente, vengono semplicemente ignorati,possibile interpolato ove supportato dal codec.

Inoltre, una parte importante di TCP è il controllo del flusso, per essere sicuri di ottenere il massimo flusso di dati possibile, ma senza sovraccaricare la rete (il che è un po 'ridondante, poiché una rete sovraccarica lascerà cadere i pacchetti, il che significa che dovresti fare ritrasmissioni, che danneggiano il throughput), UDP non ha nulla di tutto ciò - il che ha senso per applicazioni come la telefonia, poiché la telefonia con un determinato codec richiede una certa quantità di larghezza di banda, non è possibile "rallentarla" e anche larghezza di banda aggiuntiva non rende la chiamata più veloce.

Oltre alle applicazioni in tempo reale / a bassa latenza, UDP ha senso per transazioni molto piccole, come le ricerche DNS, semplicemente perché non ha l'istituzione della connessione TCP e l'overhead di smontaggio, sia in termini di latenza che in termini di utilizzo della larghezza di banda. Se la tua richiesta è più piccola di una MTU tipica e probabilmente anche la risposta, puoi farlo in un roundtrip, senza la necessità di mantenere uno stato sul server e il controllo del flusso come ordini e tutto ciò che probabilmente non è particolarmente utile anche per tali usi.

E poi, puoi usare UDP per costruire i tuoi sostituti TCP, ovviamente, ma probabilmente non è una buona idea senza una profonda comprensione delle dinamiche di rete, i moderni algoritmi TCP sono piuttosto sofisticati.

Inoltre, suppongo che dovrebbe essere menzionato che esiste più di UDP e TCP, come SCTP e DCCP. L'unico problema attualmente è che Internet (IPv4) è piena di gateway NAT che rendono impossibile l'uso di protocolli diversi da UDP e TCP nelle applicazioni per l'utente finale.

Lo streaming video è un perfetto esempio di utilizzo di UDP.

UDP ha un sovraccarico inferiore, come già indicato è buono per lo streaming di cose come video e audio in cui è meglio perdere solo un pacchetto quindi provare a rinviare e recuperare.

Non ci sono garanzie sulla consegna TCP, si deve semplicemente dire se il socket è disconnesso o sostanzialmente se i dati non arrivano. Altrimenti ci arriva quando ci arriva.

Una cosa importante che la gente dimentica è che udp è basato su pacchetti e tcp è basato su test secondari, non vi è alcuna garanzia che il "pacchetto tcp" che hai inviato sia il pacchetto che si presenta all'altra estremità, può essere sezionato in altrettanti pacchetti come desiderano i router e le pile. Quindi il tuo software ha l'overhead aggiuntivo di analizzare nuovamente i byte in blocchi di dati utilizzabili, che possono richiedere una buona quantità di overhead. UDP può essere fuori servizio, quindi è necessario numerare i pacchetti o utilizzare qualche altro meccanismo per riordinarli se si desidera farlo. Ma se ottieni quel pacchetto udp arriva con tutti gli stessi byte nello stesso ordine in cui è rimasto, nessuna modifica. Quindi il termine pacchetto udp ha senso, ma il pacchetto tcp non lo è necessariamente. TCP ha il proprio meccanismo di riprova e di ordinamento nascosto alla tua applicazione,

UDP è molto più facile scrivere codice per entrambe le estremità, fondamentalmente perché non è necessario creare e mantenere connessioni punto a punto. La mia domanda è in genere dove sono le situazioni in cui si desidera l'overhead TCP? E se prendi scorciatoie come supporre che un "pacchetto" tcp ricevuto sia il pacchetto completo che è stato inviato, stai meglio? (è probabile che tu butti via due pacchetti se ti preoccupi di controllare lunghezza / contenuto)

La comunicazione di rete per i videogiochi avviene quasi sempre su UDP.

La velocità è della massima importanza e non importa se mancano gli aggiornamenti poiché ogni aggiornamento contiene lo stato corrente completo di ciò che il giocatore può vedere.

La domanda chiave era collegata a "che tipo di situazioni UDP sarebbe la scelta migliore [oltre tcp]"

Ci sono molte grandi risposte sopra, ma ciò che manca è una valutazione formale e obiettiva dell'impatto dell'incertezza del trasporto sulle prestazioni TCP.

Con la massiccia crescita delle applicazioni mobili e i paradigmi "occasionalmente connessi" o "occasionalmente disconnessi" che ne derivano, ci sono certamente situazioni in cui il sovraccarico dei tentativi di TCP di mantenere una connessione quando le connessioni sono difficili da trovare porta a un forte caso per UDP e la sua natura "orientata ai messaggi".

Ora non ho la matematica / la ricerca / i numeri su questo, ma ho prodotto app che hanno funzionato in modo più affidabile usando e ACK / NAK e numerazione dei messaggi su UDP di quanto si potesse ottenere con TCP quando la connettività era generalmente scarsa e scarso vecchio TCP ho appena trascorso il tempo e il denaro del mio cliente solo cercando di connettersi. Ottieni questo nelle aree regionali e rurali di molti paesi occidentali ....

In alcuni casi, che altri hanno sottolineato, l'arrivo garantito dei pacchetti non è importante, e quindi l'uso di UDP va bene. Ci sono altri casi in cui UDP è preferibile a TCP.

Un caso unico in cui si desidera utilizzare UDP anziché TCP è il tunneling di TCP su un altro protocollo (ad esempio tunnel, reti virtuali, ecc.). Se si esegue il tunneling di TCP su TCP, i controlli di congestione di ciascuno interferiranno l'uno con l'altro. Quindi si preferisce generalmente eseguire il tunneling del TCP su UDP (o di qualche altro protocollo senza stato). Vedi l'articolo di TechRepublic: Comprensione di TCP su TCP: effetti del tunneling TCP su throughput e latenza end-to-end .

UDP può essere utilizzato quando un'app si preoccupa di più dei dati "in tempo reale" anziché dell'esatta replica dei dati. Ad esempio, VOIP può usare UDP e l'app si preoccuperà di riordinare i pacchetti, ma alla fine VOIP non ha bisogno di ogni singolo pacchetto, ma soprattutto ha bisogno di un flusso continuo di molti di essi. Forse qui un "glitch" nella qualità della voce, ma lo scopo principale è quello di ricevere il messaggio e non che venga ricreato perfettamente dall'altra parte. UDP viene utilizzato anche in situazioni in cui le spese per la creazione di una connessione e la sincronizzazione con TCP superano il payload. Le query DNS sono un esempio perfetto. Un pacchetto in uscita, un pacchetto indietro, per query. Se si utilizza TCP questo sarebbe molto più intenso. Se non ricevi la risposta DNS, riprova.

UDP quando la velocità è necessaria e l'accuratezza se i pacchetti non lo sono e TCP quando è necessaria l'accuratezza.

UDP è spesso più difficile in quanto è necessario scrivere il programma in modo tale da non dipendere dall'accuratezza dei pacchetti.

Non è sempre chiaro. Tuttavia, se hai bisogno della consegna garantita di pacchetti senza perdita e nella giusta sequenza, probabilmente TCP è quello che desideri.

D'altro canto, UDP è appropriato per la trasmissione di brevi pacchetti di informazioni in cui la sequenza delle informazioni è meno importante o in cui i dati possono rientrare in un singolo pacchetto.

È inoltre appropriato quando si desidera trasmettere le stesse informazioni a molti utenti.

Altre volte, è appropriato quando si inviano dati sequenziali, ma se alcuni di questi scompaiono non si è troppo preoccupati (ad esempio un'applicazione VOIP).

Alcuni protocolli sono più complessi perché sono necessarie alcune (ma non tutte) le funzionalità di TCP, ma più di quelle fornite da UDP. È qui che il livello dell'applicazione deve implementare la funzionalità aggiuntiva. In questi casi, UDP è anche appropriato (ad es. Radio su Internet, l'ordine è importante ma non tutti i pacchetti devono passare).

Esempi di dove è / potrebbe essere utilizzato 1) Un server orario che trasmette l'ora corretta a un gruppo di macchine su una LAN. 2) Protocolli VOIP 3) Ricerche DNS 4) Richiesta di servizi LAN ad es. Dove sei? 5) Internet radio 6) e molti altri ...

Su unix puoi digitare grep udp / etc / services per ottenere un elenco di protocolli UDP implementati oggi ... ce ne sono centinaia.

Guarda la sezione 22.4 della Programmazione di rete Unix di Steven , "Quando usare UDP invece di TCP".

Inoltre, vedi questa altra risposta SO circa l'idea sbagliata che UDP sia sempre più veloce di TCP .

Ciò che Steven dice può essere riassunto come segue:

• Usa UDP per broadcast e multicast poiché questa è la tua unica opzione (usa multicast per qualsiasi nuova app)
• Puoi utilizzare UDP per semplici app di richiesta / risposta, ma dovrai creare le tue funzioni, timeout e ritrasmissioni
• Non utilizzare UDP per il trasferimento di dati in blocco.

Sappiamo che l'UDP è un protocollo senza connessione, quindi lo è

1. adatto a processi che richiedono una semplice comunicazione richiesta-risposta.
2. adatto per processi con flusso interno, controllo degli errori
3. adatto per casting ampi e multicasting

Esempi specifici:

• utilizzato in SNMP
• utilizzato per alcuni protocolli di aggiornamento del percorso come RIP

Confrontando TCP con UDP, protocolli senza connessione come UDP assicurano la velocità, ma non l'affidabilità della trasmissione dei pacchetti. Ad esempio, nei videogiochi in genere non è necessaria una rete affidabile, ma la velocità è la più importante e l'utilizzo di UDP per i giochi ha il vantaggio di ridurre il ritardo della rete.

Si desidera utilizzare UDP su TCP nei casi in cui la perdita di alcuni dati lungo il percorso non rovinerà completamente i dati trasmessi. Molti dei suoi usi sono in applicazioni in tempo reale, come i giochi (ad esempio FPS, in cui non è sempre necessario sapere dove si trova ogni giocatore in un determinato momento e se si perdono alcuni pacchetti lungo il percorso, nuovi i dati ti diranno correttamente dove si trovano i giocatori) e lo streaming video in tempo reale (un frame corrotto non rovinerà l'esperienza di visualizzazione).

Abbiamo un servizio web che ha migliaia di client winforms in altrettanti PC. I PC non hanno alcuna connessione con il back-end DB, tutti gli accessi sono tramite il servizio web. Quindi abbiamo deciso di sviluppare un server di registrazione centrale in ascolto su una porta UDP e tutti i client inviano un pacchetto di log degli errori xml (usando l'appender UDP log4net) che viene scaricato su una tabella DB al momento della ricezione. Dal momento che non ci interessa davvero se mancano alcuni log degli errori e con migliaia di client è veloce con un servizio di registrazione dedicato che non carica il servizio web principale.

Sono un po 'riluttante a suggerire UDP quando TCP potrebbe funzionare. Il problema è che se TCP non funziona per qualche motivo, perché la connessione è troppo lenta o congestionata, è improbabile che cambiare l'applicazione per usare UDP. Una cattiva connessione è negativa anche per UDP. TCP fa già un ottimo lavoro nel minimizzare la congestione.

L'unico caso che mi viene in mente dove è richiesto UDP è per i protocolli di trasmissione. Nei casi in cui un'applicazione coinvolge due host noti, UDP offrirà probabilmente vantaggi di prestazioni marginali solo per costi sostanzialmente aumentati della complessità del codice.

Usa UDP solo se sai davvero cosa stai facendo. L'UDP è oggi in casi estremamente rari, ma il numero di esperti (anche molto esperti) che tenterebbero di attaccarlo ovunque sembra sproporzionato. Forse si divertono a implementare da soli il codice di gestione degli errori e di manutenzione della connessione.

TCP dovrebbe essere molto più veloce con le moderne schede di interfaccia di rete a causa della cosiddetta impronta del checksum . Sorprendentemente, a velocità di connessione elevate (come 1 Gbps) il calcolo di un checksum sarebbe un grosso carico per una CPU, quindi viene scaricato su hardware NIC che riconosce i pacchetti TCP per l'impronta e non offre lo stesso servizio.

UDP è perfetto per il VoIP indirizzato in cui il pacchetto di dati deve essere inviato per quanto riguarda la sua affidabilità ... La chat video è un esempio di UDP (è possibile verificarlo tramite l'acquisizione di rete di WireShark durante qualsiasi chat video) .. Inoltre TCP non funziona con Protocolli DNS e SNMP. UDP non ha alcun sovraccarico mentre TCP ha un sacco di sovraccarico