TCP ou UDP pour un jeu multijoueur?

C'est une question que je vois beaucoup. La plupart des gens disent que UDP est toujours meilleur pour les jeux en temps réel que TCP. Ma compréhension est que TCP essaie de renvoyer des paquets encore et encore jusqu'à ce que l'autre côté les reçoive alors qu'UDP s'en fiche.

La plupart des choses que j'ai lues, c'est que UDP est un must pour tout jeu en temps réel et TCP est terrible. Mais le fait est que la plupart des gens semblent de toute façon implémenter une forme de TCP par-dessus UDP. Et j'ai également entendu que la différence entre les deux est négligeable étant donné que nous ne sommes plus dans les années 80 et que l'Internet est maintenant assez rapide et fiable.

Ma compréhension générale ici est-elle fausse? Quelqu'un peut-il clarifier cela pour moi?

game-development networking tcp

— flooblebit
source

internet is now pretty fast and reliableNon ce n'est pas. La bande passante a considérablement augmenté, oui, mais la latence est encore assez élevée. Avec le TCP pur, le temps de tick du serveur doit être supérieur à la latence maximale abordable, sauf si vous effectuez l'écrêtage des paquets - ce qui est préférable pour le client via UDP. Le problème est que certaines informations dans un jeu doivent être fiables, tandis que d'autres doivent être rapides. Des protocoles personnalisés en plus de UDP permettent cela, ainsi qu'un tas de propriétaires qui vous donnent tout ce dont vous avez besoin dans un joli package.

— Ordous

Ils n'implémentent pas exactement TCP sur UDP. TCP offre certaines fonctionnalités qui sont souhaitables et qui sont implémentées par-dessus UDP. Un point important de l'utilisation d'UDP est que si vous envoyez un paquet contenant l'état mondial à un moment t0qui n'est jamais reçu, alors vous envoyez le nouvel état mondial à un moment donné t1, vous n'avez pas à attendre que le client reçoive réellement le premier paquet, qui est déjà obsolète.

— Vincent Savard

@Ordous Je pense que cela répond à ma question :) Merci

— flooblebit

Sachez également que UDP est sujet à l'usurpation d'adresse IP, ce qui pourrait rendre votre serveur ouvert aux attaques DDoS si cela vous inquiète. Vous pouvez éviter cela en ayant une connexion TCP "de contrôle" qui envoie l'adresse IP des clients et d'autres détails au serveur qui accepte ensuite les paquets UDP de l'adresse "authentifiée". Vous devrez peut-être également implémenter votre propre couche de chiffrement car il n'y a pas de normes ouvertes pour cela sur UDP.

— ARau

@ blownie55 bons points là

— Naresh Kumar

Réponses:

Cela dépend si vous parlez d'égal à égal, client / serveur avec les utilisateurs exécutant le serveur ou client / serveur avec un centre de données exécutant le serveur. Ce n'est que dans ce dernier cas que l'Internet est vraiment rapide et fiable. Les ordinateurs de vos utilisateurs ne sont pas garantis pour être rapides et ne seront certainement pas fiables.

UDP vous permet un meilleur contrôle sur le type d'implémentation de type TCP que vous effectuez. Il vous donne une plus grande flexibilité pour exécuter des paquets dans le désordre, éliminer les paquets que vous considérez inutiles tout en réessayant les paquets que vous jugez importants, ce genre de chose. Mais cela ne devrait être fait qu'en cas de besoin et si vous avez l'expertise nécessaire.

Si vous pouvez vous passer de cette flexibilité, TCP fonctionne assez bien et vous fait gagner beaucoup de temps. Même les studios professionnels (comme celui dans lequel j'ai travaillé) utilisent TCP s'ils n'ont pas absolument besoin d'UDP, et ils ont des gens dédiés à la programmation réseau.

— Kevin Fee
source

Je suggérerais également que «pour quoi» est important - par exemple pour un système de chat en jeu, je ne considérerais même pas UDP. L'autre chose que je considérerais (au moins pour "serveur client") est l'efficacité avec laquelle le serveur peut gérer le trafic - les cartes réseau modernes ont beaucoup de choses de "déchargement" intégrées pour TCP (fractionnement et fusion de paquets, tri des paquets en flux, etc) qui sont conçus pour réduire les frais généraux du processeur, et la plupart de ceux-ci ne peuvent pas fonctionner pour UDP.

— Brendan

Les choses peuvent changer maintenant que QUIC ( en.wikipedia.org/wiki/QUIC ) qui fera partie de HTTP / 3 qui utilise UDP et est crypté en utilisant TLS par défaut. Il faudra un certain temps pour que cela soit largement disponible et c'est quelque chose à espérer. Plus de détails sur certains problèmes qui doivent être traités ici blog.cloudflare.com/the-road-to-quic

— ARau

Ce serait une supposition de dire "Internet est maintenant assez rapide et fiable" comme l'a souligné @Ordous, et dangereux aussi.

La raison pour laquelle le protocole personnalisé UDP + pour les paquets critiques pour la livraison fait de la magie sur la plupart des jeux est que, parfois, cela pourrait être "correct" si vous perdez un paquet (juste pour, par exemple, des événements secondaires non critiques pour terminer le jeu) , il y a aussi des moments où il est "pas du tout correct" de perdre des données pour par exemple le mouvement du curseur, etc. (je ne fais pas de développement de jeux pour gagner ma vie, alors pardonnez mes exemples vagues)

UDP ne perd pas de temps à les pousser encore et encore, par défaut.

Et, de nombreux jeux semblent d'ailleurs avoir les paquets «ok pour perdre parfois» plus que «doivent toujours livrer sans échec». D'où un ajustement naturel pour cette tâche.

Tout ce qui était nécessaire sur UDP était d'utiliser un protocole personnalisé qui aide simplement à fournir correctement les paquets "toujours nécessaires pour livrer sans échec", laissant le reste des données du jeu à la merci de la connexion réseau.

Maintenant, décider du type de trafic qui compose la plupart de VOS données à transmettre vous aidera à mieux décider.

Le point contre TCP serait que le temps passé sur les tentatives pourrait plutôt être consacré à l'envoi de paquets qui comptent MAINTENANT.

Il y a également une chance que s'il y a un problème pendant la transmission, TCP puisse se répercuter sur un scénario de jeu plus dégradé pour l'utilisateur, gâchant ainsi son expérience par rapport à UDP + Custom Stack (cette dernière partie est juste une intuition. Je vais quitter à d'autres experts ici pour commenter cela. J'adorerais en savoir plus sur les possibilités de ce scénario).

— Naresh Kumar
source