Quand est-il approprié d'utiliser UDP au lieu de TCP? [fermé]


304

Puisque TCP garantit la livraison des paquets et peut donc être considéré comme "fiable", alors qu'UDP ne garantit rien et que les paquets peuvent être perdus. Quel serait l'avantage de transmettre des données en utilisant UDP dans une application plutôt que sur un flux TCP? Dans quel genre de situations l'UDP serait-il le meilleur choix, et pourquoi?

Je suppose que UDP est plus rapide car il n'a pas la charge de créer et de maintenir un flux, mais cela ne serait-il pas inutile si certaines données n'atteignent jamais leur destination?


55
En plus de souffrir d'une éventuelle perte de paquets, UDP ne garantit pas que vous ne recevrez le paquet qu'une seule fois. Si vous avez des réseaux compliqués ou mal configurés, vous pouvez recevoir le même paquet plusieurs fois. Attention, les gens ont tendance à oublier ça!
Brian Agnew

3
Il ne garantit même pas la commande de paquets.
Mehrdad Afshari

19
TCP ne garantit pas la livraison , il garantit simplement que s'il est capable de livrer les paquets, ils seront dans le même ordre qu'ils ont été envoyés.
Chaim Geretz

5
BTW, je vois souvent des gens assimiler la fiabilité / la livraison dans l'ordre aux retransmissions TCP. Ces "experts" vous diront que pour surmonter les erreurs de transmission sur UDP, vous réimplémenterez TCP (mal) et donc vous pourriez aussi bien utiliser TCP. Ce n'est pas vrai. Outre la retransmission, il existe d'autres techniques de récupération d'erreur qui ne subissent pas de latence ou de débit exponentiellement dégradé en raison de taux d'erreur faibles mais non nuls.
Ben Voigt

TCP garantit également que vous saurez si la destination n'a pas reçu les paquets.
csga5000

Réponses:


354

C'est une de mes questions préférées. UDP est tellement mal compris.

Dans les situations où vous voulez vraiment obtenir rapidement une réponse simple à un autre serveur, UDP fonctionne mieux. En général, vous voulez que la réponse soit dans un seul paquet de réponse et vous êtes prêt à implémenter votre propre protocole pour la fiabilité ou à renvoyer. DNS est la description parfaite de ce cas d'utilisation. Les coûts des configurations de connexion sont beaucoup trop élevés (pourtant, DNS prend également en charge un mode TCP).

Un autre cas est celui où vous livrez des données qui peuvent être perdues car de nouvelles données entrant remplaceront ces données / états précédents. Les données météorologiques, le streaming vidéo, un service de cotation d'actions (non utilisé pour le trading réel) ou les données de jeu viennent à l'esprit.

Un autre cas est lorsque vous gérez une quantité énorme d'état et que vous voulez éviter d'utiliser TCP car le système d'exploitation ne peut pas gérer autant de sessions. C'est un cas rare aujourd'hui. En fait, il y a maintenant des piles TCP utilisateur-terre qui peuvent être utilisées afin que le rédacteur d'application puisse avoir un contrôle plus fin sur les ressources nécessaires pour cet état TCP. Avant 2003, UDP était vraiment le seul jeu en ville.

Un autre cas concerne le trafic multicast. UDP peut être multidiffusé sur plusieurs hôtes alors que TCP ne peut pas du tout le faire.


Merci pour la réponse intéressante. Nous avons actuellement un serveur qui fait tout en UDP (exigence de bande passante élevée), ce qui est correct car il y a vraiment un seul saut (routage désactivé, ...), mais nous avons remarqué que la réorganisation des paquets pouvait devenir un problème sur certaines cartes réseau défectueuses. Quelle pile TCP en mode utilisateur (ou autre pile contrôlée par le flux en mode utilisateur) proposez-vous?
dashesy

@dashesy - pouvez-vous vous débarrasser des exigences de commande? Y a-t-il un nombre croissant monotone dans la charge utile que vous pouvez utiliser? Si c'est le cas, vous n'avez pas vraiment besoin d'une pile TCP de terrain utilisateur complète.
drudru

@ drudru- oui le numéro de séquence est là, j'ai peut-être besoin de me tamponner et de me désamorcer. Merci, éliminer une option de plus est toujours une bonne chose.
dashesy

64

Si un paquet TCP est perdu, il sera renvoyé. Ce n'est pas pratique pour les applications qui reposent sur le traitement des données dans un ordre spécifique en temps réel.

