UDP fait-il quoi que ce soit?
Je crois comprendre que TCP a une logique pour assurer une communication fiable, mais UDP envoie naïvement des informations le long du canal configuré pour lui en utilisant IP et des éléments dans les couches inférieures.
UDP fait-il réellement quelque chose? Je suis un peu confus par la raison pour laquelle il a même un nom.
Réponses
Point de vue et question intéressantes!
Oui, la plupart de ce que UDP n'est fournir un moyen standard pour de multiples applications à coexister en utilisant la même adresse IP, en définissant le concept de ports UDP .
La partie passionnante d'UDP n'est pas tant le protocole réseau que l'API implémentée par les systèmes d'exploitation et les bibliothèques de sockets. Bien qu'elle ne fasse pas partie des spécifications UDP elles-mêmes, la possibilité d'utiliser des abstractions telles que l'API de socket POSIX pour développer facilement des logiciels sur des protocoles tels que UDP est la clé du succès de la pile de protocole Internet.
UDP est un protocole de transport, comme TCP. Cela signifie qu'il fournit un protocole permettant à une application d'utiliser IP. Comme TCP, UDP a un adressage (ports) auquel les applications se lient afin que les datagrammes destinés aux applications liées soient envoyés par UDP aux applications appropriées. UDP pour IPv4 fournit également une somme de contrôle facultative, mais la somme de contrôle est requise pour IPv6.
UDP est un protocole basé sur les messages, où TCP est un protocole basé sur les flux. UDP peut être utile pour les protocoles de couche application pour fournir certaines fonctionnalités de TCP, mais pas toutes, et de nombreuses applications ou protocoles de couche application ne peuvent pas utiliser, ou sont même endommagés par, la fiabilité de TCP. Par exemple, les protocoles en temps réel, tels que la VoIP, la vidéo ou même les jeux, ne peuvent pas utiliser les datagrammes perdus une fois qu'ils ne sont plus utiles, donc le fait de renvoyer les données par TCP aurait un mauvais résultat. Lorsque vous utilisez la VoIP et que l'autre personne répond, vous voulez entendre «Bonjour», pas «Oh, diable».
D'autres choses, telles que la multidiffusion, sont unidirectionnelles, mais TCP nécessite la mise en place d'une connexion bidirectionnelle entre deux applications, tandis qu'une application de multidiffusion envoie des données à de nombreux récepteurs. TCP ne peut pas vraiment faire cela, mais il est facile d'utiliser UDP avec la multidiffusion.
Je vous encourage à regarder comment les protocoles de niveau supérieur qui utilisent UDP l'utilisent réellement. Les exemples classiques et bien documentés sont le DNS (dans la plupart des cas au moins, il est possible de faire du DNS sur TCP mais c'est vraiment rare), DHCP, NTP et PTP.
Tous ces protocoles ont des points communs:
- Ils se soucient de pouvoir coexister avec d'autres services sur le même système.
- Ils se soucient d'un certain degré d'intégrité des données de leurs messages.
- Ils sont orientés message , pas orientés flux .
- Ils impliquent principalement des échanges de données très courts et souvent peu fréquents.
Les deux premiers points sont trivialement couverts par tout protocole de couche de transport raisonnable (même des choses exotiques comme TIPC), y compris TCP. Cependant, TCP est horrible pour les deux autres points, car il vous oblige à rouler votre propre protocole de tramage de messages au-dessus de ses flux pour les protocoles orientés message et la surcharge importante de démarrage et de maintenance de la connexion signifie qu'il est très inefficace pour de courts échanges de données peu fréquents. .
En d'autres termes, la `` caractéristique '' d'UDP qui vaut la peine de s'inquiéter est qu'elle fournit le strict minimum pour ces deux premiers points sans vous gêner comme TCP le fait pour ces types d'applications. Il a également un petit avantage par rapport à TCP en ce sens qu'il est trivialà implémenter soit purement matériel, soit sur un système minuscule avec moins de 1 Ko de RAM et une quantité minuscule d'espace de stockage pour le code (c'est en partie pourquoi BOOTP, RARP, TFTP et d'autres protocoles d'amorçage l'ont utilisé à l'origine). L'inconvénient est la fiabilité et la sensibilité à certains types d'attaques si vous utilisez des `` connexions '' avec état de longue durée sans une gestion très minutieuse, mais les protocoles qui l'utilisent et s'en soucient le gèrent eux-mêmes (voir TFTP pour un exemple de gestion du problème de fiabilité, mais au détriment de la vitesse).
Maintenant, il existe des options qui peuvent atteindre des ensembles de fonctionnalités similaires (ou même des ensembles de fonctionnalités plus complets) à TCP avec beaucoup moins de frais généraux et permettant toujours une communication orientée message (les principaux exemples incluent RUDP, DCCP et SCTP), ils ne l'ont tout simplement pas vraiment attrapé pour une combinaison de raisons, donc UDP reste juste un peu partout.
Il y a un point important qu'UDP ne nécessite pas la mise en place d'une "connexion" .
Par exemple, il serait difficile et complexe, voire impossible, d'implémenter DHCP sur TCP, où un client n'a aucune adresse IP et aucune connaissance de l'environnement réseau existant. Il est donc inutile de «configurer une connexion», car le client ne connaît pas l'adresse cible et n'a pas d'adresse source. UDP rend cela facile en permettant une diffusion d'une requête DHCP sur le réseau existant, et un (et, espérons-le, un seul) serveur DHCP répondra avec une offre.
De même, la plupart des actions de diffusion réseau n'ont pas beaucoup de sens avec TCP *, car vous ne pouvez pas avoir de «connexion» avec une «cible de diffusion» où chaque hôte accepte et répond. Des choses comme les numéros de séquence et les sommes de contrôle ne s'additionnent pas.
* Nous ne parlons pas de trucs comme MPI_Bcast(). Ils sont vraiment hors de portée de cette question.
Pour moi, la chose clé qu'UDP fait est de fournir à la fois les numéros de port source et de destination et donc d'autoriser non seulement plusieurs protocoles d'application différents, mais également plusieurs instances du même protocole d'application.
En principe, vous pouvez créer votre protocole d'application directement sur IP et obtenir un numéro de protocole pour celui-ci. Cela fonctionne bien si vous n'avez qu'une seule instance de votre protocole d'application sur chaque hôte, mais cela ne fonctionne pas très bien si vous souhaitez avoir plusieurs instances du même protocole d'application sur chaque hôte.
En ayant des numéros de port source et de destination séparés et en établissant les conventions selon lesquelles les clients utilisent des ports éphémères tandis que les serveurs utilisent des ports bien connus et que les réponses permutent les numéros de port, UDP prend en charge plusieurs instances du même protocole d'application sur le même hôte.
Il offre des services de multiplexage / démultiplexage aux couches supérieures (App) afin de pouvoir gérer les données de différents processus. Avec la somme de contrôle, il vous apportera également une détection d'erreur.
UDP, étant un protocole si simple, est utile pour les protocoles de couche supérieure qui préfèrent une communication rapide, sans qu'il soit nécessaire d'établir une connexion ou un transfert de données fiable.
En plus de cela, certains protocoles tels que DNS, utilisent UDP à leurs fins ...
Je pense qu'il est important de noter que DHCP repose à 100% sur UDP et qu'il est extrêmement largement utilisé.
De plus, DNS utilisait historiquement UDP, et n'utilise TCP que lorsque la réponse est trop grande pour un paquet UDP.