UDP vs TCP, quanto più veloce è?[chiuso]

Question

Per il protocollo generale di scambio di messaggi, che possono tollerare alcuni di perdita di pacchetti.Quanto più efficiente è UDP TCP?

Answer 1

UDP è più veloce di TCP, e il motivo è semplice, perché la sua inesistente pacchetto di acknowledge (ACK) che permette un continuo flusso di pacchetti, invece di TCP che riconosce una serie di pacchetti, calcolato utilizzando la dimensione della finestra TCP e il round-trip time (RTT).

Per ulteriori informazioni vi consiglio il semplice, ma molto comprensibile Skullbox spiegazione (TCP vsUDP)

Answer 2

La gente dice che la cosa più importante TCP fornisce l'affidabilità.Ma non è vero.La cosa più importante TCP ti dà è di controllo della congestione:è possibile eseguire 100 connessioni TCP attraverso un collegamento DSL tutti di andare alla massima velocità, e tutte e 100 le connessioni produttive, perché tutti "senso" la larghezza di banda disponibile.Provate con più di 100 diverse applicazioni UDP, spingendo tutti i pacchetti come veloce come si può andare, e vedere come le cose funzionano per voi.

Su una scala più grande, questo TCP comportamento è ciò che tiene in Internet dalla chiusura, in "la congestione del collasso".

Cose che tendono a spingere le applicazioni verso UDP:

• Gruppo semantica di consegna:e ' possibile effettuare la consegna affidabile di un gruppo di persone in modo molto più efficiente rispetto a TCP point-to-point di riconoscimento.

• Out-of-order di consegna:in molte applicazioni, come lungo come è possibile ottenere tutti i dati, non si cura di ciò che ordine non arriva;è possibile ridurre app a livello di latenza accettando un ordine di blocco.

• Inimicizia:su un LAN party, potrebbe non importa se il vostro browser web funzioni bene finchè sei in blitting aggiornamenti alla rete veloce come è possibile.

Ma anche se non ti interessano le prestazioni, probabilmente non si vuole andare con UDP:

• Sei sul gancio per affidabilità, ora, e un sacco di cose che potete fare per implementare l'affidabilità può essere più lento di quello che TCP fa già.

• Ora sei in rete ostile, che può causare problemi in ambienti condivisi.

• Ancora più importante, firewall ti blocca.

È potenzialmente in grado di superare alcune prestazioni TCP e problemi di latenza da "trunking" più connessioni TCP insieme;iSCSI viene per aggirare controllo di congestione sulle reti di area locale, ma si può anche fare per creare una bassa latenza "urgente" message channel (TCP è "URGENTE" il comportamento è totalmente rotto).

Answer 3

In alcune applicazioni TCP è più veloce (migliore capacità di trasmissione) rispetto a UDP.

Questo è il caso quando si fa un sacco di piccole scrive relativa alla dimensione MTU.Per esempio, ho letto di un esperimento in cui un flusso di 300 byte pacchetti è stata inviata over Ethernet (MTU 1500 byte) e TCP è stato più veloce del 50% rispetto a UDP.

Il motivo è perché il TCP proverà e buffer di dati e di riempire un intero segmento di rete, quindi, di rendere più efficiente l'uso della larghezza di banda disponibile.

UDP invece mette il pacchetto sul filo immediatamente così che congestiona la rete con un sacco di pacchetti di piccole dimensioni.

Probabilmente non dovrebbe usare UDP a meno che non hai un motivo specifico per farlo.Soprattutto perché si può dare TCP lo stesso tipo di latenza come UDP, disattivando l' Algoritmo Nagle (per esempio se si trasmettono in tempo reale i dati del sensore e non siete preoccupati per congestiona la rete con un sacco di pacchetti di piccole dimensioni).

Answer 4

con la perdita tollerante

Vuoi dire "con la perdita di tolleranza" ?

Fondamentalmente, UDP non è "la perdita di tolleranza".È possibile inviare 100 pacchetti a qualcuno, e si potrebbe ottenere solo 95 di quei pacchetti, e alcuni potrebbero essere nell'ordine sbagliato.

Per cose come lo streaming video, e giochi multiplayer, dove è meglio perdere un pacchetto di ritardare tutti gli altri pacchetti dietro di esso, questa è la scelta evidente

Per la maggior parte delle altre cose anche se, mancante o decomposti pacchetto è fondamentale.Dovresti scrivere qualche codice aggiuntivo per esecuzione su UDP a riprova, se le cose si sono perse, e di imporre l'ordine corretto.Questo sarebbe aggiungere un po ' di overhead in certi luoghi.

Fortunatamente, alcune persone molto intelligenti hanno fatto questo, e l'hanno chiamato TCP.

Penso in questo modo:Se un pacchetto viene smarrito, sarebbe invece di ottenere solo il pacchetto successivo il più rapidamente possibile e continuare (UDP), o avete bisogno, che i dati mancanti (utilizzare il protocollo TCP).L'overhead non importa, a meno che non sei davvero bordo-case scenario.

Answer 5

