UDP vs TCP, combien plus rapide est-il?

Pour l’échange de messages de protocole général, qui peut tolérer une perte de paquets. Quelle est l’efficacité de UDP sur TCP?

UDP est plus rapide que TCP, et la raison simple est que son paquet d’accusé de réception inexistant (ACK) qui permet un stream de paquets continu, au lieu de TCP qui reconnaît 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 recommande l’ explication simple mais très compréhensible de Skullbox (TCP vs UDP)

Les gens disent que le principal avantage de TCP est la fiabilité. Mais ce n’est pas vraiment vrai. La chose la plus importante que TCP vous donne est le contrôle de la congestion: vous pouvez exécuter 100 connexions TCP sur un lien DSL à la vitesse maximale, et toutes 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 se passent bien pour vous.

À plus grande échelle, ce comportement TCP empêche Internet de se bloquer dans un «effondrement de la congestion».

Ce qui a tendance à pousser les applications vers UDP:

  • Sémantique de la livraison de groupe: il est possible d’effectuer une livraison fiable à un groupe de personnes beaucoup plus efficacement que la reconnaissance point à sharepoint TCP.

  • Livraison hors commande: dans de nombreuses applications, tant que vous obtenez toutes les données, vous ne vous souciez pas de leur ordre d’arrivée. Vous pouvez réduire la latence au niveau de l’application en acceptant un bloc en désordre.

  • Inopportunité: sur une partie LAN, vous ne vous souciez peut-être pas du bon fonctionnement de votre navigateur Web tant que vous modifiez les mises à jour sur le réseau aussi rapidement que possible.

Mais même si vous vous souciez de la performance, vous ne voudrez probablement pas utiliser UDP:

  • Vous êtes en quête de fiabilité maintenant, et beaucoup de choses que vous pourriez faire pour implémenter la fiabilité peuvent finir par être plus lentes que TCP.

  • Maintenant, vous n’êtes pas favorable au 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; iSCSI le fait pour contourner le contrôle de congestion sur les réseaux locaux, mais vous pouvez également le faire pour créer un canal de messagerie “urgent” à faible latence (le comportement “URGENT” de TCP est totalement rompu).

Dans certaines applications, le protocole TCP est plus rapide (meilleur débit) que le protocole UDP.

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

La raison en est que TCP essaiera de mettre en mémoire tampon les données et remplira un segment de réseau complet, ce qui optimisera l’utilisation de la bande passante disponible.

UDP met le paquet sur le câble immédiatement, congestionnant ainsi le réseau avec beaucoup de petits paquets.

Vous ne devriez probablement pas utiliser UDP à moins que vous n’ayez une raison très précise de le faire. Surtout que vous pouvez accorder à TCP le même type de latence que UDP en désactivant l’ algorithme Nagle (par exemple, si vous transmettez des données de capteur en temps réel et que vous ne craignez pas de congestionner le réseau avec de nombreux petits paquets).

avec tolérance aux pertes

Voulez-vous dire “avec tolérance à la perte”?

Fondamentalement, UDP n’est pas “tolérant aux pertes”. Vous pouvez envoyer 100 paquets à quelqu’un et ils ne recevront peut-être que 95 de ces paquets, et certains pourraient être dans le mauvais ordre.

Pour des choses comme le streaming vidéo et le jeu multijoueur, où il est préférable de rater un paquet que de retarder tous les autres paquets derrière lui, c’est le choix évident.

Pour la plupart des autres choses, un paquet manquant ou «réarrangé» est essentiel. Vous devrez écrire un code supplémentaire pour exécuter UDP afin de réessayer si les choses ont été manquées et appliquer le bon ordre. Cela appendait un peu de frais généraux à certains endroits.

Heureusement, certaines personnes très intelligentes l’ont fait, et ils l’ont appelé TCP.

Pensez-y de cette façon: Si un paquet est manquant, préféreriez-vous simplement récupérer 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 ne seront pas importants à moins que vous ne soyez dans un scénario vraiment critique.

