Le protocole UDP est-il toujours meilleur que le protocole TCP pour les jeux en temps réel avec beaucoup de données?


71

Je sais que le protocole UDP est généralement recommandé pour les jeux multijoueurs en temps réel avec une utilisation élevée des données.

La plupart des articles ont quelques années d'expérience et, comme environ 80% de toutes les données transmises sur Internet sont en TCP, une optimisation importante a dû être effectuée pour TCP.

Cela me fait penser: UDP est-il toujours supérieur en termes de vitesse et de latence? Les récentes optimisations TCP pourraient-elles avoir rendu TCP plus performant qu’UDP?


25
Avec UDP, rien ne garantit que vos paquets seront reçus ou même commandés, cela seul rend UDP plus rapide que TCP.
Nathan

4
@ KaareZ que voulez-vous dire plus rapidement à mettre en œuvre?
Nathan

2
@nathan Il est plus facile de développer votre application avec TCP qu'avec UDP. Je veux savoir si toutes les optimisations TCP ont fait de TCP une meilleure option en termes de performances.
KaareZ

3
@ KaareZ Je ne suis pas un expert, mais réfléchissons-y. Comment TCP pourrait-il être meilleur en termes de performances et rester un protocole fiable? Vous ne pouvez pas tout avoir. TCP est fait pour la fiabilité. La vraie question est pourquoi voudriez-vous utiliser TCP dans votre jeu?
nathan

7
UDP est meilleur que TCP si et seulement si vous êtes capable (= programmeur expérimenté en réseau de bas niveau) de ne ré-implémenter que les fonctionnalités TCP dont vous avez besoin de manière efficace. Suppression des fonctionnalités TCP inutiles pour améliorer les performances.
Wondra

Réponses:


119

Non, UDP reste supérieur en termes de latence des performances et sera toujours plus rapide, en raison de la philosophie des 2 protocoles - en supposant que vos données de communication ont été conçues pour UDP ou toute autre communication avec pertes en tête.

TCP crée une abstraction dans laquelle tous les paquets du réseau arrivent, et ils arrivent dans l'ordre exact dans lequel ils ont été envoyés. Pour mettre en œuvre une telle abstraction sur un canal avec perte, il doit implémenter des retransmissions et des délais d'attente, qui prennent du temps. Si vous envoyez 2 mises à jour sur TCP et qu'un paquet de la première mise à jour est perdu, vous ne verrez pas la deuxième mise à jour jusqu'à ce que:

  1. La perte de la première mise à jour est détectée.
  2. Une retransmission de la première mise à jour est demandée.
  3. la retransmission est arrivée et a été traitée.

Peu importe la rapidité avec laquelle cela est fait en TCP, car avec UDP, vous ignorez simplement la première mise à jour et utilisez la seconde, la plus récente, en ce moment. Contrairement à TCP, UDP ne garantit pas que tous les paquets arrivent et il ne garantit pas qu’ils arrivent dans l’ordre.

Pour cela, vous devez envoyer le bon type de données et concevoir votre communication de manière à ce que la perte de données soit acceptable.

Si vous avez des données où chaque paquet doit arriver et que les paquets doivent être traités par votre jeu dans l'ordre dans lequel ils ont été envoyés, UDP ne sera pas plus rapide. En fait, utiliser UDP dans ce cas serait probablement plus lent parce que vous reconstruisez TCP et que vous l'implémentez au moyen d'UDP, auquel cas vous pourriez aussi bien utiliser TCP.

EDIT - Ajout de quelques informations supplémentaires pour intégrer / adresser certains des commentaires:

Normalement, le taux de perte de paquets sur Ethernet est très faible, mais il devient beaucoup plus élevé une fois que le WiFi est impliqué ou si l'utilisateur a un téléchargement en cours. Supposons que nous avons une perte de paquets parfaitement uniforme de 0,01% (aller simple, pas aller-retour). Sur un jeu de tir à la première personne, les clients doivent envoyer des mises à jour chaque fois que quelque chose se passe, par exemple lorsque le curseur de la souris tourne le lecteur, ce qui se produit environ 20 fois par seconde. Ils pourraient également envoyer des mises à jour par image ou selon un intervalle fixe, soit 60 à 120 mises à jour par seconde. Étant donné que ces mises à jour sont envoyées à des moments différents, elles seront / devraient être envoyées dans un paquet par mise à jour. Dans une partie à 16 joueurs, les 16 joueurs envoient ces 20 à 120 paquets par seconde au serveur, ce qui donne un total de 320 à 120 paquets par seconde. Avec notre taux de perte de paquets de 0,01%, nous nous attendons à perdre un paquet toutes les 5,2 à 31,25 secondes.