Les exemples incluent le streaming vidéo et en particulier la VoIP (par exemple Skype ). Dans ces cas, cependant, un paquet abandonné n'est pas si grave: nos sens ne sont pas parfaits, donc nous ne pouvons même pas le remarquer. C'est pourquoi ces types d'applications utilisent UDP au lieu de TCP.


16
Je pense que vous l'avez à l'envers. TCP réordonne les paquets afin que les données soient livrées dans l'ordre envoyé. UDP ne réordonne pas et livre les données dans l'ordre dans lequel elles les ont reçues.
Hans Malherbe

1
UDP ne garantit pas la commande, vous pouvez cependant numéroter les paquets et les réorganiser après les avoir récupérés.
Kugel

7
@ Stephan202: Je pense que je ne serais pas d'accord pour ne pas remarquer les paquets perdus dans Skype ;-)
Robert S. Barnes

6
@Kugel: Attention, vous pourriez implémenter une nouvelle pile TCP. Il est peu probable que vous fassiez un meilleur travail que le système d'exploitation.
erikkallen

1
@erikkallen: Si l'on utilisait UDP pour implémenter un protocole de niveau supérieur avec les mêmes exigences que TCP a été conçu pour satisfaire, il est peu probable que l'on fasse beaucoup mieux que les protocoles existants. D'un autre côté, certaines applications bénéficient de l'ajout de quelques fonctionnalités au protocole qu'un wrapper UDP pourrait mieux gérer que TCP.
supercat

56

Le "manque de fiabilité" de l'UDP est un formalisme. La transmission n'est pas absolument garantie. En pratique, ils réussissent presque toujours. Ils ne sont tout simplement pas reconnus et réessayés après un temps mort.

La surcharge de négociation d'un socket TCP et de négociation des paquets TCP est énorme. Vraiment énorme. Il n'y a pas de surcharge UDP appréciable.

Plus important encore, vous pouvez facilement compléter UDP avec une poignée de main fiable de livraison qui est moins lourde que TCP. Lisez ceci: http://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol

UDP est utile pour diffuser des informations dans une application de type publication-abonnement. IIRC, TIBCO fait un usage intensif de l'UDP pour la notification de changement d'état.

Tout autre type d'activité "d'événement significatif" ou de "journalisation" unidirectionnelle peut être bien géré avec les paquets UDP. Vous souhaitez envoyer une notification sans construire une socket entière. Vous n'attendez aucune réponse des différents auditeurs.

Les messages «rythme cardiaque» ou «Je suis vivant» du système sont également un bon choix. En manquer un n'est pas une crise. Il manque une demi-douzaine (d'affilée).


5
"En pratique, ils réussissent presque toujours". Dépend fortement de la fiabilité des couches réseau inférieures.
m0skit0

en outre, y a-t-il une différence entre la planification de "quelques" pertes de paquets et "trop" de pertes de paquets? la perte est la perte. vous devez tout de même le planifier.
Sedat Kapanoglu

30

Je travaille sur un produit qui prend en charge les communications UDP (IP) et TCP / IP entre le client et le serveur. Il a commencé avec IPX il y a plus de 15 ans et le support IP a été ajouté il y a 13 ans. Nous avons ajouté le support TCP / IP il y a 3 ou 4 ans. Devinette à venir: Le rapport de code UDP sur TCP est probablement d'environ 80/20. Le produit est un serveur de base de données, la fiabilité est donc essentielle. Nous devons gérer tous les problèmes imposés par UDP (perte de paquets, doublage de paquets, ordre des paquets, etc.) déjà mentionnés dans d'autres réponses. Il y a rarement des problèmes, mais ils surviennent parfois et doivent donc être traités. L'avantage de la prise en charge d'UDP est que nous sommes en mesure de le personnaliser un peu à notre propre usage et d'en modifier un peu plus les performances.

