UDP vs TCP, à quel point est-il plus rapide ?[fermé]

Question

Pour l'échange de messages de protocole général, qui peut tolérer une certaine perte de paquets.Dans quelle mesure UDP est-il plus efficace que TCP ?

Answer 1

UDP est plus rapide que TCP, et la raison simple est que son paquet d'accusé de réception (ACK) inexistant permet un flux de paquets continu, au lieu de TCP qui accuse réception d'un ensemble de paquets, calculé en utilisant la taille de la fenêtre TCP et le temps d'aller-retour (RTT). ).

Pour plus d'informations je vous conseille le simple, mais très compréhensible Explication de Skullbox (TCP vs.UDP)

Answer 2

Les gens disent que la principale chose que TCP vous apporte est la fiabilité.Mais ce n'est pas vraiment vrai.La chose la plus importante que TCP vous offre est le contrôle de la congestion :vous pouvez exécuter 100 connexions TCP sur une liaison DSL, toutes à vitesse maximale, et les 100 connexions seront productives, car elles "détectent" toutes la bande passante disponible.Essayez cela avec 100 applications UDP différentes, toutes poussant les paquets aussi vite que possible, et voyez à quel point les choses fonctionnent pour vous.

À plus grande échelle, ce comportement de TCP est ce qui empêche Internet de s'enfermer dans un « effondrement de la congestion ».

Choses qui ont tendance à pousser les applications vers UDP :

• Sémantique de livraison de groupe :il est possible d'effectuer une livraison fiable à un groupe de personnes beaucoup plus efficacement que l'accusé de réception point à point de TCP.

• Livraison hors commande :dans de nombreuses applications, tant que vous obtenez toutes les données, peu importe l'ordre dans lequel elles arrivent ;vous pouvez réduire la latence au niveau de l'application en acceptant un blocage dans le désordre.

• Inconvivialité :lors d'une soirée LAN, vous ne vous soucierez peut-être pas du bon fonctionnement de votre navigateur Web tant que vous effectuez des mises à jour sur le réseau aussi rapidement que possible.

Mais même si vous vous souciez des performances, vous ne voudrez probablement pas opter pour UDP :

• Vous êtes désormais tributaire de la fiabilité, et beaucoup de choses que vous pourriez faire pour implémenter la fiabilité peuvent finir par être plus lentes que ce que TCP fait déjà.

• Vous n'êtes désormais plus convivial avec le réseau, ce qui peut entraîner des problèmes dans les environnements partagés.

• Plus important encore, les pare-feu vous bloqueront.

Vous pouvez potentiellement surmonter certains problèmes de performances et de latence TCP en « regroupant » plusieurs connexions TCP ensemble ;iSCSI fait cela pour contourner le contrôle de congestion sur les réseaux locaux, mais vous pouvez également le faire pour créer un canal de message « urgent » à faible latence (le comportement « URGENT » de TCP est totalement interrompu).

Answer 3

Dans certaines applications, TCP est plus rapide (meilleur débit) qu'UDP.

C'est le cas lorsque vous effectuez de nombreuses petites écritures par rapport à la taille de la MTU.Par exemple, j'ai lu une expérience dans laquelle un flux de paquets de 300 octets était envoyé via Ethernet (MTU de 1 500 octets) et TCP était 50 % plus rapide que UDP.

La raison en est que TCP essaiera de mettre les données en mémoire tampon et de remplir un segment de réseau complet, permettant ainsi une utilisation plus efficace de la bande passante disponible.

UDP, en revanche, met immédiatement le paquet sur le câble, encombrant ainsi le réseau avec de nombreux petits paquets.

