2010-03-01 2 views
8

La vitesse, l'optimisation et l'évolutivité sont les comparaisons typiques entre les protocoles Udp et Tcp. Tcp revendique la fiabilité avec l'inconvénient d'un peu de frais supplémentaires, mais la vitesse est bonne à excellente. Une fois qu'une socket Tcp est instanciée, garder le socket ouvert nécessite une surcharge de. Mais comparé aux charges souvent décrites de Udp, quel protocole a réellement plus de frais généraux ?. J'ai aussi entendu dire qu'il y avait des problèmes d'évolutivité avec Tcp ... pourtant Internet (pages/serveurs Web) fonctionne sur Tcp - alors qu'est-ce qui empêche Tcp d'être évolutif? Ok, ... donc Udp ne nécessite pas cette surcharge de maintenir une connexion ouverte. Mais, il faut que vous écriviez des méthodes supplémentaires pour vous assurer que tout le paquet arrive là, dans l'ordre où vous voulez le recevoir. Si un paquet n'est pas reçu en entier, vous devez dire au client ou au serveur de le renvoyer. Et vous devez également garder une sorte de collection de messages pour les paquets partiels, reconstruire les messages partiels, et vérifier un message complet avant que le message puisse finalement être traité. Sans compter que si la deuxième partie d'un message ne le fait jamais, vous devez soit dire renvoyer le tout, ou renvoyer la partie qui nous manque, ou peu importe.Fiabilité Tcp par rapport à Udp Burdens pour serveur sérieux et hautes performances

Au fond, mes questions sont les suivantes:

  1. Pourquoi choisir Udp sur Tcp pour un sérieux, un serveur haute performance avec l'ajout « frais généraux » de vérification un message et manuel ACK par rapport au « frais généraux » de un flux continu?
  2. Si Tcp est assez bon pour les goûts de World of Warcraft, pourquoi Tcp n'est-il pas plus largement accepté comme le protocole à utiliser pour un serveur de jeu?

Remarque: Je ne suis pas opposé à l'implémentation d'options UDP pour un serveur. Nous utilisons C# sur le framework .Net 3.5. Donc, je serais également intéressé par les meilleures pratiques pour traiter UDP fardeaux. J'utilise également les méthodes asynchrones au niveau socket au lieu d'utiliser TcpListener, TcpClient, etc.

Répondre

11

Eh bien, je recommanderais d'en lire plus. Il y a des endroits beaucoup à voir les avantages et les inconvénients de TCP vs UDP et vice versa, voici quelques-uns:

Cependant, ce lien peut vous intéresser le plus, car il concerne directement la programmation de jeux en réseau:

Si je devais citer un petit quelque chose:

La décision semble assez clair alors, TCP ne tout ce que nous voulons et son super facile à utiliser, alors que UDP est énorme douleur dans le cul et nous devons coder tout nous-mêmes à partir de zéro.Donc, évidemment, nous utilisons TCP juste?

Incorrect.

L'utilisation de TCP est la pire erreur que vous pouvez faire en développant un jeu en réseau ! Pour comprendre pourquoi, vous avez besoin de voir ce que TCP fait ci-dessus IP pour tout faire si simple!

Je recommande toujours faire vos propres recherches sur la question si, et assurez-vous que des protocoles convient vos besoins à la fin de la journée. Cela dit, il semble que la majorité des jeux utilisent UDP pour leurs données. Tout ce qui met continuellement à jour l'intégralité de l'état n'a pas besoin de la surcharge garantie.

+0

Ouais ... c'est la partie "douleur dans le cul" qui me pousse à me demander. Mais je vais continuer à faire des recherches ... – IAbstract

+1

Eh bien, c'est un des sacrifices que je suppose. Si vous utilisez ceci pour le jeu cependant, la meilleure pratique semble être UDP cependant. –

+0

Je voudrais juste noter que l'utilisation de TCP est une idée horrible pour les jeux que si votre jeu fonctionne bien avec la "meilleure distribution de l'effort". Si votre jeu repose sur l'ordre des messages, et ne permet pas de laisser tomber les paquets, TCP finira généralement par être beaucoup plus rapide (les datagrammes UDP sont déposés * tout le temps * sur Internet). Des jeux comme Quake utilisaient UDP (et IPX) dès le début, car un paquet en retard est inutile de toute façon. Des jeux comme Age of Empires ou Civilization utilisaient TCP, car c'est tout le contraire: les messages individuels sont souvent inutiles jusqu'à ce que tous les messages précédents arrivent et soient traités. – Luaan

1

