TCP ou UDP para um jogo multiplayer?

Esta é uma pergunta que vejo muito. A maioria das pessoas diz que o UDP é sempre melhor para jogos em tempo real do que o TCP. Meu entendimento é que o TCP tenta reenviar pacotes repetidamente até que o outro lado os obtenha, enquanto o UDP não se importa.

A maioria das coisas que li é que o UDP é obrigatório para qualquer jogo em tempo real e o TCP é terrível. Mas o problema é que a maioria das pessoas parece implementar alguma forma de TCP sobre o UDP de qualquer maneira. E também ouvi dizer que a diferença entre os dois é insignificante, já que não estamos mais nos anos 80 e a internet agora é bem rápida e confiável.

O meu entendimento geral aqui está errado? Alguém pode esclarecer isso para mim?

game-development networking tcp

— flooblebit
fonte

internet is now pretty fast and reliableNão, não é. A largura de banda aumentou dramaticamente, sim, mas a latência ainda é bastante alta. Com o TCP puro, você precisa que o tempo de verificação do servidor seja superior à latência máxima acessível, a menos que você faça squishing de pacotes - o que é melhor feito no cliente via UDP. O problema é que algumas informações em um jogo precisam ser confiáveis, enquanto outras precisam ser rápidas. Os protocolos personalizados sobre o UDP permitem isso, assim como vários proprietários, que oferecem tudo o que você precisa em um bom pacote.

— Ordous

Eles não implementam exatamente o TCP sobre o UDP. Existem alguns recursos que o TCP oferece que são desejáveis e que são implementados sobre o UDP. Um ponto importante do uso do UDP é que, se você envia um pacote contendo o estado mundial em um momento t0que nunca é recebido, envia o novo estado mundial em um momento t1, não precisa esperar até que o cliente realmente receba o primeiro pacote, que já está obsoleto.

— Vincent Savard

@Ordous Eu acho que isso responde a minha pergunta :) Thanks

— flooblebit

Lembre-se também de que o UDP é propenso a falsificação de IP, o que poderia tornar seu servidor aberto a ataques DDoS, se isso for um problema. Você pode evitar isso tendo uma conexão TCP de "controle" que envia o endereço IP dos clientes e outros detalhes para o servidor, que aceita pacotes UDP a partir do endereço "autenticado". Além disso, talvez você precise implementar sua própria camada de criptografia, pois não há padrões abertos para isso no UDP.

— arau

@ blownie55 bons pontos lá

— Naresh Kumar

Respostas:

Depende se você está falando de ponto a ponto, cliente / servidor com os usuários executando o servidor ou cliente / servidor com um data center executando o servidor. Somente neste último caso, a Internet é realmente rápida e confiável. Não é garantido que os computadores de seus usuários sejam rápidos e certamente não serão confiáveis.

O UDP permite maior controle sobre o tipo de implementação semelhante ao TCP que você está fazendo. Dá a você maior flexibilidade para executar pacotes fora de ordem, descartar pacotes que você considera desnecessários ao tentar novamente os pacotes que considera importantes, esse tipo de coisa. Mas isso só deve ser feito se necessário e se você tiver o conhecimento necessário.

Se você pode ficar sem essa flexibilidade, o TCP funciona bem o suficiente e economiza muito tempo. Até estúdios profissionais (como o que eu trabalhei) usam o TCP se não precisam absolutamente de UDP e têm pessoas dedicadas à programação em rede.

— Kevin Fee
fonte

Eu também sugeriria que "para o que" importa - por exemplo, para um sistema de bate-papo no jogo, eu nem consideraria o UDP. A outra coisa que eu consideraria (pelo menos para "servidor cliente") é a eficiência com que o servidor pode lidar com o tráfego - as NICs modernas possuem muitas coisas de "descarregamento" internas para TCP (divisão e mesclagem de pacotes, classificação de pacotes em fluxos, etc) projetados para reduzir a sobrecarga da CPU, e a maioria deles não funciona para o UDP.

— Brendan

As coisas podem mudar agora que o QUIC ( en.wikipedia.org/wiki/QUIC ), que fará parte do HTTP / 3 que usa UDP e é criptografado usando TLS por padrão. Levará algum tempo para que isso esteja amplamente disponível e é algo para se esperar. Mais detalhes sobre algumas questões que precisam ser tratadas aqui blog.cloudflare.com/the-road-to-quic #

— ARau

Seria uma suposição dizer "A Internet agora é bem rápida e confiável", como o @Ordous apontou, e uma perigosa também.

A razão pela qual o protocolo personalizado UDP + para pacotes críticos para a entrega faz a mágica na maioria dos jogos é que, há momentos em que pode ser "bom" se você perder algum pacote (apenas para, por exemplo, eventos secundários não críticos para concluir o jogo) , há também momentos em que "não está tudo bem" perder alguns dados, por exemplo, movimento do cursor etc. (eu não desenvolvo jogos para ganhar a vida, então perdoe meus exemplos vagos)

O UDP não perde tempo pressionando-os repetidamente, por padrão.

Aliás, muitos jogos parecem ter os pacotes "aceitável perder às vezes" mais do que "sempre precisam entregar sem falhas". Portanto, fazer um ajuste natural para esta tarefa.

Tudo o que era necessário no UDP era usar um protocolo personalizado que apenas ajudasse a fornecer os pacotes "sempre precisamos entregar sem falhas" corretamente, deixando o restante dos dados do jogo à mercê da conexão de rede.

Agora, decidir sobre que tipo de tráfego compõe a maioria dos SEUS dados a serem transmitidos ajudará você a decidir melhor.

O argumento contra o TCP seria que o tempo gasto em novas tentativas poderia ser gasto no envio de pacotes importantes agora.

Também há uma chance de que, se houver algum problema durante a transmissão, o TCP possa entrar em cascata para um cenário de jogo mais detalhado para o usuário, estragando sua experiência em comparação com a Pilha Personalizada UDP + (Esta última parte é apenas um palpite. Vou deixar faça isso com outros especialistas aqui para comentar sobre isso. Gostaria de aprender sobre as possibilidades desse cenário).

— Naresh Kumar
fonte