Il protocollo che funziona meglio (in termini di throughput) - UDP o TCP - realtà dipende dalle caratteristiche della rete e del traffico di rete.Robert S.Barnes, per esempio, indica uno scenario in cui il protocollo TCP esegue meglio (di piccole dimensioni scrive).Ora, si consideri uno scenario in cui la rete è congestionata e ha sia il traffico TCP e UDP.Mittenti in rete che utilizza il protocollo TCP, avrà senso il 'congestione' e ridotto le loro di inviare i tassi.Tuttavia, UDP non ha per evitare la congestione congestione e / o meccanismi di controllo, e mittenti utilizzando UDP continuerà a pompa di dati allo stesso tasso.Gradualmente, TCP mittenti a ridurre le loro invio i tassi al minimo e se UDP mittenti sono abbastanza dati per essere inviati attraverso la rete, avrebbero hog la maggior parte della larghezza di banda disponibile.Così, in tal caso, UDP mittenti di avere una maggiore velocità di trasferimento, come ottenere una torta più grande della larghezza di banda della rete.In realtà, questo è un attivo tema di ricerca - Come migliorare la velocità di trasmissione TCP in presenza di traffico UDP.Un modo, che io sappia, utilizzando TCP che le applicazioni possono migliorare la velocità di trasmissione è con l'apertura di più connessioni TCP.In questo modo, anche se, ogni connessione TCP, la produttività può essere limitato, la somma totale di il rendimento di tutte le connessioni TCP può essere maggiore della velocità di trasmissione per un applicazione che utilizza UDP.

Answer 6

Ogni connessione TCP richiede una prima stretta di mano prima della trasmissione dei dati.Inoltre, il protocollo TCP header contiene un sacco di overhead destinati a diversi segnali di consegna dei messaggi e di rilevamento.Per un scambio di messaggi, UDP sarà probabilmente sufficiente, se una piccola probabilità di fallimento è accettabile.Se la ricevuta deve essere verificata, TCP è la vostra migliore opzione.

Answer 7

@Andrea, Mi permetto di dissentire.UDP è la scelta in alcuni tipi di applicazione, a causa di requisiti di prestazioni.Un esempio classico è la videoconferenza.Questo tipo di applicazione non risponde bene a TCP di controllo.

Altro aspetto da prendere in considerazione è se si sta andando a bisogno di multicast.Se è così, utilizzare il protocollo UDP.

Answer 8

Quando si parla di "ciò che è più veloce" - ci sono almeno due aspetti molto diversi:throughput e latenza.

Se parlando il throughput - Il protocollo TCP controllo di flusso (come già detto in altre risposte), è estremamente importante e si fa niente di paragonabile su UDP, mentre è certamente possibile, sarebbe un gran mal di testa(tm).Come risultato, l'utilizzo di UDP quando è necessario il throughput, raramente si qualifica come una buona idea (a meno che non si desidera ottenere un ingiusto vantaggio su TCP).

Tuttavia, se parlando latenze - il tutto è completamente diverso.Mentre in assenza di perdita di pacchetti TCP e UDP si comportano molto simile (eventuali differenze, se del caso, essere marginale) - dopo che il pacchetto è perso, tutto il disegno cambia drasticamente.

Dopo l'eventuale perdita di pacchetti TCP di attesa per ritrasmettere per almeno 200ms (1sec al paragrafo 2.4 del RFC6298, ma pratico moderne implementazioni tendono a ridurla a 200ms).Inoltre, con il protocollo TCP, anche i pacchetti che ha fatto raggiungere l'host di destinazione non sarà consegnato alla vostra applicazione fino a quando l'mancanti pacchetto viene ricevuto (cioè, tutta la comunicazione è in ritardo di circa 200ms) - BTW, questo effetto, noto come Head-of-Line di Blocco, è inerente a tutti affidabili ordine flussi, se TCP o affidabile+ordinato UDP.Per rendere le cose ancora peggio - se il pacchetto ritrasmesso è perso, allora saremo a parlare di ritardo di ~600ms (a causa del cosiddetto backoff esponenziale, 1 ° ritrasmettere è 200ms, il secondo è 200*2=400ms).Se il nostro canale ha 1% di perdita di pacchetti (che non è male per gli standard di oggi), e abbiamo un gioco con 20 aggiornamenti al secondo, ad 600ms ritardi si verificano in media ogni 8 minuti.E come 600ms è più che sufficiente per ottenere hai ucciso in un gioco veloce - beh, è piuttosto male per il gioco.Questi effetti sono esattamente il motivo per cui gamedevs spesso preferiscono UDP TCP.

Tuttavia, quando si utilizza il protocollo UDP per ridurre le latenze, è importante rendersi conto che solo "l'utilizzo di UDP" non è sufficiente per ottenere sostanziale latenza di miglioramento, è tutto su COME si utilizza UDP.In particolare, mentre RUDP librerie di solito evitare che "exponential backoff" e utilizzare più breve di ritrasmissione a volte - se utilizzato come "affidabili ordine" stream, hanno ancora soffrono di Head-of-Line di Blocco (quindi in caso di una doppia perdita di pacchetti, invece che 600ms arriveremo a circa 1,5*2*RTT - o per un buon 80 ms RTT, è un ~250 ms di ritardo, che è un miglioramento, ma è ancora possibile fare di meglio).D'altra parte, se l'utilizzo di tecniche discusse in http://gafferongames.com/networked-physics/snapshot-compression/ e/o http://ithare.com/udp-from-mog-perspective/#low-latency-compression È possibile eliminare Head-of-Line di blocco interamente (quindi per una doppia perdita di pacchetti per un gioco con 20 aggiornamenti al secondo, il ritardo di 100ms a prescindere dal RTT).