Je pense que la plus grande partie de TCP/IP qui empêche l'évolutivité est qu'il maintient un tampon sur toutes les connexions entrantes/sortantes jusqu'à la taille de la fenêtre. Donc, si j'ai un temps de latence élevé mais que je parle à un débit élevé, je dois garder tous les paquets envoyés dans le tampon jusqu'à ce que je reçoive un accusé de réception. Donc, pour quelques connexions, c'est bien, mais pour gérer les connexions 100K, cela peut commencer à être problématique. Du côté de la réception, si un paquet est abandonné, il tamponnera à nouveau tous les nouveaux paquets reçus jusqu'à ce que celui requis soit retransmis.

Si vous souhaitez implémenter la retransmission, vous devez faire la même chose et donc avoir la même surcharge. Cependant, UDP vous donne un avantage, si vous connaissez les vitesses de liaison de bout en bout, ou si certains messages peuvent être livrés dans le désordre ou si certains messages n'ont pas besoin d'être retransmis. Garder le scénario de jeu:

paquet 1 = passage à 1,1 paquet 2 = tournage paquet 3 = se déplacer à 2,2

La plupart des concepteurs de jeu, si le paquet 1 est perdu, mais paquet 3 est reçu , le paquet 1 n'est plus important car il contient de toute façon des informations périmées. Cependant, vous pourriez choisir de dire que le paquet 2 est important, donc s'il n'est pas accusé, envoyez une retransmission. Si vous avez besoin d'un haut débit et que vous connectez deux serveurs directement avec 1000Mbps ethernet, TCP/IP prendra un certain temps à l'échelle et aura un surcoût supplémentaire, et n'atteindra probablement jamais une véritable connexion Gigabit grâce aux mécanismes d'évitement de congestion. Cependant, vous savez que c'est 1 Gbps, donc vous pouvez configurer UDP pour transmettre jusqu'à 1 Gbps (moins frais généraux) vous-même. Pour répondre à vos questions plus directement: Si vous voulez tout acquitter, il n'y a pas grand avantage à avoir UDP, sauf que vous pouvez traiter certains messages en attendant la retransmission (sauf si vous voulez livraison en ordre aussi bien). Udp n'est pas autant considéré pour les serveurs de jeu, principalement en dehors du scénario ci-dessus, et les systèmes de combat en temps réel tels que les FPS, où un message peut être abandonné, et le nouveau message à venir invalidera la chute message de toute façon. World of Warcraft peut se permettre d'utiliser TCP, car ils n'ont pas besoin d'être aussi précis avec le timing, et ont probablement une bonne logique qui fait qu'il est plus difficile pour vous de faire la différence de toute façon. Le système de combat ne nécessite tout simplement pas la vitesse.

Je dirais aussi qu'une partie de la justification est la survivance d'il y a des années, quand tout le monde avait des connexions Internet moins fiables et plus lentes. TCP est également plus indulgent pour le partage du réseau, donc s'il se passe beaucoup de choses, il ralentira pour que tout le monde ait une part de la connexion (évitement de congestion).TCP/IP est un protocole conçu par des personnes bien plus intelligentes que moi pendant des années de recherche. Le réglage au cours des dernières années lui a permis de mieux fonctionner avec les vitesses réseau moyennes plus rapides et plus rapides que nous voyons, et ne nécessite pas une grande compréhension à utiliser. Cependant, remplacer ceci par UDP nécessite une compréhension significative de la mise en réseau. J'ai vu des programmes UDP mal écrits saturer des liens 1Gbps et tuer tout le trafic sur le lien, car ils ont implémenté un algorithme de retransmission plutôt naïf.

Voici une liste des choses que TCP/IP peut faire maintenant que vous perdriez en allant UDP: - Dans l'arrivée de la commande vous êtes programme - retransmission (maintenant avec réémission rapide, la reconnaissance sélective, et d'autres caractéristiques) - taille maximale du segment - Path MTU Discovery - Détection trou noir (extension de Path MTU) - congestion Avoidance

à cause de cela, je recommande fortement coller avec TCP/IP si cela vous convient êtes besoins .

Egalement à ne pas choisir nit, mais vous commentez sur l'Internet fonctionnant sur TCP/IP est faux, il y a en fait des douzaines de protocoles routables d'Internet check them out here. Je pense que vous avez fait référence à des pages Web et les serveurs Web sont tous en cours d'exécution sur TCP/IP. Ce qui encore une fois pour le web est super où les humains ne remarqueront pas un retard tant que la page s'affiche correctement. Même pour TCP/IP, leur défi est que TCP/IP n'est pas assez agressif pour le web: Google thinks tcp/ip should be more aggressive by default