Chaque réseau va être différent, mais le protocole de communication UDP est généralement un peu plus rapide pour nous. Le lecteur sceptique se demandera à juste titre si nous avons tout mis en œuvre correctement. De plus, que pouvez-vous attendre d'un gars avec un représentant à 2 chiffres? Néanmoins, je viens de lancer un test par curiosité. Le test a lu 1 million d'enregistrements (sélectionnez * à partir de quelque chose). J'ai défini le nombre d'enregistrements à renvoyer avec chaque demande individuelle de client à 1, 10, puis 100 (trois cycles de test avec chaque protocole). Le serveur n'était qu'à deux sauts sur un LAN à 100 Mbits. Les chiffres semblaient correspondre à ce que d'autres ont trouvé dans le passé (l'UDP est environ 5% plus rapide dans la plupart des situations). Les temps totaux en millisecondes étaient les suivants pour ce test particulier:

  1. 1 enregistrement
    • IP: 390,760 ms
    • TCP: 416 903 ms
  2. 10 enregistrements
    • IP: 91 707 ms
    • TCP: 95 662 ms
  3. 100 enregistrements
    • IP: 29,664 ms
    • TCP: 30 968 ms

La quantité totale de données transmises était à peu près la même pour IP et TCP. Nous avons des frais supplémentaires avec les communications UDP parce que nous avons certains des mêmes choses que vous obtenez gratuitement avec TCP / IP (sommes de contrôle, numéros de séquence, etc.). Par exemple, Wireshark a montré qu'une demande pour le prochain ensemble d'enregistrements était de 80 octets avec UDP et 84 octets avec TCP.


Et si vous l'aviez développé pour TCP uniquement et achetiez un meilleur matériel au lieu de 5 fois plus d'efforts de codage?
inf3rno

2
Merci pour les chiffres concrets! L'amélioration de 5% est un peu décevante pour la complexité qu'elle ajoute.
Sergei

1
Probablement le 5% est parce qu'il est envoyé dans un réseau local (à deux espoirs)? Je suppose que plus c'est éloigné, plus la différence est grande.
lepe

19

Il y a déjà beaucoup de bonnes réponses ici, mais je voudrais ajouter un facteur très important ainsi qu'un résumé. UDP peut atteindre un débit beaucoup plus élevé avec un réglage correct car il n'utilise pas de contrôle de congestion . Le contrôle de la congestion dans TCP est très trèsimportant. Il contrôle le débit et le débit de la connexion afin de minimiser la congestion du réseau en essayant d'estimer la capacité actuelle de la connexion. Même lorsque des paquets sont envoyés sur des liaisons très fiables, comme dans le réseau principal, les routeurs ont des tampons de taille limitée. Ces tampons se remplissent à leur capacité et les paquets sont ensuite supprimés, et TCP remarque cette baisse par le manque d'accusé de réception reçu, ce qui limite la vitesse de la connexion à l'estimation de la capacité. TCP utilise également quelque chose appelé démarrage lent , mais le débit (en fait la fenêtre de congestion) est lentement augmentée jusqu'à ce que les paquets soient abandonnés, puis est abaissée et augmentée à nouveau lentement jusqu'à ce que les paquets soient supprimés, etc. Cela fait fluctuer le débit TCP. Vous pouvez le voir clairement lorsque vous téléchargez un gros fichier.

Parce que UDP n'utilise pas le contrôle de congestion, il peut être à la fois plus rapide et subir moins de retard car il ne cherchera pas à maximiser les tampons jusqu'au point de chute, c'est-à-dire que les paquets UDP passent moins de temps dans les tampons et y arrivent plus rapidement avec moins de retard. Parce que UDP n'utilise pas le contrôle de congestion, mais TCP le fait, il peut retirer la capacité de TCP qui cède aux flux UDP.

UDP est toujours vulnérable à la congestion et aux pertes de paquets, donc votre application doit être prête à gérer ces complications d'une manière ou d'une autre, probablement à l'aide de codes de retransmission ou de correction d'erreur.

Le résultat est que UDP peut:

  • Obtenez un débit supérieur à TCP tant que le taux d'abandon du réseau est dans les limites que l'application peut gérer.
  • Livrez des paquets plus rapidement que TCP avec moins de retard.
  • Configurez les connexions plus rapidement car il n'y a pas de prise de contact initiale pour configurer la connexion
  • Transmettez des paquets de multidiffusion, tandis que TCP doit utiliser plusieurs connexions.
  • Transmettez des paquets de taille fixe, tandis que TCP transmet des données en segments. Si vous transférez un paquet UDP de 300 octets, vous recevrez 300 octets à l'autre extrémité. Avec TCP, vous pouvez alimenter le socket d'envoi 300 octets, mais le récepteur ne lit que 100 octets, et vous devez comprendre en quelque sorte qu'il y a 200 octets de plus sur le chemin. Ceci est important si votre application transmet des messages de taille fixe, plutôt qu'un flux d'octets.

