TCP o UDP per una partita multiplayer?


18

Questa è una domanda che vedo molto. Molte persone dicono che UDP è sempre meglio per i giochi in tempo reale rispetto a TCP. La mia comprensione è che TCP tenta di rinviare i pacchetti più e più volte fino a quando l'altra parte li ottiene, mentre a UDP non importa.

La maggior parte delle cose che ho letto è che UDP è un must per qualsiasi gioco in tempo reale e TCP è terribile. Ma il fatto è che la maggior parte delle persone sembra implementare comunque una qualche forma di TCP su UDP. E ho anche sentito che la differenza tra i due è trascurabile dato che non siamo più negli anni '80 e che Internet è ora abbastanza veloce e affidabile.

La mia comprensione generale qui è sbagliata? Qualcuno può chiarire questo per me?


7
internet is now pretty fast and reliableNo non lo è. La larghezza di banda è aumentata notevolmente, sì, ma la latenza è ancora piuttosto elevata. Con TCP puro, è necessario che il tempo di tick del server sia superiore alla massima latenza economica, a meno che non si esegua lo compressione dei pacchetti, il che è meglio eseguire sul client tramite UDP. Il problema è che alcune informazioni in un gioco devono essere affidabili, mentre altre devono essere veloci. I protocolli personalizzati su UDP lo consentono, così come un mucchio di quelli proprietari che ti danno tutto ciò di cui hai bisogno in un bel pacchetto.
Ordous,

4
Non implementano esattamente TCP su UDP. Ci sono alcune funzionalità offerte da TCP che sono desiderabili e che sono implementate su UDP. Un punto importante dell'utilizzo di UDP è che se invii un pacchetto contenente lo stato del mondo in un momento t0che non viene mai ricevuto, quindi invii il nuovo stato del mondo in quel momento t1, non devi aspettare che il client riceva effettivamente il primo pacchetto, che è già obsoleto.
Vincent Savard,

@Ordous Penso che questo risponda alla mia domanda :) Grazie
flooblebit

4
Inoltre, tieni presente che UDP è soggetto allo spoofing IP che potrebbe rendere il tuo server aperto agli attacchi DDoS se questo è un problema. È possibile evitarlo disponendo di una connessione TCP "di controllo" che invia l'indirizzo IP dei client e altri dettagli al server che quindi accetta i pacchetti UDP dall'indirizzo "autenticato". Inoltre, potrebbe essere necessario implementare il proprio livello di crittografia in quanto non esistono standard aperti per questo su UDP.
ARau,

@ blownie55 buoni punti lì
Naresh Kumar

Risposte:


12

Dipende se stai parlando di peer-to-peer, client / server con gli utenti che eseguono il server o client / server con un data center che esegue il server. Solo in quest'ultimo caso Internet è davvero veloce e affidabile. I computer dei tuoi utenti non sono garantiti per essere veloci e certamente non saranno affidabili.

UDP ti consente un maggiore controllo sul tipo di implementazione simile a TCP che stai realizzando. Ti dà una maggiore flessibilità per eseguire i pacchetti fuori servizio, scartando i pacchetti che ritieni non necessari mentre riprova i pacchetti che ritieni importanti, quel genere di cose. Ma questo dovrebbe essere fatto solo se necessario e se si dispone delle competenze necessarie.

Se puoi fare a meno di tale flessibilità, TCP funziona abbastanza bene e ti fa risparmiare un sacco di tempo. Perfino gli studi professionali (come quello in cui ho lavorato) usano TCP se non hanno assolutamente bisogno di UDP e hanno persone dedicate alla programmazione di rete.


Suggerirei anche che "per cosa" è importante, ad esempio per un sistema di chat in-game che non prenderei nemmeno in considerazione UDP. L'altra cosa che prenderei in considerazione (almeno per "client server") è quanto il server sia in grado di gestire in modo efficiente il traffico: le moderne schede di rete hanno un sacco di roba "offloading" incorporata per TCP (suddivisione e unione di pacchetti, ordinamento di pacchetti in flussi, ecc.) progettati per ridurre il sovraccarico della CPU e la maggior parte di questi non può funzionare con UDP.
Brendan,

1
Le cose possono cambiare ora che QUIC ( en.wikipedia.org/wiki/QUIC ) che farà parte di HTTP / 3 che utilizza UDP ed è crittografato usando TLS per impostazione predefinita. Ci vorrà del tempo perché questo sia ampiamente disponibile ed è qualcosa da guardare al futuro. Maggiori dettagli su alcuni problemi che devono essere gestiti qui blog.cloudflare.com/the-road-to-quic
ARau

3

Sarebbe un presupposto dire "Internet è ora abbastanza veloce e affidabile" come ha sottolineato @Ordous, e anche pericoloso.

Il motivo per cui il protocollo personalizzato UDP + per i pacchetti critici per la consegna fa magie sulla maggior parte dei giochi è che, ci sono momenti in cui potrebbe essere "ok" se perdi un pacchetto (solo per. Per esempio eventi secondari non critici per completare il gioco) , ci sono anche momenti in cui è "per niente ok" perdere alcuni dati per esempio il movimento del cursore, ecc. (Non faccio sviluppo di giochi per vivere, quindi scusate i miei vaghi esempi)

UDP non perde tempo a spingerli ancora e ancora, per impostazione predefinita.

E, per inciso, molti giochi sembrano avere i pacchetti "okay da perdere a volte" più di quelli che "devono sempre consegnare senza errori". Quindi fare una misura naturale per questo compito.

Tutto ciò che era necessario su UDP era usare un protocollo personalizzato che aiutasse a consegnare correttamente i pacchetti "sempre necessari per consegnare senza errori", lasciando il resto dei dati di gioco in balia della connessione di rete.

Ora decidere su quale tipo di traffico costituisce la maggior parte dei TUOI dati da trasmettere ti aiuterà a decidere meglio.

Il punto contro TCP sarebbe che il tempo speso per i tentativi potrebbe piuttosto essere speso per inviare pacchetti che contano ORA.

C'è anche la possibilità che, in caso di problemi durante la trasmissione, TCP possa passare a uno scenario di gioco più suddiviso per l'utente, rovinando la sua esperienza rispetto a UDP + Custom Stack (Quest'ultima parte è solo un sospetto. questo ad altri esperti qui per commentare questo. Mi piacerebbe conoscere le possibilità di questo scenario).

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.