Sur chaque paquet que nous recevons après le paquet perdu, nous enverrons un DupAck, et après le 3ème DupAck, l'expéditeur retransmettra le paquet perdu . Donc, le temps requis par TCP pour lancer la retransmission est de 3 paquets, plus le temps nécessaire au dernier DupAck pour arriver à l'expéditeur. Ensuite, nous devons attendre la retransmission pour arriver, donc nous attendons au total 3 paquets + 1 latence aller-retour. La latence aller-retour est généralement de 0 à 1 ms sur un réseau local et de 50 à 200 ms sur Internet. Trois paquets arriveront généralement en 25 ms si nous envoyons 120 paquets par seconde et en 150 ms si nous envoyons 20 paquets par seconde.

En revanche, avec UDP, nous récupérons un paquet perdu dès que nous obtenons le prochain paquet. Nous perdons donc 8,3 ms si nous envoyons 120 paquets par seconde et 50 ms si nous envoyons 20 paquets par seconde.

Avec TCP, les choses se gâtent si nous devons également prendre en compte Nagle (si le développeur oublie de désactiver la fusion des envois, ou ne peut pas désactiver les ACK retardés ), éviter la congestion du réseau ou si la perte de paquets est suffisamment grave pour que nous puissions en tenir compte plusieurs. pertes de paquets (y compris Ack et DupAck perdus). Avec UDP, nous pouvons facilement écrire du code plus rapide parce que nous ne nous soucions tout simplement pas d'être un bon citoyen du réseau, contrairement à TCP.


Remarque: UDP peut diffuser sur un réseau local (avantage possible) et, puisque Vista demande à l'administrateur d'exécuter le serveur / la diffusion sur UDP (inconvénient) (UAC / pare-feu ont tendance à ne pas informer l'utilisateur qu'une action est requise).
PTwr

7
"Si vous envoyez 2 mises à jour sur TCP et qu'un paquet de la première mise à jour est perdu" C'est vrai, mais quelles sont les chances pour que cela se produise? Selon pingman : "Plus de 2% de perte de paquets sur une période
Mucaho

30
@Peter vous oubliez que dans les stalles de paquets TCP chaque abandonné chaque paquet suivant. Avec 100 ms, il pourrait facilement s'écouler entre 300 et 500 ms avant que ce paquet ne soit retransmis et reçu, donc 6 à 10 paquets sont bloqués toutes les 33 secondes. Ce sera certainement visible dans un FPS semblable à un séisme.
BlueRaja - Danny Pflughoeft

12
Sur de nombreuses implémentations TCP, le premier dépassement de délai après un ack manquant prendra une seconde complète. Ça fait longtemps . Si les paquets sont petits, le protocole UDP pourrait facilement atténuer une ou deux communications manquées en intégrant simplement les données des deux dernières mises à jour afin que l'application obtienne les données dont elle a besoin avant que l'expéditeur ou le destinataire ne sache que le premier paquet a disparu.
Supercat

23
Avec un jeu comme Quake, perdre le premier paquet n’a aucune importance. Dans FAR moins de temps qu'il vous faudrait pour détecter la perte et réémettre le premier paquet, vous devriez déjà avoir transmis un second paquet qui rend le premier obsolète de toute façon. C'est la même raison que beaucoup d'applications vocales et vidéo en temps réel utilisent également UDP. Si un paquet est abandonné, vous préférez de beaucoup perdre 0,02 seconde d’audio plutôt que de retarder le flux entier d’une seconde ou plus. La même chose est généralement vraie avec les jeux en temps réel, car vous voulez savoir où un objet est maintenant , pas il y a 1,5 seconde.
Reirab

19

Nous convenons que TCP et UDP sont des protocoles fondés sur IP , n'est-ce pas? IP spécifie comment les messages sont distribués sur Internet, mais rien ne concerne la structure, le format des messages. Voici les protocoles TCP et UDP. Ils utilisent les propriétés IP, mais permettent au programmeur de se concentrer sur l’échange de messages sans se soucier des couches inférieures de la communication réseau. Et c’est bien, car traiter avec des signaux analogiques directement sur les fils serait assez pénible.

  • TCP fournit un ensemble de fonctions pour envoyer et recevoir des messages. Il divise nos données en petits paquets et les envoie sur le réseau. Tout ce qui nous est demandé est un port à utiliser pour le socket réseau et le message que nous voulons envoyer. En outre, il est fiable, ce qui signifie que si certains paquets sont perdus le long du réseau, ils sont détectés, puis à nouveau envoyés en prenant soin de les envoyer dans le même ordre qu’ils étaient censés arriver.

  • D'autre part, UDP est un protocole orienté vers le contrôle de l'utilisateur. Lorsque nous utilisons UDP pour envoyer nos datagrammes , nous ne pouvons pas être sûrs qu’il arrivera ou non à destination (nous entendons par certitude mathématique: lorsque nous envoyons un paquet, il arrivera probablement, mais nous ne pouvons pas être sûr de 100%). De plus, lorsqu'un paquet est perdu, il ne sera ni détecté ni envoyé à nouveau.