En résumé, UDP peut être utilisé pour chaque type d'application que TCP peut, tant que vous implémentez également un mécanisme de retransmission approprié. UDP peut être très rapide, a moins de retard, n'est pas affecté par la congestion sur une base de connexion, transmet des datagrammes de taille fixe et peut être utilisé pour la multidiffusion.


1
Lorsque les réseaux sont suffisamment encombrés pour provoquer une perte de paquets, TCP essaie de minimiser son impact sur les autres utilisateurs du réseau, contrairement à de nombreuses implémentations basées sur UDP. Cela leur permet de saisir une plus grande part d'une tarte décroissante, mais réduit également la quantité totale de bande passante utile disponible (par exemple, à la suite d'une retransmission inutile dans les cas où les données seraient effectivement livrées mais que l'expéditeur ne réaliserait pas)
supercat

Tout d'abord, merci pour la bonne réponse, j'en ai vraiment beaucoup appris! Mais j'ai une question: la segmentation ne se produit-elle pas sur la couche 3 (IP) en raison des limitations de l'adaptateur Ethernet pour tous les paquets reçus de la couche 4 (TCP et UDP)? Voulez-vous dire tout autre type de segmentation qui se produit dans TCP mais ne se produit pas dans UDP? J'apprécierais vraiment si vous pouviez m'expliquer.
RuslanSh

1
@Freezy. Vous avez raison, la fragmentation des paquets qui dépassent la MTU de la liaison (couche 2) se produit au niveau de la couche 3-IP. Cependant, TCP est un protocole basé sur un flux et il traite les données comme un flux d'octets. TCP envoie ses données en segments afin de tenir dans les paquets IP, qui sont dimensionnés en fonction du MSS, donc la segmentation se produit également dans TCP. La quantité de données que TCP place dans un segment, ou la quantité de données lues par votre socket, varie cependant en fonction de nombreux facteurs; il peut s'agir de 1 octet ou d'octets MSS. Avec UDP, le récepteur obtient toujours le nombre exact d'octets envoyés par l'émetteur, si le paquet n'est pas perdu en cours de route.
Andy

15

UDP a moins de frais généraux et est bon pour faire des choses comme le streaming de données en temps réel comme l'audio ou la vidéo, ou dans tous les cas où c'est correct si des données sont perdues.


15

UDP est un protocole sans connexion et est utilisé dans des protocoles comme SNMP et DNS dans lesquels les paquets de données arrivant dans le désordre sont acceptables et la transmission immédiate des paquets de données est importante.

Il est utilisé dans SNMP car la gestion du réseau doit souvent être effectuée lorsque le réseau est en situation de stress, c'est-à-dire lorsqu'il est difficile d'obtenir un transfert de données fiable et contrôlé par la congestion.

Il est utilisé dans DNS car il n'implique pas d'établissement de connexion, évitant ainsi les retards d'établissement de connexion.

à votre santé


12

L'une des meilleures réponses que je connaisse à cette question vient de l' utilisateur zAy0LfpBZLC8mAC de Hacker News . Cette réponse est si bonne que je vais la citer telle quelle.