Le protocole qui fonctionne le mieux (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, indique un scénario dans lequel TCP fonctionne mieux (écritures de petite taille). Considérons maintenant un scénario dans lequel le réseau est encombré et présente à la fois un trafic TCP et UDP. Les expéditeurs du réseau qui utilisent TCP détecteront la congestion et réduiront leurs taux d’envoi. Cependant, UDP ne dispose d’aucun mécanisme d’évitement des encombrements ou de contrôle de la congestion, et les expéditeurs utilisant UDP continueraient à pomper les données au même rythme. Progressivement, les expéditeurs TCP réduiraient au minimum leurs taux d’envoi et, si les expéditeurs UDP disposaient de suffisamment de données pour être envoyés sur le réseau, ils utiliseraient la plus grande partie de la bande passante disponible. Ainsi, dans un tel cas, les expéditeurs UDP auront un débit plus élevé, car ils obtiennent le plus gros volume 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 sum totale du débit de toutes les connexions TCP peut être supérieure au débit d’une application utilisant UDP.

Chaque connexion TCP nécessite une prise de contact initiale 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 dissortingbution des messages. Pour un échange de messages, UDP suffira probablement si une petite chance d’échec est acceptable. Si la réception doit être vérifiée, TCP est votre meilleure option.

@ Andrew , je vous prie de différer. 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 compte est de savoir si vous avez besoin de la multidiffusion. Si oui, utilisez UDP.

En parlant de “ce qui est plus rapide” – il y a au moins deux aspects très différents: le débit et la latence.

Si parler de débit – le contrôle de stream de TCP (comme mentionné dans d’autres réponses), est extrêmement important et faire quelque chose de comparable sur UDP, bien que cela soit certainement possible, serait un gros casse-tête ™. Par conséquent, utiliser UDP lorsque vous avez besoin de débit est rarement considéré comme une bonne idée (sauf si vous souhaitez obtenir un avantage indu par rapport à TCP).

Cependant, si vous parlez de latences , le tout est complètement différent. Bien qu’en l’absence de perte de paquets, TCP et UDP se comportent de manière extrêmement similaire (toute différence, s’il y en a, étant marginale) – une fois le paquet perdu, l’ensemble du motif 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 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 la communication entière est retardée de ~ 200ms). -Line Blocking, est inhérent à tous les stream ordonnés fiables, que ce soit TCP ou UDP ordonné + fiable. Pour aggraver les choses – si le paquet retransmis est également perdu, alors nous parlerons de délai de ~ 600ms (en raison de ce que nous appelons les retards exponentiels, la première retransmission est à 200ms et la seconde à 200 * 2 = 400ms). Si notre chaîne a 1% de perte de paquets (ce qui n’est pas mauvais par rapport aux normes actuelles) et que nous avons un jeu avec 20 mises à jour par seconde, ces délais de 600 ms se produiront en moyenne toutes les 8 minutes. Et comme 600ms est plus que suffisant pour vous tuer dans un jeu rapide, eh bien, c’est plutôt mauvais pour le gameplay. Ces effets sont précisément la raison pour laquelle les gamedev préfèrent souvent le protocole UDP au protocole TCP.