Vous ne devriez probablement pas utiliser UDP, sauf si vous avez une raison très précise de le faire.D'autant plus que vous pouvez donner à TCP le même type de latence qu'à UDP en désactivant le Algorithme Nagle (par exemple, si vous transmettez des données de capteurs en temps réel et que vous ne craignez pas d'encombrer le réseau avec de nombreux petits paquets).

Answer 4

avec tolérance aux pertes

Voulez-vous dire "avec tolérance aux pertes" ?

Fondamentalement, UDP n'est pas "tolérant aux pertes".Vous pouvez envoyer 100 paquets à quelqu'un, et il se peut qu'il n'en reçoive que 95, et certains peuvent être dans le mauvais ordre.

Pour des choses comme le streaming vidéo et les jeux multijoueurs, où il est préférable de rater un paquet plutôt que de retarder tous les autres paquets qui le suivent, c'est le choix évident.

Cependant, pour la plupart des autres choses, un paquet manquant ou « réorganisé » est critique.Vous devrez écrire du code supplémentaire à exécuter sur UDP pour réessayer si des choses ont été manquées et appliquer l'ordre correct.Cela ajouterait un peu de frais généraux à certains endroits.

Heureusement, des personnes très très intelligentes l'ont fait et l'ont appelé TCP.

Pense-y de cette façon:Si un paquet disparaît, préférez-vous simplement obtenir le paquet suivant le plus rapidement possible et continuer (utilisez UDP), ou avez-vous réellement besoin de ces données manquantes (utilisez TCP).Les frais généraux n'auront pas d'importance, sauf si vous vous trouvez dans un scénario vraiment extrême.

Answer 5

Le protocole le plus performant (en termes de débit) – UDP ou TCP – dépend vraiment des caractéristiques du réseau et du trafic réseau.Robert S.Barnes, par exemple, souligne un scénario dans lequel TCP fonctionne mieux (écritures de petite taille).Imaginons maintenant un scénario dans lequel le réseau est encombré et comporte à la fois du trafic TCP et UDP.Les expéditeurs du réseau qui utilisent TCP ressentiront la « congestion » et réduiront leurs tarifs d’envoi.Cependant, UDP ne dispose d'aucun mécanisme d'évitement ou de contrôle de la congestion, et les expéditeurs utilisant UDP continueraient à injecter des données au même rythme.Progressivement, les expéditeurs TCP réduiraient leurs taux d'envoi au strict minimum et si les expéditeurs UDP disposaient de suffisamment de données à envoyer sur le réseau, ils accapareraient la majorité de la bande passante disponible.Ainsi, dans un tel cas, les expéditeurs UDP auront un débit plus élevé, car ils obtiendront la plus grande partie de la bande passante du réseau.En fait, il s'agit d'un sujet de recherche actif : comment améliorer le débit TCP en présence de trafic UDP.À ma connaissance, les applications TCP peuvent améliorer le débit en ouvrant plusieurs connexions TCP.De cette façon, même si le débit de chaque connexion TCP peut être limité, la somme totale du débit de toutes les connexions TCP peut être supérieure au débit d'une application utilisant UDP.

Answer 6

Chaque connexion TCP nécessite une première prise de contact avant la transmission des données.En outre, l'en-tête TCP contient beaucoup de surcharge destinée à différents signaux et à la détection de la livraison des messages.Pour un échange de messages, UDP suffira probablement si un petit risque d'échec est acceptable.Si la réception doit être vérifiée, TCP est votre meilleure option.

Answer 7

@André, Je ne suis pas d'accord.UDP est le choix dans certains types d'applications en raison des exigences de performances.Un exemple classique est la vidéoconférence.Ce type d'application ne répond pas bien au contrôle TCP.

Un autre aspect à prendre en considération est de savoir si vous avez besoin de multidiffusion.Si c'est le cas, utilisez UDP.

Answer 8

Quand on parle de « ce qui est plus rapide », il y a au moins deux aspects très différents :débit et latence.

Si on parle de débit - Le contrôle de flux de TCP (comme mentionné dans d'autres réponses) est extrêmement important et faire quelque chose de comparable sur UDP, bien que certainement possible, serait un gros casse-tête (tm).En conséquence - en utilisant UDP lorsque vous en avez besoin débit, est rarement considéré comme une bonne idée (sauf si vous souhaitez obtenir un avantage injuste sur TCP).

Cependant, si on parle de latences - le tout est complètement différent.Alors qu'en l'absence de perte de paquets, TCP et UDP se comportent de manière extrêmement similaire (toute différence, le cas échéant, étant marginale) - une fois le paquet perdu, l'ensemble du modèle change radicalement.

Après toute perte de paquet, TCP attendra la retransmission pendant au moins 200 ms (1 seconde selon le paragraphe 2.4 de la RFC6298, mais les implémentations modernes et pratiques ont tendance à le réduire à 200 ms).De plus, avec TCP, même les paquets qui ont atteint l'hôte de destination ne seront pas livrés à votre application tant que le paquet manquant n'est pas reçu (c'est-à-dire que toute la communication est retardée d'environ 200 ms) - BTW, cet effet, connu sous le nom de Head-of -Le blocage de ligne est inhérent à tous les flux ordonnés fiables, qu'ils soient TCP ou UDP fiable + ordonné.Pour aggraver les choses - si le paquet retransmis est également perdu, nous parlerons alors d'un délai d'environ 600 ms (en raison de ce que l'on appelle l'intervalle exponentiel, la première retransmission est de 200 ms et la seconde de 200*2 = 400 ms).Si notre chaîne présente 1 % de perte de paquets (ce qui n'est pas mauvais selon les normes actuelles) et que nous avons un jeu avec 20 mises à jour par seconde, de tels retards de 600 ms se produiront en moyenne toutes les 8 minutes.Et comme 600 ms sont plus que suffisants pour vous tuer dans un jeu rapide, eh bien, c'est plutôt mauvais pour le gameplay.Ces effets sont exactement la raison pour laquelle les développeurs de jeux préfèrent souvent UDP à TCP.

Cependant, lorsque vous utilisez UDP pour réduire les latences, il est important de réaliser que le simple fait d'"utiliser UDP" n'est pas suffisant pour obtenir une amélioration substantielle de la latence, tout dépend de la manière dont vous utilisez UDP.En particulier, alors que les bibliothèques RUDP évitent généralement ce « recul exponentiel » et utilisent des temps de retransmission plus courts, si elles sont utilisées comme flux « ordonné et fiable », elles doivent quand même souffrir d'un blocage de tête de ligne (donc en cas de double perte de paquets, au lieu de ces 600 ms, nous obtiendrons environ 1,5*2*RTT - ou pour un assez bon RTT de 80 ms, c'est un délai d'environ 250 ms, ce qui est une amélioration, mais il est encore possible de faire mieux).D'un autre côté, si vous utilisez les techniques décrites dans http://gafferongames.com/networked-physics/snapshot-compression/ et/ou http://ithare.com/udp-from-mog-perspective/#low-latency-compression , il EST possible d'éliminer complètement le blocage en tête de ligne (donc pour une double perte de paquets pour un jeu avec 20 mises à jour/seconde, le délai sera de 100 ms quel que soit le RTT).

Et en remarque - si vous avez accès uniquement à TCP mais pas à UDP (comme dans un navigateur, ou si votre client est derrière l'un des 6 à 9 % de pare-feu laids bloquant UDP) - là semble pour être un moyen d'implémenter UDP-over-TCP sans trop de latences, voir ici : http://ithare.com/almost-zero-additional-latency-udp-over-tcp/ (assurez-vous également de lire les commentaires (!)).

Answer 9

Si vous avez besoin d'envoyer rapidement un message sur le net entre deux adresses IP qui n'ont même pas encore parlé, alors un UDP arrivera au moins 3 fois plus vite, généralement 5 fois plus vite.

Answer 10

UDP est légèrement plus rapide d'après mon expérience, mais pas de beaucoup.Le choix ne doit pas être fait sur les performances mais sur le contenu du message et les techniques de compression.

Si c'est un protocole avec message échange, je dirais que le très léger impact sur les performances que vous subissez avec TCP en vaut largement la peine.Vous disposez d'une connexion entre deux points finaux qui vous donnera tout ce dont vous avez besoin.N'essayez pas de fabriquer votre propre protocole bidirectionnel fiable au-dessus d'UDP à moins que vous ne soyez vraiment très confiant dans ce que vous entreprenez.

Answer 11

Gardez à l’esprit que TCP conserve généralement plusieurs messages sur le réseau.Si vous souhaitez implémenter cela dans UDP, vous aurez beaucoup de travail si vous voulez le faire de manière fiable.Votre solution sera soit moins fiable, moins rapide, soit une quantité de travail incroyable.Il existe des applications valides d'UDP, mais si vous posez cette question, ce n'est probablement pas le cas.

Answer 12

Je vais juste clarifier les choses. TCP/UDP il y a deux voitures qui roulent sur la route.supposons que les panneaux de signalisation et les obstacles sont des erreurs TCP prend soin des panneaux de signalisation, respecte tout ce qui l'entoure.Conduite lente car quelque chose pourrait arriver à la voiture.Alors que UDP il démarre à toute vitesse, sans respecter les panneaux de signalisation.Rien, un conducteur fou. UDP n'a pas de récupération d'erreur, s'il y a un obstacle, il entrera simplement en collision avec lui puis continuera.Alors que TCP s'assure que tous les paquets sont envoyés et reçus parfaitement, aucune erreur, donc la voiture franchit simplement les obstacles sans entrer en collision.J'espère que c'est un bon exemple pour que vous compreniez pourquoi UDP est préféré dans les jeux.Le jeu a besoin de vitesse. TCP est préféré dans les téléchargements, sinon les fichiers téléchargés peuvent être corrompus.

Answer 13

Certains travaux ont été réalisés pour permettre au programmeur de bénéficier des avantages des deux mondes.

SCTP

Il s'agit d'un protocole de couche de transport indépendant, mais il peut être utilisé comme bibliothèque fournissant une couche supplémentaire sur UDP.L'unité de communication de base est un message (mappé sur un ou plusieurs paquets UDP).Un contrôle de la congestion est intégré.Le protocole a des boutons et des boutons pour allumer

• dans l'ordre de livraison des messages
• retransmission automatique des messages perdus, avec paramètres définis par l'utilisateur

si tout cela est nécessaire pour votre application particulière.

L’un des problèmes est que l’établissement de la connexion est un processus compliqué (et donc lent).

D'autres trucs similaires

• https://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol

Une autre chose expérimentale propriétaire similaire

• https://en.wikipedia.org/wiki/QUIC

Cela tente également d'améliorer la prise de contact à trois voies de TCP et de modifier le contrôle de la congestion pour mieux gérer les lignes rapides.

Answer 14

Cela n’a aucun sens de parler de TCP ou d’UDP sans prendre en compte l’état du réseau.Si le réseau entre les deux points est de très haute qualité, UDP est absolument plus rapide que TCP, mais dans d'autres cas, comme le réseau GPRS, TCP peut être plus rapide et plus fiable qu'UDP.

Answer 15

La configuration du réseau est cruciale pour toute mesure.Cela fait une énorme différence si vous communiquez via des sockets sur votre machine locale ou avec l’autre bout du monde.

Trois choses que je souhaite ajouter à la discussion :

1. Tu peux trouver ici un très bon article sur TCP vs.UDP dans le contexte du développement de jeux.
2. En plus, iperf (jperf Améliorer iPerf avec une interface graphique) est un très bel outil pour répondre à votre question vous-même en mesurant.
3. J'ai implémenté un benchmark en Python (voir cette question SO).En moyenne sur 10^6 itérations, la différence pour l'envoi de 8 octets est d'environ 1 à 2 microsecondes pour UDP.