TCP a un blocage de tête de file d'attente, car il garantit une livraison complète et dans l'ordre, donc quand un paquet est perdu en transit, il doit attendre une retransmission du paquet manquant, tandis qu'UDP livre des paquets à l'application dès leur arrivée , y compris les doublons et sans aucune garantie qu'un paquet arrive ou l'ordre dans lequel il arrive (c'est vraiment essentiellement IP avec des numéros de port et une somme de contrôle (facultative) de charge utile ajoutée), mais c'est très bien pour la téléphonie, par exemple, où il est généralement n'a tout simplement pas d'importance quand quelques millisecondes d'audio sont manquantes, mais le retard est très ennuyeux, donc ne vous embêtez pas avec les retransmissions, vous déposez simplement les doublons, triez les paquets réorganisés dans le bon ordre pendant quelques centaines de millisecondes de tampon de gigue , et si les paquets n'apparaissent pas à temps ou pas du tout, ils sont simplement ignorés,possible interpolé là où il est pris en charge par le codec.

En outre, une partie importante de TCP est le contrôle de flux, pour vous assurer d'obtenir le plus de débit possible, mais sans surcharger le réseau (ce qui est un peu redondant, car un réseau surchargé supprimera vos paquets, ce qui signifie que vous devrez faire retransmets, ce qui nuit au débit), UDP n'a rien de tout cela - ce qui est logique pour des applications comme la téléphonie, car la téléphonie avec un codec donné a besoin d'une certaine quantité de bande passante, vous ne pouvez pas le "ralentir" et une bande passante supplémentaire également ne fait pas passer l'appel plus vite.

En plus des applications en temps réel / à faible latence, UDP est logique pour les très petites transactions, telles que les recherches DNS, simplement parce qu'il n'a pas d'établissement de connexion TCP et de surcharge de démontage, à la fois en termes de latence et en termes d'utilisation de la bande passante. Si votre demande est plus petite qu'un MTU typique et que la répétition l'est probablement aussi, vous pouvez faire cela en un seul aller-retour, sans avoir besoin de garder un état sur le serveur, et de contrôler le flux de commande et tout ce qui n'est probablement pas particulièrement utile pour de telles utilisations non plus.

Et puis, vous pouvez utiliser UDP pour créer vos propres remplacements TCP, bien sûr, mais ce n'est probablement pas une bonne idée sans une compréhension approfondie de la dynamique du réseau, les algorithmes TCP modernes sont assez sophistiqués.

En outre, je suppose qu'il convient de mentionner qu'il existe plus que UDP et TCP, tels que SCTP et DCCP. Le seul problème actuellement est que l'Internet (IPv4) regorge de passerelles NAT qui rendent impossible l'utilisation de protocoles autres que UDP et TCP dans les applications d'utilisateur final.


Vous pouvez exécuter SCTP et DCCP sur UDP.
Demi

9

Le streaming vidéo est un parfait exemple d'utilisation de l'UDP.


Veuillez fournir quelques exemples.
Gaurav Singh

"Streaming vidéo" en est l'exemple. Considérez un match en direct diffusé sur hotstar.
Sisir

8

UDP a des frais généraux inférieurs, comme indiqué déjà, est bon pour diffuser des choses comme la vidéo et l'audio où il vaut mieux simplement perdre un paquet puis essayer de renvoyer et de rattraper son retard.

Il n'y a aucune garantie sur la livraison TCP, vous êtes simplement censé être informé si le socket est déconnecté ou, fondamentalement, si les données ne vont pas arriver. Sinon, il y arrive quand il y arrive.

Une grande chose que les gens oublient est que udp est basé sur des paquets et tcp est basé sur un flux de sortie, il n'y a aucune garantie que le "paquet tcp" que vous avez envoyé est le paquet qui apparaît à l'autre extrémité, il peut être disséqué en autant de paquets comme le désirent les routeurs et les piles. Votre logiciel a donc la surcharge supplémentaire de l'analyse des octets en morceaux utilisables, ce qui peut prendre une bonne quantité de surcharge. UDP peut être hors service, vous devez donc numéroter vos paquets ou utiliser un autre mécanisme pour les réorganiser si vous le souhaitez. Mais si vous obtenez ce paquet udp, il arrive avec tous les mêmes octets dans le même ordre qu'il a quitté, aucun changement. Le terme paquet udp a donc un sens, mais pas nécessairement le paquet tcp. TCP a son propre mécanisme de réessai et de commande qui est caché à votre application,

UDP est beaucoup plus facile à écrire du code aux deux extrémités, essentiellement parce que vous n'avez pas à établir et à maintenir les connexions point à point. Ma question est généralement où sont les situations où vous voudriez la surcharge TCP? Et si vous prenez des raccourcis comme en supposant qu'un "paquet" TCP reçu est le paquet complet qui a été envoyé, vous êtes mieux? (vous risquez de jeter deux paquets si vous prenez la peine de vérifier la longueur / le contenu)


TCP a une garantie de livraison: le bloc A sera livré à une application avant le bloc B, donc si une application reconnaît (au niveau de l'application) le bloc B, vous savez qu'il a obtenu le bloc A. Mais cela se produit également au niveau de la gestion TCP.
Simeon Pilgrim

Dans TCP, on peut délimiter en toute sécurité des blocs de données en préfixant simplement chaque bloc avec sa longueur. Selon l'application, on peut préfixer chaque bloc avec une longueur fixe d'un octet, de deux octets ou de quatre octets, ou on peut préfixer chaque bloc de taille 128 ^ N ou moins avec une longueur de N octets. Pas exactement un énorme frais généraux. Une telle conception serait mauvaise avec des protocoles qui ne garantissent pas une livraison dans l'ordre sans lacunes, mais lors de l'utilisation de TCP, une telle conception est très bien.
supercat

si vous recherchez des quantités de données de longueur fixe, vous n'avez même pas besoin de la longueur que vous venez de compter les octets à mesure qu'ils entrent ...
old_timer

1
@supercat. Tu as tout à fait raison. Cela signifie également que vous ajoutez de la complexité à votre application; complexité qui est réellement nécessaire dans UDP. Pour cette raison, TCP est préférable pour transférer des flux, tels que des fichiers. Mais je fais exactement ce que vous faites quand je veux la fiabilité des données fragmentées, et peut-être une sécurité supplémentaire de TLS sur TCP supérieur.
Andy

5

La communication réseau pour les jeux vidéo se fait presque toujours via UDP.

La vitesse est de la plus haute importance et peu importe si des mises à jour sont manquées car chaque mise à jour contient l'état actuel complet de ce que le joueur peut voir.


5
normal pas l'état complet du tout, mais un delta depuis le dernier accusé de réception, donc les mises à jour deviennent progressivement plus importantes.
Simeon Pilgrim

5

La question clé était liée à "quel genre de situations l'UDP serait-il le meilleur choix [par rapport à TCP]"

Il y a beaucoup de bonnes réponses ci-dessus, mais ce qui manque, c'est une évaluation formelle et objective de l'impact de l'incertitude de transport sur les performances TCP.

Avec la croissance massive des applications mobiles et les paradigmes "parfois connectés" ou "parfois déconnectés" qui les accompagnent, il y a certainement des situations où la surcharge des tentatives de TCP pour maintenir une connexion lorsque les connexions sont difficiles à obtenir conduit à une forte cas pour UDP et sa nature "orientée message".

Maintenant, je n'ai pas les mathématiques / recherches / chiffres à ce sujet, mais j'ai produit des applications qui ont fonctionné de manière plus fiable en utilisant et ACK / NAK et la numérotation des messages sur UDP que ce qui pourrait être obtenu avec TCP lorsque la connectivité était généralement mauvaise et pauvre ancien TCP vient de passer son temps et l'argent de mon client à essayer de se connecter. Vous obtenez cela dans les zones régionales et rurales de nombreux pays occidentaux ....


3

Dans certains cas, que d'autres ont mis en évidence, l'arrivée garantie des paquets n'est pas importante, et donc l'utilisation d'UDP est très bien. Il existe d'autres cas où UDP est préférable à TCP.

Un cas unique où vous voudriez utiliser UDP au lieu de TCP est celui où vous tunnelisez TCP sur un autre protocole (par exemple tunnels, réseaux virtuels, etc.). Si vous tunnelisez TCP sur TCP, les contrôles de congestion de chacun interfèrent les uns avec les autres. Par conséquent, on préfère généralement tunneler TCP sur UDP (ou un autre protocole sans état). Consultez l'article TechRepublic: Comprendre TCP sur TCP: effets du tunneling TCP sur le débit et la latence de bout en bout .


2

UDP peut être utilisé lorsqu'une application se soucie davantage des données "en temps réel" plutôt que de la réplication exacte des données. Par exemple, VOIP peut utiliser UDP et l'application s'inquiétera de réorganiser les paquets, mais en fin de compte, VOIP n'a pas besoin de chaque paquet, mais plus important encore, il a besoin d'un flux continu de beaucoup d'entre eux. Peut-être que vous avez ici un "problème" dans la qualité de la voix, mais le but principal est que vous obteniez le message et non qu'il soit parfaitement recréé de l'autre côté. UDP est également utilisé dans des situations où les frais de création d'une connexion et de synchronisation avec TCP l'emportent sur la charge utile. Les requêtes DNS en sont un parfait exemple. Un paquet en sortie, un paquet en arrière, par requête. Si vous utilisez TCP, cela serait beaucoup plus intensif. Si vous ne récupérez pas la réponse DNS, réessayez simplement.


2

UDP lorsque la vitesse est nécessaire et la précision si les paquets ne le sont pas, et TCP lorsque vous avez besoin de précision.

UDP est souvent plus difficile dans la mesure où vous devez écrire votre programme de telle manière qu'il ne dépende pas de la précision des paquets.


2

Ce n'est pas toujours clair. Cependant, si vous avez besoin d'une livraison garantie de paquets sans perte et dans la bonne séquence, TCP est probablement ce que vous voulez.

D'un autre côté, UDP est approprié pour transmettre de courts paquets d'informations lorsque la séquence des informations est moins importante ou lorsque les données peuvent tenir dans un seul paquet.

Il convient également lorsque vous souhaitez diffuser les mêmes informations à de nombreux utilisateurs.

D'autres fois, c'est approprié lorsque vous envoyez des données séquencées mais si certaines d'entre elles manquent, vous n'êtes pas trop inquiet (par exemple une application VOIP).

Certains protocoles sont plus complexes car ce qui est nécessaire, ce sont certaines (mais pas toutes) des fonctionnalités de TCP, mais plus que ce que fournit UDP. C'est là que la couche application doit implémenter les fonctionnalités supplémentaires. Dans ces cas, UDP est également approprié (par exemple, radio Internet, l'ordre est important mais tous les paquets n'ont pas besoin de passer).

Exemples où il est / pourrait être utilisé 1) Un serveur de temps diffusant l'heure correcte à un tas de machines sur un LAN. 2) Protocoles VOIP 3) Recherches DNS 4) Demande de services LAN, par exemple, où êtes-vous? 5) Radio Internet 6) et bien d'autres ...

Sous Unix, vous pouvez taper grep udp / etc / services pour obtenir une liste des protocoles UDP implémentés aujourd'hui ... il y en a des centaines.


2

Regardez la section 22.4 de la programmation réseau Unix de Steven , "Quand utiliser UDP au lieu de TCP".

Voir également cette autre réponse SO sur l'idée fausse selon laquelle UDP est toujours plus rapide que TCP .

Ce que dit Steven peut se résumer comme suit:

  • Utilisez UDP pour la diffusion et la multidiffusion, car c'est votre seule option (utilisez la multidiffusion pour toutes les nouvelles applications)
  • Vous pouvez utiliser UDP pour de simples applications de demande / réponse, mais vous devrez intégrer vos propres accusés de réception, délais d'expiration et retransmissions
  • N'utilisez pas UDP pour le transfert de données en masse.

1
Un peu plus d'informations sur ce dernier point, pour tous ceux qui viendront. TCP fonctionne pour le transfert de données en masse, mais si vous ne vous souciez pas que vos données arrivent dans un ordre de bout en bout, vous pouvez écrire un protocole sur UDP qui pourrait être plus rapide - beaucoup plus rapide dans des cas pathologiques très spécifiques. Ce n'est pas que vous ne pouvez pas faire de transfert en masse dans UDP, ce n'est pas que c'est toujours un moins bon interprète; c'est juste une telle douleur dans le cul à mettre en œuvre que ça vaut rarement la peine.
ijw

1
Oui, vous pouvez utiliser UDP pour le transfert en masse et vous devez implémenter votre propre mécanisme de contrôle. Si c'est une douleur dans le cul ou non dépend de vos compétences en programmation, mais ce n'est certainement pas toujours un moins bon interprète. Vous devez savoir ce que vous faites; si vous ne le faites pas, alors vous risquez de souffrir.
Andy

2

Nous savons que l'UDP est un protocole sans connexion, il est donc

  1. adapté aux processus qui nécessitent une communication simple demande-réponse.
  2. adapté au processus à flux interne, contrôle des erreurs
  3. adapté pour la diffusion large et la multidiffusion

Exemples spécifiques:

  • utilisé dans SNMP
  • utilisé pour certains protocoles de mise à jour de route tels que RIP

2

En comparant TCP avec UDP, des protocoles sans connexion comme UDP assurent la vitesse, mais pas la fiabilité de la transmission de paquets. Par exemple, dans les jeux vidéo, ils n'ont généralement pas besoin d'un réseau fiable, mais la vitesse est la plus importante et l'utilisation de l'UDP pour les jeux a l'avantage de réduire le retard du réseau.

entrez la description de l'image ici


1

Vous souhaitez utiliser UDP sur TCP dans les cas où la perte de certaines données en cours de route ne ruinera pas complètement les données transmises. Beaucoup de ses utilisations se font dans des applications en temps réel, telles que les jeux (par exemple, FPS, où vous n'avez pas toujours besoin de savoir où se trouve chaque joueur à un moment donné, et si vous perdez quelques paquets en cours de route, de nouveaux les données vous indiqueront correctement où se trouvent les lecteurs de toute façon) et le streaming vidéo en temps réel (une image corrompue ne ruinera pas l'expérience de visionnement).


Eh bien, une image corrompue va ruiner cette partie de la visualisation, mais vous ne voulez pas qu'elle bloque toutes les dernières images, en attendant, si les images ultérieures ont plus de valeur que l'image perdue.
Simeon Pilgrim

1

Nous avons un service Web qui a des milliers de clients Winforms sur autant de PC. Les PC n'ont pas de connexion avec le backend DB, tout l'accès se fait via le service web. Nous avons donc décidé de développer un serveur de journalisation central qui écoute sur un port UDP et tous les clients envoient un paquet de journal d'erreurs xml (à l'aide de l'appendeur UDP log4net) qui est transféré dans une table DB dès réception. Comme nous ne nous soucions pas vraiment si quelques journaux d'erreurs sont manqués et avec des milliers de clients, c'est rapide avec un service de journalisation dédié qui ne charge pas le service Web principal.


0

Je suis un peu réticent à suggérer UDP alors que TCP pourrait éventuellement fonctionner. Le problème est que si TCP ne fonctionne pas pour une raison quelconque, parce que la connexion est trop lente ou encombrée, il est peu probable que changer l'application pour utiliser UDP puisse aider. Une mauvaise connexion est également mauvaise pour UDP. TCP fait déjà un très bon travail pour minimiser la congestion.

Le seul cas où je peux penser où UDP est requis est pour les protocoles de diffusion. Dans les cas où une application implique deux hôtes connus, UDP n'offrira probablement que des avantages de performance marginaux pour des coûts considérablement accrus de complexité du code.


Une application dans laquelle vous obtiendrez de meilleurs résultats avec UDP est le test de mise en place, si un nœud intermédiaire effectue une régulation du trafic, car vous pouvez contrôler le débit des paquets plus facilement, verset TCP qui poussera les paquets rapidement et l'interaction du TCP le fenêtrage interagit négativement avec le maintien de l'ordre.
Simeon Pilgrim

Il s'agit toujours d'une optimisation, qui devrait découler des tests réels. Mon argument est que vous devez toujours essayer d'utiliser TCP en premier, et essayer uniquement des alternatives lorsque vous découvrez que TCP ne fonctionne pas pour une raison quelconque. Choisir UDP car il prend théoriquement en charge une meilleure utilisation de la bande passante est une forme d'optimisation prématurée.
SingleNegationElimination

Oh d'accord sur le front de l'optimisation. Mais savoir quand TCP peut être le problème ou quelque chose d'autre vous aide lorsque vous essayez de résoudre ce problème de performances.
Simeon Pilgrim

-1

N'utilisez UDP que si vous savez vraiment ce que vous faites. L'UDP est dans des cas extrêmement rares aujourd'hui, mais le nombre d'experts (même très expérimentés) qui essaieraient de le coller partout semble hors de proportion. Ils aiment peut-être eux-mêmes implémenter le code de gestion des erreurs et de maintenance des connexions.

TCP devrait être beaucoup plus rapide avec les cartes d'interface réseau modernes en raison de ce qu'on appelle l' empreinte de somme de contrôle . Étonnamment, à des vitesses de connexion rapides (telles que 1 Gbit / s), le calcul d'une somme de contrôle représenterait une charge importante pour un processeur.Il est donc déchargé sur le matériel NIC qui reconnaît les paquets TCP pour l'impression, et il ne vous offrira pas le même service.


2
Le déchargement de la somme de contrôle UDP est disponible tout comme le déchargement de la somme de contrôle TCP.
Ben Voigt

mais pas la validation de la somme de contrôle.
Pavel Radzivilovsky

1
Même les adaptateurs Ethernet grand public ont aujourd'hui un déchargement de somme de contrôle UDP pour la transmission et la réception (le déchargement de réception est en cours de validation). Et j'ai vu cette fonctionnalité dans le matériel prosommateur il y a une décennie, je suis sûr qu'elle se trouve dans les cartes réseau de classe serveur encore plus longtemps.
Ben Voigt

-2

UDP est parfait pour les adresses VoIP où les paquets de données doivent être envoyés, moins sa fiabilité ... Protocoles DNS et SNMP. UDP n'a pas de surcharge tandis que TCP a beaucoup de surcharge

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.