Cependant, lorsque vous utilisez UDP pour réduire les temps de latence, il est important de comprendre que le simple “utilisation de UDP” ne suffit pas pour obtenir une amélioration significative de la latence. En particulier, alors que les bibliothèques RUDP évitent généralement ce “retard exponentiel” et utilisent des durées de retransmission plus courtes – si elles sont utilisées comme un stream “ordonné fiable”, elles doivent toujours subir un blocage de tête (donc en cas de double perte de paquets, au lieu de 600ms nous aurons environ 1.5 * 2 * RTT – ou pour un assez bon RTT de 80ms, c’est un retard de ~ 250ms, ce qui est une amélioration, mais il est toujours possible de faire mieux. D’un autre côté, si vous utilisez des techniques abordées dans http://gafferongames.com/networked-physics/snapshot-compression/ et / ou http://ithare.com/udp-from-mog-perspective/#low-latency- la compression , il est possible d’éliminer complètement le blocage de la tête de ligne (donc, pour une perte de deux paquets pour un jeu avec 20 mises à jour / seconde, le délai sera de 100 ms, indépendamment de la RTT).

Et en passant, si vous n’avez access qu’à TCP mais pas à UDP (comme dans le navigateur, ou si votre client est derrière l’un des 6 à 9% de pare-feu laids), il semble y avoir un moyen de implémenter UDP-over-TCP sans encourir trop de latences, voir ici: http://ithare.com/almost-zero-additional-latency-udp-over-tcp/ (assurez-vous de lire aussi les commentaires (!)).

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

Si c’est un protocole avec échange de messages, je dirais que le très faible impact sur les performances que vous obtenez avec TCP vaut plus que la peine. Vous avez un lien entre deux points finaux qui vous donneront tout ce dont vous avez besoin. N’essayez pas de fabriquer votre propre protocole bidirectionnel fiable en plus du protocole UDP, à moins que vous ne soyez vraiment sûr de ce que vous entreprenez.

Si vous avez besoin de diffuser rapidement un message sur le Web entre deux adresses IP qui n’ont pas encore été évoquées, un protocole UDP va arriver au moins 3 fois plus rapidement, généralement 5 fois plus rapidement.

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

Des travaux ont été réalisés pour permettre au programmeur d’avoir les avantages des deux mondes.

SCTP

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

  • dans l’ordre de livraison des messages
  • retransmission automatique des messages perdus, avec des parameters définis par l’utilisateur

si l’un de ces éléments est nécessaire pour votre application particulière.

Un problème avec ceci est que l’établissement de la connexion est un processus compliqué (et donc lent).

D’autres choses similaires

Une autre chose expérimentale propriétaire similaire

Cela essaie également d’améliorer la sortingple prise en main de TCP et de modifier le contrôle de congestion pour mieux gérer les lignes rapides.

Je vais juste clarifier les choses. TCP / UDP sont deux voitures qui sont conduites sur la route. Supposons que les panneaux de signalisation et les obstacles soient des erreurs TCP se soucie des panneaux de signalisation, respecte tout autour. Conduite lente parce que quelque chose peut arriver à la voiture. Alors que l’ UDP se déclenche, la vitesse maximale ne respecte pas les panneaux de signalisation. Rien, un pilote fou. UDP n’a pas de récupération d’erreur, s’il y a un obstacle, il ne fera que se heurter à lui, puis continuer. Alors que TCP s’assure que tous les paquets sont envoyés et reçus parfaitement, pas d’erreurs, la voiture ne fait que passer les obstacles sans entrer en collision. J’espère que c’est un bon exemple à comprendre, pourquoi UDP est préféré dans les jeux. Le jeu a besoin de vitesse. TCP est utilisé dans les téléchargements ou les fichiers téléchargés peuvent être endommagés.

Il est inutile de parler du protocole TCP ou UDP sans tenir compte de l’état du réseau. Si le réseau entre les deux points est de très haute qualité, le protocole UDP est absolument plus rapide que le protocole TCP, mais dans d’autres cas, comme le réseau GPRS, le protocole TCP peut être plus rapide et plus fiable que le protocole UDP.

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 à l’autre bout du monde.

Trois choses que je veux append à la discussion:

  1. Vous pouvez trouver ici un très bon article sur TCP vs UDP dans le contexte du développement de jeux.
  2. En outre, iperf ( Jperf Enhance iperf avec une interface graphique) est un très bon outil pour répondre à votre question en mesurant.
  3. J’ai implémenté un benchmark en Python (voir cette question SO ). En moyenne 10 ^ 6 itérations, la différence pour l’envoi de 8 octets est d’environ 1 à 2 microsecondes pour le protocole UDP.