E come nota a margine - se vi capita di avere accesso solo a TCP, ma non UDP (come nel browser, o se il client è dietro uno di 6-9% di brutto firewall che bloccano UDP) - c' sembra per essere un modo per implementare UDP su TCP senza incorrere in troppo latenze, vedi qui: http://ithare.com/almost-zero-additional-latency-udp-over-tcp/ (assicurarsi di leggere i commenti troppo(!)).

Answer 9

Se avete bisogno di rapidamente esplosione di un messaggio attraverso la rete tra i due IP che non hanno ancora parlato di sicurezza, quindi un UDP sta per arrivare almeno a 3 volte più veloce, di solito 5 volte più veloce.

Answer 10

UDP è leggermente più veloce nella mia esperienza, ma non di molto.La scelta non dovrebbe essere fatto su le prestazioni, ma il contenuto del messaggio e le tecniche di compressione.

Se si tratta di un protocollo con il messaggio scambio, Io proporrei che il lieve calo di prestazioni con il protocollo TCP è più che la pena.Ti sei dato una connessione tra due punti che vi darà tutto ciò di cui hai bisogno.Non provare a realizzare le proprie affidabile a due vie protocollo UDP a meno che non siete veramente sicuri in quello che stai intraprendendo.

Answer 11

Tenete a mente che il protocollo TCP di solito mantiene più messaggi sul filo.Se si desidera implementare questo in UDP avrai un bel po ' di lavoro se si vuole fare in modo affidabile.La soluzione è destinata a essere meno affidabile, meno veloce o una quantità incredibile di lavoro.Ci sono valide applicazioni UDP, ma se stai chiedendo a questa domanda, vostra, probabilmente non lo è.

Answer 12

Mi limito a fare chiarezza. TCP/UDP sono due auto che essere guidato su strada.supponiamo che il traffico di segni e gli ostacoli sono Errori TCP si preoccupa per i segnali stradali, rispetti tutto intorno.Lento guida, perché potrebbe succedere qualcosa alla macchina.Mentre UDP solo le unità fuori, al massimo della velocità non ha rispetto per la segnaletica stradale.Niente, un mad driver. UDP non dispone di recupero di errore, Se c'è un ostacolo, sarà solo collidere con esso per poi continuare.Mentre TCP fa in modo che tutti i pacchetti sono inviati e ricevuto perfettamente, Senza errori , così , l'auto passa gli ostacoli senza entrare in collisione.Spero che questo sia un buon esempio per farvi capire, Perché UDP è preferito nel gioco.Esigenze di gioco, velocità. TCP è preferito per il download, o scaricato il file può essere danneggiato.

Answer 13

C'è stato un lavoro fatto per consentire al programmatore di avere i vantaggi di entrambi i mondi.

SCTP

Si tratta di un indipendente di strato di trasporto protolol, ma può essere utilizzato come una libreria che fornisce ulteriore strato su UDP.L'unità di base della comunicazione è un messaggio (mappata a uno o più pacchetti UDP).C'è congestione di controllo integrato.Il protocollo ha le manopole e giocherella per accendere

• in ordine di consegna dei messaggi
• ritrasmissione automatica di messaggi persi, con parametri definiti dall'utente

se ciò è necessario per la vostra applicazione particolare.

Unico problema con questo è che la connessione di struttura complessa (e quindi lento processo)

Altre cose simili

• https://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol

Uno più simili di proprietà sperimentali cosa

• https://en.wikipedia.org/wiki/QUIC

Questo cerca anche di migliorare la tripla way handshake TCP e modificare il controllo di congestione per affrontare meglio le linee veloci.

Answer 14

Non ha senso parlare di TCP o UDP, senza prendere la condizione di rete in considerazione.Se la rete tra i due punti hanno una qualità molto alta, UDP è assolutamente più veloce di TCP, ma in qualche altro caso come la rete GPRS, TCP può stato più veloce e più affidabilità di UDP.

Answer 15

La configurazione di rete è fondamentale per qualsiasi tipo di misura.Si fa una differenza enorme, se si è in comunicazione via socket sulla macchina locale o con l'altra estremità del mondo.

Tre cose che vorrei aggiungere alla discussione:

1. Si possono trovare qui un ottimo articolo su TCP vsUDP in contesto di sviluppo del gioco.
2. Inoltre, iperf (jperf migliorare iperf con una GUI) è un molto bello strumento per rispondere alla tua domanda te, con la misurazione.
3. Ho implementato un punto di riferimento in Python (vedi questa domanda COSÌ).In media di 10^6 iterazioni la differenza per l'invio di 8 byte è di circa 1-2 microsecondi per UDP.