Perché UDP + è un sistema di ordinazione affidabile per software più veloce di TCP?

Question

Alcuni giochi oggi utilizzano un sistema di rete che trasmette messaggi su UDP e garantisce che i messaggi siano affidabili e ordinati.

Ad esempio, RakNet è un motore di rete di giochi popolare. Utilizza solo UDP per le sue connessioni e ha un intero sistema per garantire che i pacchetti possano essere affidabili e ordinati se lo desideri.

La mia domanda di base è: che succede? TCP non è la stessa cosa di UDP ordinato e affidabile? Cosa rende così più lento il fatto che le persone debbano sostanzialmente reinventare la ruota?

Answer 1

Generali / Specializzazione

1. TCP è un sistema affidabile per scopi generici
2. UDP + qualunque sia un sistema affidabile per scopi speciali.

Le cose specializzate sono generalmente migliori delle cose per scopi generici per ciò che sono specializzate.

Stream / Messaggio

1. TCP è basato su stream
2. UDP è basato su messaggi

L'invio di mappe di informazioni di gioco discrete di solito è migliore per un paradigma basato su messaggi. Inviarlo attraverso un flusso è possibile ma orribilmente inefficace. Se si desidera inviare in modo affidabile un'enorme quantità di dati (trasferimento file), TCP è abbastanza efficace. Ecco perché Bit-torrent usa UDP per controllare i messaggi e TCP per l'invio di dati.

Answer 2

Siamo passati da affidabile a inaffidabile in "league of legends" circa un anno fa a causa di numerosi vantaggi che si sono rivelati veri:

1) Le vecchie informazioni diventano irrilevanti. Se invio un pacchetto sanitario e non arriva ... Non voglio aspettare che lo stesso pacchetto sanitario venga reinviato quando so che è cambiato.

2) A volte l'ordine non è necessario. Se invio messaggi diversi a sistemi diversi, potrebbe non essere necessario riportarli in ordine. Non costringo il client ad attendere messaggi in ordine.

3) Inaffidabile non viene eseguito il backup dei messaggi ... vale a dire in attesa di riconoscimenti, il che significa che è possibile risolvere i picchi di perdita molto più rapidamente.

4) Puoi controllare i rinvii quando sono necessariamente più efficienti. Come riconfezionare qualcosa che non è stato inviato in un altro pacchetto. (TCP reimballa ma puoi farlo in modo più efficiente con la conoscenza di come funziona il tuo programma.)

5) Controllo del flusso di messaggi come eliminare i messaggi che sono meno rilevanti quando la rete si innalza improvvisamente. Il sistema di rete può scegliere di non inviare nuovamente messaggi meno rilevanti in caso di picco di perdita. Con TCP avresti ancora una coda di messaggi che stanno tentando di inviare di nuovo, che potrebbe avere una priorità inferiore.

6) Pacchetto intestazione più piccolo ... non c'è bisogno di dire molto al riguardo.

Answer 3

C'è molta più differenza tra UDP e TCP che solo affidabilità e sequenziamento:

Al centro della questione c'è il fatto che UDP è senza connessione mentre TCP è connesso . Questa semplice differenza porta a una serie di altre differenze che non sarò in grado di riassumere ragionevolmente qui. Puoi leggere l'analisi di seguito per ulteriori dettagli.

TCP - Analisi comparativa UDP

Answer 4

La risposta a mio avviso in due parole: " Congestion control " ;.

TCP fa di tutto per gestire la larghezza di banda del percorso, per utilizzarne la maggior parte, ma per garantire che ci sia spazio per altre applicazioni. Questo è un compito molto difficile e intrinsecamente non è possibile utilizzare il 100% della larghezza di banda il 100% delle volte.

Con UDP, d'altra parte, si può creare il proprio protocollo per inviare i pacchetti sul filo più velocemente che vogliono - questo rende il protocollo molto ostile ad altre applicazioni, ma può ottenere più "prestazioni". breve termine. D'altra parte, è molto probabile che se le condizioni sono appropriate, questo tipo di protocolli potrebbe contribuire a crollo della congestione .

Answer 5

TCP è un protocollo orientato al flusso, mentre UDP è un protocollo orientato ai messaggi. Quindi TCP fa molto più che affidabilità e ordinazione. Vedi questo post per maggiori dettagli. Fondamentalmente, gli sviluppatori di RakNet hanno aggiunto l'affidabilità e l'ordinamento mantenendo comunque un protocollo orientato ai messaggi, e quindi il risultato è stato più leggero del TCP (che deve fare di più).

Answer 6

Questo piccolo articolo è vecchio, ma è ancora abbastanza vero quando si tratta di giochi. Spiega i due protocolli e il caos che queste persone hanno cercato di sviluppare un gioco Internet multiplayer. " X-Wing vs Tie Fighter "

Insegnamenti tratti (Internet fa schifo)

Tuttavia, c'è un avvertimento: corro / sviluppo un gioco multiplayer e ho usato entrambi. UDP era molto meglio per la mia app, ma molte persone non potevano giocare con UDP. I router e simili hanno bloccato le connessioni. Quindi sono passato al "affidabile" TCP. Bene ... affidabile? Io non la penso così. Si invia un pacchetto, nessun errore, ne si invia un altro e si arresta in modo anomalo (eccezione) nel mezzo del pacchetto. Ora quali pacchetti lo hanno creato? Quindi finisci per scrivere un protocollo affidabile ON TOP OF tcp, per simulare UDP - ma stabilire continuamente una nuova connessione quando si blocca. Prendi inefficiente.

UDP + Stop and wait ARW = buono

UDP + Sliding Window Protocol = migliore

TCP + Protocollo a finestra scorrevole con riconnessione? = Bulkware senza valore. (IMHO)

L'altro effetto collaterale sono le applicazioni multi-thread. TCP funziona bene per una cosa tipo chat room, dal momento che ogni room può essere il proprio thread. Una sala può contenere 60-100 persone e funziona bene, poiché il thread della sala contiene i socket per ciascun partecipante.

UDP è invece meglio servito (IMO) da un thread, ma quando ottieni il pacchetto, devi analizzarlo per capire da chi proviene (tramite informazioni inviate o RemoteEndPoint), quindi passare quei dati a il thread della chatroom in modo sicuro.

In realtà, devi fare lo stesso con TCP, ma solo su connessione.

Ultimo punto. Ricorda che TCP si interromperà e ucciderà la connessione in qualsiasi momento, ma puoi riconnetterti in circa 0,5 secondi e inviare le stesse informazioni. La cosa più bizzarra con cui abbia mai lavorato.