+0

Fondamentalement, oui, je parlais de plus de matériaux liés au Web. – IAbstract

4

Définir "sérieuse haute performance" - de combien de connexions simultanées parlez-vous et combien de données circulent? Jetez un oeil aux réponses à cette question What do you use when you need reliable UDP? qui liste certains des protocoles fiables qui ont déjà été construits sur UDP. Vous pourriez en trouver un qui fonctionne pour votre situation, ou vous pouvez au moins trouver quelques idées utiles. La clé pour utiliser efficacement UDP ici est d'avoir un certain niveau de fiabilité et un certain niveau de manque de fiabilité et vous obtenez plus d'un avantage plus chaque datagramme peut être manipulé indépendamment des autres. L'avantage par rapport à TCP est que vous pouvez agir sur chaque datagramme et décider si vous pouvez l'utiliser quand il arrive. C'est pourquoi cela fonctionne pour les jeux d'action. Donc, à mon humble avis, si vous avez besoin de 100% de fiabilité et de la livraison de la commande, optez pour le protocole TCP; N'essayez pas de réimplémenter TCP dans UDP.

7

D'abord, je vais paraphraser Stevens de Unix Network Programming Section 22.4 "Quand utiliser UDP au lieu de TCP":

Il dit essentiellement les suivantes:

  1. UDP est la seule option pour la diffusion/Multicast - donc vous devez l'utiliser là-bas.
  2. UDP peut être être utilisé pour de simples applications de demande/réponse. Mais vous devez ajouter votre propre détection d'erreur au moins acks, timesouts et retransmission.
  3. UDP ne devrait pas être utilisé pour le transfert de données en vrac (transferts de fichiers), car vous devez intégrer toutes les fonctionnalités déjà présentes dans TCP pour le faire fonctionner correctement.
  4. UDP doit être utilisé pour les données en temps réel où la rapidité de livraison est la plus importante et une perte de données ne sont pas un problème comme les données de capteurs en temps réel, des flux multimédias en direct, des cotations boursières en temps réel, etc.

La réponse à votre première question dépend beaucoup de votre définition de «haute performance». Si vous êtes préoccupé par la faible latence, c'est-à-dire que les paquets/demandes de données individuels arrivant le plus rapidement possible par rapport au protocole UDP seront la solution. Il ya deux raisons principales pour cela. En supposant que les paquets/demandes sont assez indépendants les uns des autres que l'utilisation de TCP introduirait un problème connu sous le nom head-of-line blocking.

Disons que vous envoyez deux paquets/demandes indépendantes. D'abord A puis B. Puisque TCP est basé sur un flux, si A est perdu dans le réseau et doit être retransmis, même si B est déjà arrivé, il ne peut être livré à l'application par la pile jusqu'à ce que A arrive. . Non seulement cela, mais jusqu'à ce que A arrive, B ne peut pas être reconnu par la pile, ce qui pourrait provoquer la retransmission de B, provoquant une congestion inutile du réseau. Un moyen de contourner ce problème consiste à utiliser des connexions séparées pour chaque requête, mais cela introduit également des ressources système de temps de latence et. UDP contourne tous ces problèmes.

Un autre problème dans les serveurs haute performance (faible latence) est le Nagle Algorithm qui peut ajouter une latence importante dans les communications TCP.

La réponse à votre deuxième question est que WoW envoie probablement des flux de données, et non la demande indépendante/réponse paires. En outre, une partie de la latence de TCP peut être supprimée en désactivant le Nagle algorithm. S'ils utilisent certaines communications de demande/réponse, ils peuvent avoir simplement pris une décision de conception selon laquelle la fiabilité est plus importante pour eux que la latence.

1

Il est Fiabilité vs performance.

jeux FPS ne nécessitent pas -tous- les paquets pour atteindre la destination, pour l'atteindre afin, d'être exceptionnellement grand, ou pour assurer un débit grand. Ils ont seulement besoin que les paquets atteignent le serveur le plus tôt possible. C'est la priorité ultime et les frais généraux de TCP sont simplement un fardeau inutile. WoW, dans sa communication "pas tout à fait en temps réel" et souvent des tonnes de données à transmettre (dans les zones encombrées), peut avoir à traiter des paquets dépassant MTU (nécessitant une fragmentation) et nécessitant de la fiabilité. plus). Donc, son choix de TCP est logique. Il en irait de même pour la plupart des jeux de stratégie au tour par tour et autres. Dans les jeux où le joueur avec ping de 30ms bat le joueur avec ping 50ms UDP est le roi.

Questions connexes