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

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?

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.

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 .

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.

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.

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.

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).

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.

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.

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.

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.