À ce stade, TCP apparaîtrait comme la solution idéale à tous nos problèmes. C'est fiable, rapide, cela résout le temps de latence des connexions en gardant une trace de ce que les paquets sont arrivés et des paquets que nous devons encore envoyer.

MAIS , regarde au-delà. Le seul avantage que nous offre UDP est sa rapidité, et c’est ce que nous voulons vraiment. Un paquet UDP est simplement conçu, vérifié et envoyé sans contrôles particuliers, car c'est ainsi que fonctionne le protocole UDP. Un paquet TCP doit être fabriqué, étiqueté, vérifié, et quand il arrive, un ACK est renvoyé pour indiquer à l'expéditeur que "le paquet x est ici, continuez" , et quand ce signal n'est pas envoyé, cela signifie que ce paquet x doit être envoyé. encore.

Je sais que le protocole UDP est généralement recommandé pour les jeux multijoueurs en temps réel avec une utilisation élevée des données.

Oui mais pas seulement. Le protocole UDP est largement préféré au protocole TCP, principalement parce que sa vitesse élevée est l’idée idéale pour gérer l’envoi et la gestion de données élevées. Cela se produit lorsque, en supposant qu'un tel jeu vidéo fonctionne sur un pas déterministe (ce qui se passe sur le serveur est répliqué de manière identique sur tout client indépendamment de la latence du réseau), un paquet de mise à jour est perdu et n'arrive jamais à sa destination. TCP renverrait un tel paquet, et les paquets suivants sont abandonnés car ils n'arrivent pas dans l'ordre, puis sont renvoyés après le paquet perdu. UDP est beaucoup plus tolérant dans ce scénario: il ne se soucie pas de ce paquet, car de nouvelles mises à jour sont à venir. La mise à jour perdue n'est pas rendue, mais la physique du jeu est interpolée en fonction de la méthode d'intégration utilisée et de la dernière mise à jour reçue.

TCP provoque une instabilité lorsque la latence est suffisante, mais pas UDP:

<video style="min-width: 100% height: auto" autoplay="" preload="auto" loop="true"><source src="https://gafferongames.com/videos/deterministic_lockstep_tcp_250ms_5pc.mp4" type="video/mp4"><source src="http://173.255.195.190/cubes_deterministic_lockstep_tcp_250ms_5pc.webm" type="video/webm">Your browser does not support the video tag.</video>

Cela me fait me demander si UDP est toujours supérieur en termes de vitesse et de latence.

Eh bien, oui, et ça va durer longtemps . Vous pouvez en savoir plus sur TCP vs UDP ici .


