Pourquoi UDP + est-il un système de commande logiciel fiable plus rapide que TCP?

Question

Certains jeux utilisent aujourd'hui un système réseau qui transmet les messages via UDP et garantit leur fiabilité et leur ordre.

Par exemple, RakNet est un moteur de réseau de jeu populaire. Il utilise uniquement le protocole UDP pour ses connexions et dispose d’un système complet pour garantir la fiabilité et la commande des paquets si vous le souhaitez.

Ma question fondamentale est la suivante: qu'est-ce qui se passe avec ça? TCP n’est-il pas la même chose qu’UDP ordonné et fiable? Qu'est-ce qui le ralentit tellement que les gens doivent réinventer la roue?

Answer 1

Général / Spécialisation

1. TCP est un système fiable polyvalent
2. UDP + tout ce qui constitue un système fiable à usage spécifique.

Les choses spécialisées sont généralement meilleures que les choses d'usage général pour ce qu'elles sont spécialisées.

Flux / Message

1. TCP est basé sur le flux
2. UDP est basé sur un message

L'envoi de cartes d'informations de jeu discrètes est généralement préférable à un paradigme basé sur un message. L'envoyer à travers un flux est possible mais horriblement inefficace. Si vous souhaitez envoyer de manière fiable une grande quantité de données (transfert de fichier), le protocole TCP est très efficace. C'est pourquoi Bit-torrent utilise UDP pour les messages de contrôle et TCP pour l'envoi de données.

Answer 2

Nous sommes passés de fiables à non fiables dans la "Ligue des légendes". il y a environ un an en raison de plusieurs avantages qui se sont avérés depuis:

1) Les anciennes informations deviennent inutiles. Si j’envoie un paquet de santé et qu’il n’arrive pas ... je ne veux pas attendre que ce même paquet de santé soit renvoyé quand je sais que cela a changé.

2) L'ordre n'est parfois pas nécessaire. Si j'envoie des messages différents à différents systèmes, il ne sera peut-être pas nécessaire de les mettre en ordre. Je ne force pas le client à attendre les messages en ordre.

3) Unreliable n’est pas sauvegardé avec des messages ... c’est-à-dire qu’il attend des accusés de réception, ce qui signifie que vous pouvez résoudre les pics de perte beaucoup plus rapidement.

4) Vous pouvez contrôler les renvois lorsque cela est nécessairement plus efficace. Par exemple, remballer quelque chose qui n'a pas été envoyé dans un autre paquet. (TCP remballe mais vous pouvez le faire plus efficacement avec des informations sur le fonctionnement de votre programme.)

5) Contrôle du flux des messages, par exemple en jetant des messages moins pertinents en cas de pics soudains du réseau. Le système de réseau peut choisir de ne pas renvoyer de messages moins pertinents en cas de pointe de perte. Avec TCP, vous avez toujours une file de messages que vous essayez de renvoyer, dont la priorité est peut-être inférieure.

6) Le paquet d'en-tête plus petit ... n'a pas vraiment besoin d'en dire beaucoup à ce sujet.

Answer 3

Il y a beaucoup plus de différence entre UDP et TCP que juste la fiabilité et le séquencement:

Le fait que UDP est sans connexion alors que TCP est connecté est au cœur du problème. Cette simple différence mène à une foule d'autres différences que je ne vais pas pouvoir résumer raisonnablement ici. Vous pouvez lire l'analyse ci-dessous pour plus de détails.

Analyse comparative TCP - UDP

Answer 4

La réponse à mon avis aux deux mots: "Contrôle de la congestion".

TCP déploie beaucoup d'efforts pour gérer la bande passante du chemin d'accès - pour en tirer le meilleur parti, tout en garantissant qu'il y a de la place pour d'autres applications. C’est une tâche très difficile et, par nature, il n’est pas possible d’utiliser 100% de la bande passante 100% du temps.

En revanche, avec UDP, il est possible de créer son propre protocole pour envoyer les paquets sur le réseau aussi rapidement qu’ils le souhaitent - le protocole devient donc très hostile à d’autres applications, mais il peut gagner davantage en "performances". court terme. D’autre part, il est fort probable que, si les conditions sont réunies, ce type de protocoles puisse contribuer à réduction de la congestion .

Answer 5

TCP est un protocole orienté flux, alors que UDP est un protocole orienté message. Par conséquent, TCP ne se limite pas à la fiabilité et à la commande. Voir cet article pour plus de détails. Fondamentalement, les développeurs RakNet ont ajouté la fiabilité et la commande tout en conservant le même protocole que les messages. Ainsi, le résultat était plus léger que TCP (il faut en faire plus).

Answer 6

Ce petit article est ancien, mais il reste assez vrai en ce qui concerne les jeux. Il explique les deux protocoles et les dégâts causés par ces personnes qui ont essayé de développer un jeu Internet multijoueur. "X-Wing vs Tie Fighter"

Leçons apprises (L'internet est nul)

Il y a cependant un inconvénient: je lance / développe un jeu multijoueur et j'ai utilisé les deux. UDP était bien meilleur pour mon application, mais beaucoup de gens ne pouvaient pas jouer avec UDP. Les routeurs et autres ont bloqué les connexions. J'ai donc changé pour le "fiable" TCP. Eh bien ... fiable? Je ne pense pas. Vous envoyez un paquet, pas d'erreurs, vous en envoyez un autre et il se bloque (exception) au milieu du paquet. Maintenant, quels paquets l'ont fait? Vous finissez donc par écrire un protocole fiable SUR TOP OF tcp, pour simuler UDP - mais établissez en permanence une nouvelle connexion en cas de panne. Prenez à peu près inefficace

UDP + Arrêtez et attendez ARW = bon

UDP + protocole de fenêtre glissante = meilleur

Protocole TCP + fenêtre glissante avec reconnexion? = Bulkware sans valeur. (IMHO)

L’autre effet secondaire concerne les applications multithreads. TCP fonctionne bien pour un type de salle de discussion, car chaque salle peut être son propre fil. Une salle peut accueillir de 60 à 100 personnes et fonctionne correctement, le fil de discussion contenant les sockets pour chaque participant.

UDP est par contre mieux servi (IMO) par un thread, mais lorsque vous recevez le paquet, vous devez l’analyser pour déterminer de qui il provient (via info envoyé ou RemoteEndPoint), puis transmettez ces données à le fil de discussion d'une manière threadsafe.

En fait, vous devez faire la même chose avec TCP, mais uniquement lors de la connexion.

Dernier point. N'oubliez pas que TCP générera simplement une erreur et interrompra la connexion à tout moment, mais vous pourrez vous reconnecter en environ 0,5 seconde et envoyer les mêmes informations. La plupart des bizzare avec lesquels j'ai travaillé.