8
TCP utilise des flux d'octets plutôt que de datagrammes. UDP utilise des datagrammes. De bonnes implémentations TCP garderont les paquets qui arrivent dans l’ordre, mais aucun contenu de paquet ne peut être mis à la disposition de l’application à moins que ou jusqu’à ce que tous les paquets précédents aient été reçus. Ainsi, si un paquet est perdu, l'expéditeur n'aura peut-être pas besoin de retransmettre tout ce qui suit le paquet perdu, mais l'application réceptrice ne verra plus rien au-delà du paquet perdu tant que ce paquet ne sera pas retransmis (après quoi l'application verra instantanément le contenu de celui-ci. paquet et ceux qui le suivent).
Supercat

@supercat Malheureusement, TCP n'a aucun moyen de dire à l'expéditeur exactement quels paquets il a reçus ou non. Il a seulement un mécanisme pour "j'ai reçu tous les octets jusqu'à x numéro de séquence." Si l'expéditeur retransmet les paquets que le destinataire a déjà reçus, il ignorera simplement les copies.
Reirab

@reirab: Je pensais qu'il existait des extensions modernes incluant cette fonctionnalité, mais même sans cela, je pense qu'une implémentation avait envoyé des données allant jusqu'à l'octet # 1 050 000 mais ne recevant que des acks pour des données allant jusqu'à 1 000 000, après une seconde sans audience tout ack dépassé 1 000 000, commencez par envoyer un bloc de données de 1 000 000 à 1 000 500 environ, puis attendez une réponse. S'il reçoit un accusé de réception pour des données allant jusqu'à 1 000 500, il peut alors retransmettre plus de données; s'il reçoit un accusé de réception pour des données allant jusqu'à 1 050 000, il peut ignorer les retransmissions.
Supercat

1
@Giorgio IP ne spécifie absolument rien sur les signaux analogiques. Cela se fait à la couche physique. IP exploite deux couches supérieures à celle de la couche réseau. IP ne se soucie pas de savoir si les bits passent par la fibre, une liaison par satellite ou un modem à numérotation à 14,4 kbps. UDP et TCP sont une couche d'IP, au niveau de la couche de transport. En outre, comme le dit supercat, TCP présente une interface de flux pour l'application, pas une interface de datagramme comme UDP.
Reirab

@supercat Hmm ... vous avez peut-être raison sur les extensions modernes, bien que cela ne fasse certainement pas partie de la norme TCP d'origine. Un ACK a juste un numéro de séquence. J'imagine qu'une implémentation TCP commencerait normalement à retransmettre la fenêtre d'envoi entière si un paquet est abandonné, au lieu d'attendre un RTT complet pour chaque paquet. Cela ajouterait une énorme quantité de temps de latence si plusieurs paquets consécutifs étaient perdus pour un gain minime.
Reirab

9

TCP <- Protocole de contrôle de transmission . Il est fait pour contrôler la transmission.

TCP a été créé pour être un bon citoyen du réseau diplomatique. Il vise à faire de la mise en réseau une bonne expérience pour tous et diminue volontiers le débit pour y parvenir. Il s'adapte à l'environnement en ajoutant de la latence . Les raisons sont par exemple:

  • Le destinataire détecte un paquet manquant et demande à l'expéditeur de ralentir (réduire de moitié le débit pendant un moment).
  • Receiver détecte le mauvais ordre des paquets entrants (ils ont peut-être emprunté des chemins réseau différents), demande à l'expéditeur de ralentir - et au fait, le destinataire n'acceptera plus de paquets tant que le paquet manquant n'aura pas été livré. Cela prend du temps.
  • L’expéditeur détecte la congestion du réseau (par exemple, un temps d’aller-retour lent) et ajoute de la latence.
  • Le récepteur ne peut pas suivre la vitesse (le tampon d’entrée devient trop plein), demande à l’envoyeur d’ajouter de la latence (contrôle de flux).
  • Il y a un seul récepteur lent (bâtard de ping élevé, crybaby, comment ils s'appellent) parmi les récepteurs, une latence (peut être) ajoutée dans le ménage.

aditionellement

  • L'algorithme de Nagle peut garder les données des expéditeurs en attente jusqu'à ce qu'il ne reste plus qu'à envoyer (afin d'utiliser les trames de données plus efficacement). Les données critiques sont retardées.
  • Je crois que les routeurs domestiques ordinaires avec wlan peuvent faire des choses intelligentes (ralentir) pour lisser le débit TCP entre plusieurs clients (l'interface wlan étant le goulot d'étranglement, même si le jeu ne l'utilise pas). Relatif à la diffusion / multidiffusion, c.-à-d. Les "autres" données peuvent diminuer votre débit TCP.
  • TCP ACKconnait tout ce qui n'est pas nécessaire pour un environnement de jeu. Il est inutile d’accepter chaque mise à jour physique. Assez pour reconnaître, par exemple une fois par seconde ou de la même manière. Si un client (ou un serveur) reste silencieux plus longtemps, il est temps de réagir.

Malgré cela, TCP fournit le chiffre le plus élevé pour (données transmises globalement) / (temps total consommé). Juste que cela n'arrive pas précisément quand vous voulez que cela se produise.

UDP ne fait rien de tout cela. Il tire sur votre volonté, mais on ne peut pas s’attendre à ce qu’il frappe à chaque fois. La cible doit annoncer que "vous n’avez pas tiré depuis longtemps, pourquoi?". On peut toujours créer ses propres paquets ACK personnalisés, mettre plusieurs enregistrements dans un seul paquet, etc. Il est également important de contrôler le parcours NAT. UDP est très certainement adapté aux jeux à faible demande de latence.


1
Remarque: l'algorithme de Nagle peut être désactivé, par exemple pour Linux .
Mucaho

Nagle peut fonctionner contre (et peut être contourné en réglant chaque paquet à "pousser" par l'application) pendant ce temps Delayed Ack fonctionne en faveur de TCP, il permet à l'expéditeur de mettre plus d'octets sur le fil jusqu'à ce que la fenêtre d'envoi soit pleine (idéalement aussi grande comme le tampon de réception est de l’autre côté) indépendamment du fait qu’un accusé de réception ait été vu.
Jeff Meden

4
C'est un protocole de contrôle de transmission .
Ysdx

1
Tapez ces mots un million de fois ... thx - corrigé.
Hurlevent le

3

Vous pouvez comparer le premier diagramme de RFC 768 (UDP) au premier diagramme de RFCP 793 (TCP) page 15 .

Les deux affichent 16 bits pour un «port source» suivi de 16 bits pour un «port de destination». Les deux affichent 16 bits pour une «somme de contrôle». Selon la RFC 768, la procédure de somme de contrôle d'UDP est la même que celle utilisée dans TCP.

Alors que la longueur d'UDP englobe les détails du diagramme d'UDP, la longueur de TCP fait partie d'un «pseudo en-tête de 96 bits» décrit aux pages 15 et 16.

Ne vous attendez pas à ce que TCP surpasse UDP. Ce n'est tout simplement pas susceptible de se produire, pour plusieurs raisons. La première est que TCP a simplement plus de bits. Donc, si un équipement peut traiter efficacement un certain nombre de bits par seconde, cela permettra plus de paquets UDP que de paquets TCP.

L'autre raison est que la "poignée de main à trois" de TCP signifie que l'expéditeur doit attendre une réponse. Cette exigence introduit une surcharge supplémentaire que UDP ne gère pas. Il y a une raison pour laquelle la plupart de vos communications Internet commencent par certaines communications UDP. Le DNS de base utilise UDP, car une requête et une réponse peuvent être complétées en moins d'étapes que le processus de "tris-handshake" de TCP. La fonctionnalité de TCP pour garder la trace des paquets perdus est plutôt dérangeante, car un ordinateur pourrait simplement faire une nouvelle requête au lieu d’essayer de laisser un système distant savoir qu’une requête antérieure n’a pas été satisfaite.


Bien que les résumés en anglais (comme on le voit dans certaines autres réponses) soient intéressants, il peut être plus simple de disposer de descriptions précises et précises.
TOOGAM

Vous voulez dire 16 bits, pas octets!
jcaron

Oh, bête moi. C’est un exemple de la raison pour laquelle les réponses techniquement précises sont bien; ils sont faciles à identifier les erreurs et voir les informations correctes. J'ai corrigé la réponse. Merci @jcaron
TOOGAM le

2

Considérez ce qui se passe pendant un moment. Pour simplifier les scénarios, vous avez deux choix lorsque vous essayez d'envoyer un changement d'état (par exemple, votre joueur vient de changer de direction, ou a tiré une arme à feu, ou un autre joueur a déclenché une bombe):

  1. Gardez une session TCP ouverte et, lorsque la bombe explose, envoyez un message TCP à tous les joueurs (si possible, voir ci-dessous).
  2. Gardez un port UDP à l'écoute et, lorsque la bombe explose, envoyez un message UDP à tous les joueurs, quel que soit leur état de connexion.

En supposant qu'aucune mise à jour ne soit nécessaire juste avant, le moment où cette mise à jour singulière arrive en 1 vs 2 ne sera pas très différent. C'est un voyage du serveur au client. Mais disons, au lieu de simplement lancer une bombe, vous essayez de relayer en permanence l’activité de quelqu'un qui traverse un labyrinthe; tissage, esquive, tir, etc. Dans le cas du protocole UDP, chaque action est envoyée dans un datagramme, dès que cela se produit. Dans le cas de TCP, chaque action ne sera envoyée dans un paquet que si le serveur est autorisé à envoyer. Qu'est-ce qu'il est permis d'envoyer? Avoir de la place dans la fenêtre TCP (en supposant que l’accusé de réception retardé est actif) afin que le message puisse être mis sur le fil. Sinon, il doit attendre qu'un accusé de réception du client lui soit envoyé avant de l'envoyer.

Combien de temps c'est trop long? À la fin des années 90 et au début des années 2000, le développement du jeu de tir en mode multijoueur à la première personne devenait très difficile à obtenir. Les connexions à faible latence n'étaient pas courantes. Un modem par numérotation aurait une latence unidirectionnelle typique de 180 ms. Attendre un accusé de réception avant d'envoyer une autre mise à jour, doublant effectivement ce délai à 360 ms, était pénible; Même les utilisateurs novices peuvent vraiment sentir la différence. Lorsque les connexions à large bande ont commencé à fonctionner, elles ont considérablement réduit la latence, mais elle persiste quand la bande passante est insuffisante (assez souvent dans certaines régions). La préférence pour la latence la plus faible possible a donc persisté.

Les connexions et interconnexions domestiques modernes ont changé la situation, à tel point que la latence régionale, même en période de pointe de la journée, se situe dans les 15 ms ou en dessous. Choisir TCP au lieu de UDP serait invisible dans la plupart des cas, car la latence est "suffisamment basse". Cependant, UDP a toujours tendance à être prioritaire par rapport à TCP étant donné son historique de protocole à faible temps de latence. Ainsi, pour le moment (et probablement dans le futur), UDP sera préféré pour la communication en temps réel.


La latence serait suffisamment faible, sauf que, par défaut, les écritures TCP ne sont envoyées que lorsque les données à écrire traversent un certain seuil ou qu'un délai d'expiration (généralement de 200 à 1 000 ms) se produit. Si vous avez besoin de TCP sur un système à faible temps de latence et à faible débit, vous devez désactiver cette fonction et vous assurer que vous n'écrivez pas tout le temps d'octets individuels (par exemple, vous ne traitez plus le flux TCP comme un flux et vous prétendez traite plutôt des messages individuels). Vous n'avez pas besoin d'attendre l'ACK à moins que vos tampons ne soient pleins, ce qui est peu probable dans un jeu en temps réel typique.
Luaan

1
@Luaan Enter: l'indicateur TCP PSH. Quand une application remet la pile, le paquet est envoyé immédiatement sans attendre plus de données. Beaucoup d'applications l'utilisent avec succès (telnet et ssh par exemple).
Jeff Meden

2

Je sais que le protocole UDP est généralement recommandé pour les jeux multijoueurs en temps réel avec une utilisation de données importante.
Le protocole UDP est-il toujours supérieur en termes de vitesse et de temps de latence? Les récentes optimisations TCP auraient-elles pu améliorer les performances de TCP par rapport à UDP?

Vos hypothèses sont fausses. TCP et UDP diffèrent principalement par le modèle qu’ils représentent (datagrammes peu fiables par rapport à un flux virtuel fiable en ordre).

Ils ne diffèrent pas en ce qui concerne le volume ("forte utilisation de données") ou le débit. TCP transmettra autant de données qu’UDP, il saturera facilement le câble physique.

En cas de perte de paquet, les deux diffèrent par la latence, mais uniquement dans cette condition. Sinon, le temps de latence de TCP est aussi faible que celui de UDP (à quelques dizaines de nanosecondes environ, car la pile réseau a un peu plus de logique à faire, mais ce n'est pas négligeable).
Il y a une légère différence dans la taille de l'en-tête, donc techniquement, plus d'octets doivent être acheminés par câble sur les lignes série, mais celui-ci est plutôt peu important également. Cela ne compte vraiment que pour les transferts groupés, et la différence est d'environ 0,5%. La plupart des personnes disposant d'un accès Internet à domicile DSL acheminent tout leur trafic sur ATM, ce qui ajoute 10% de surcharge de protocole (5 octets de contrôle pour 48 octets de charge utile, plus des trames partielles), sans que personne ne le remarque.

Certaines personnes construisent la fiabilité en plus de UDP. Si un certain niveau de fiabilité est souhaité, mais qu'une livraison dans l'ordre stricte n'est pas nécessaire, cela peut donner un léger avantage. Cependant, on peut se demander si cette approche est très sensée et vous payez un lourd tribut pour ce petit avantage.
Si vous avez des clients qui se connectent depuis l’hôtel WiFis ou d’autres lieux «étranges», vous remarquerez que, dans l’ensemble, le support technique pour TCP est bien meilleur que pour UDP.

Les jeux utilisent généralement UDP non pas parce qu’il est supérieur d’une des manières susmentionnées - ce n’est pas le cas - ou parce que vous pouvez réduire la gigue de une demi milliseconde en mettant en œuvre la fiabilité sans ordre, mais parce que les jeux (un peu comme la téléphonie IP) contiennent souvent beaucoup de données très volatiles, telles que par exemple les mises à jour de position.
Ces données volatiles sont régulièrement et rapidement obsolètes à la fois par le temps et par le prochain datagramme. Ce qui ne signifie rien de plus et rien de moins que vous ne vous souciez pas vraiment d’être fiable à 100% (ou en ordre).

En supposant qu'un paquet réseau tombe dans un service qui fonctionne à un rythme soutenu avec des mises à jour fréquentes (jeu de tir, téléphone, discussion vidéo), cela n'a pas beaucoup de sens de laisser le délai d’accusé de réception et de renvoyer le paquet. tout geler à l’autre bout en attendant que le paquet renvoyé arrive. C'est trop dérangeant, et rien de bon.

Au lieu de cela, il vous suffit de considérer le paquet perdu et de passer à autre chose, en prenant les données du prochain paquet qui le traverse et en attendant, de votre mieux, en masquant le fait qu'un paquet a été perdu par l'utilisateur. Interpolation, compte à rebours, nommez-le.

Notez en passant que la perte de paquets est une condition normale. Bien qu'IP soit généralement "assez fiable", des paquets occasionnellement abandonnés peuvent se produire et se produiront . Bien que les paquets en train d'être perdus soient normalement plutôt rares (<1% ici), ce n'est pas quelque chose d'extraordinaire ou de théorique, ni une indication que quelque chose est cassé. C'est parfaitement normal.
Chaque transfert en masse TCP inclura nécessairement les paquets perdus, par exemple (c'est ainsi que fonctionne le contrôle de congestion).


2

Dans un MPG à large bande passante, vous ne vous inquiétez pas de manquer un paquet vous indiquant l'emplacement et la santé de monster 425, car vous obtiendrez une autre mise à jour en une fraction de seconde. C’est là un exemple où UDP donne l’impression stupide à TCP de vous faire attendre des données instantanément obsolètes.

Dans ce même jeu, vous voulez que les correctifs apparaissent exactement tels qu'ils ont été conçus. TCP possède déjà les fonctionnalités intégrées "dites-moi si elle échoue", facilitant les tentatives automatiques et les échecs vérifiés. Vous pouvez le faire dans UDP, mais pourquoi recréer la technologie?

Voici une description simple de ce qui se passe.

UDP - Isoler le morceau O'data.
Faire un paquet.
Encapsuler en IP.
Expédier.

TCP - Isoler un flux O'data.
Faire un paquet de l'avant du flux.
Encapsuler en IP.
Attendez de l'espace dans la fenêtre TCP.
Expédier.
Continuez la réexpédition jusqu'à la réception d'un reçu ou l'expiration du délai.
Restez dans la fenêtre TCP jusqu'à la réception d'un accusé de réception ou l'expiration du délai.

L'expédition signifie simplement qu'elle a traversé la carte réseau locale, sans plus.

Une réception de réception TCP garantit à la fois la réception des données et libère de l’espace dans la fenêtre pour le prochain paquet.

Renvoyer (légèrement) augmente la probabilité de réception éventuelle.

Les paquets TCP sont réassemblés de l'autre côté en tant que flux de données ordonné. Les paquets UPD sont reçus en tant que paquet distinct. Le protocole ne préserve pas l'ordre.

Le protocole TCP est utile pour transmettre les données requises et les grandes quantités de données commandées. TCP fournit une notification d'un échec persistant. TCP s'auto-étrangle à travers des tuyaux étranglés (ref: window). TCP a des poignées de main pour ralentir l'initialisation. TCP nécessite une "connexion" avant la transmission.

UDP met simplement les données sur le réseau et vous permet de continuer sans attendre les fenêtres et les retransmissions. UDP envoie les données à toute vitesse dans un tuyau étranglé, quelle que soit la quantité de données perdue.

J'ai conçu et écrit un utilitaire de transport de fichiers multidiffusion UDP appliqué dans le commerce. J'ai travaillé sur des piles IP. Ce ne sont que des bases, sans minutie. Expliquer "prises, MTU et autres jouets amusants" dépassait un peu ce qui serait utile pour cette question.

Ps (je ne peux pas ajouter de commentaires pour répondre aux commentaires) UDP convient également aux données souhaitables mais non obligatoires. La correction d'erreur directe en est un exemple, beaucoup de paquets inutiles mais souhaitables.


3
Votre remarque sur les données "obsolètes" est bonne. Le protocole TCP est bon pour les données "mieux vaut tard que jamais", mais UDP est bon pour les données qui seront utiles si elles atteignent rapidement la destination, mais inutiles si ce n'est pas le cas.
Supercat

1

Est-ce que tous les routeurs optimisés TCP ont rendu TCP plus performant qu’UDP?

Une autre question à se poser: est-ce que "data heavy" signifie que vous allez fréquemment charger des scènes?

Si tel est le cas, vous devrez peut-être envoyer de grandes quantités de données (> 1 Ko) dans lesquelles TCP peut être beaucoup plus efficace, car du côté serveur, les cartes d'interface réseau fourniront divers déchargements correspondant au même lot de cycles. Une application d’espace utilisateur peut émettre de grosses écritures avec TCP alors qu’en UDP, une tentative d’envoi de plus d’octets de taille d’en-têtes MTU entraînerait une fragmentation IP et d’autres coûts indirects, qui réduiraient les performances.


C'est un jeu "voxel", donc oui, il faudra envoyer beaucoup de données de scènes.
KaareZ

@KaareZ Eh bien, vous voudrez probablement envoyer ces messages sous forme de messages individuels indépendants dans ce cas, avec vos propres mécanismes de retransmission. Minecraft a commencé sur TCP et était pratiquement injouable sur Internet; le passage à UDP était une occasion heureuse pour la plupart des gens. L'idée principale est que lorsque vous envoyez 20 morceaux de données voxel et que le premier est "perdu", il ne devrait pas empêcher les 19 autres morceaux de s'afficher dès que vous obtenez les données; lorsque vous trouvez que le premier est manquant, vous retransmettez. Sur TCP, tous les 19 sont au moins bloqués et retransmis au pire des cas.
Luaan

2
@ Luan Minecraft n'est pas passé à UDP pour le gameplay réel. Même les dernières versions utilisent encore TCP. Pas de bonne occasion ... :( La seule partie de Minecraft qui utilise UDP est la liste de serveurs, qui permet d'
envoyer une requête

1

Ni UDP, ni TCP (ni aucune autre variante) ne sont parfaitement supérieurs , pas même en termes de vitesse / latence. Votre choix doit être fait en fonction des exigences de votre application. Pour ce faire, vous devez comparer les fonctionnalités offertes par chaque protocole, en réalisant que plus de fonctionnalités implique davantage de temps système. Ainsi, si l'objectif est de minimiser la latence ou d'optimiser la vitesse, vous devez choisir un protocole comportant le moins de fonctionnalités possible, tout en conservant les fonctionnalités essentielles nécessaires pour répondre à vos besoins.

Une comparaison de protocoles

De manière générale, UDP (User Datagram Protocol) offre le moins de fonctionnalités. C'est simpliste en ce sens que vous envoyez des données sans aucune sorte de reçu / accusé de réception.

D'autre part, TCP (Transmission Control Protocol) offre le plus grand nombre de fonctionnalités nécessaires à une communication fiable et connectée. Une communication TCP envoie des doublons ou plus de paquets et les identifie avec les informations de commande. Lors de la réception à la destination, un accusé de réception (accusé de réception) doit être renvoyé avec les informations sur les paquets perdus afin que l'expéditeur d'origine puisse renvoyer les paquets perdus. Si je me souviens bien, même les paquets ACK peuvent nécessiter un accusé de réception pour une fiabilité optimale.


Exemple: conférence téléphonique Skype

Pour une conférence téléphonique Skype, il n’est pas important de s’assurer que toutes les données vidéo et audio sont envoyées / reçues de manière fiable. De nos jours, UDP réussit quand même à minimiser les pertes de paquets. La chose importante à savoir est qu'il n'y a absolument aucune garantie dans UDP si la transmission a réussi ou non. Pour les données audio / vidéo dans une conférence téléphonique, le format UDP est un choix judicieux, car nous attachons plus d'importance à l'obtention de données en temps réel (c'est-à-dire les plus récentes). Si quelques paquets sont perdus ici et là, la communication ne sera pas interrompue de manière dramatique.

Toutefois, lors d'une téléconférence, les utilisateurs peuvent envoyer des messages instantanés ou des fichiers. Dans ces cas, la fiabilité est une condition nécessaire pour garantir que les fichiers et les messages ne sont ni corrompus ni perdus. Pour les MI, vous n'avez peut-être pas besoin de l' état connecté fourni par TCP. Un protocole intermédiaire, tel que RUDP (Reliable UDP), peut suffire. Toutefois, pour les fichiers, il peut être nécessaire d’avoir l’état connecté fourni par TCP.


Choix d'implémentation

Si vous avez une application complexe ou avez besoin d'optimiser votre communication, il est avantageux de commencer par une communication UDP. Ensuite, vous pouvez ajouter toutes les fonctionnalités dont vous avez besoin. Cela vous donnera le plus de contrôle sur votre communication réseau.

Si vous avez une application simple où l'optimisation n'est pas requise, envisagez d'utiliser une solution standard (UDP ou TCP) pour répondre à vos besoins. Cela vous permettrait de passer à des questions plus importantes.


1

J'ai remarqué de nombreux commentaires où les gens pensent que les paquets TCP sont plus gros que les paquets UDP. Ne me faites pas confiance, lisez la documentation. Le protocole est le suivant: quelques octets pour l'en-tête Ethernet (type de message 2 octets, MAC 48 bits, 6 octets) (pour le Wifi, l'en-tête peut être différent) 20 octets pour IP 20 octets pour TCP ou UDP x octets pour la plage de données x de 0 à environ 1500 (voir MTU) Enfin, la somme de contrôle pour s'assurer qu'aucune corruption ne s'est produite dans ce paquet Ethernet.

TCP permet d’envoyer un paquet "stream" plus volumineux d’environ 64K. Ce "gros" bloc est en fait haché dans de nombreux paquets Ethernet plus petits.


Essayez-vous de suggérer que les en-têtes UDP et TCP ont la même taille?
Cameron
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.