Un guide sur UDP (User Datagram Protocol)
Le protocole de datagramme utilisateur ressemble au « vilain petit canard » de Hans Christian Andersen. Après avoir été négligé et ridiculisé pendant des décennies, ce protocole simple a soudainement attiré des admirateurs en tant que protocole de transport pour les nouvelles applications multimédias glamour rendues possibles par les vitesses du haut débit. Aujourd'hui, toute application devant fournir rapidement des données choisit UDP plutôt que TCP (Transmission Control Protocol), auparavant dominant.
Historique UDP
UDP existe depuis presque aussi longtemps qu’Internet. Internet a vu le jour en mai 1974 lorsque l’Institute of Electrical and Electronics Engineers a publié « Un programme pour l'intercommunication des réseaux de paquets ' par Vint Cerf et Bob Khan . Le concept devait être développé et Khan et Cerf ont continué à affiner leurs idées tout en travaillant pour le gouvernement américain. Agence des Projets de Défense Avancée , également connu sous le nom de DARPA. Jean Postel s’est impliqué et a suggéré de scinder la structure unique proposée dans l’idée originale de Cerf et Khan. Cela a créé un concept à plusieurs niveaux. Le programme de contrôle de transmission original contenu dans les grandes lignes de 1974 a été divisé en protocole de contrôle de transmission à une couche supérieure et protocole Internet à une couche inférieure (d'où TCP/IP).
L’approche modulaire de Postel a pris tout son sens lorsque l’équipe a commencé à réfléchir à la mise en œuvre de la théorie. Il y avait une division claire du travail entre ce qui est devenu connu sous le nom de Couche de transport , qui est l'emplacement du protocole de contrôle de transmission, et le Couche Internet , où réside le protocole Internet. Cependant, Cerf et Khan ont envisagé la nécessité d'une option accélérée. Ils ont dressé un schéma de la manière dont les données seraient préparées pour la transmission en passant d'une couche à une autre. Les tâches de traitement étaient représentées par une ligne droite verticale, descendant à travers leur nouveau diagramme de pile montrant la progression depuis application vers TCP et vers IP .
Lorsqu’il s’agissait de tracer la voie rapide, ils ne voulaient pas avoir à tracer une ligne de détour courbe évitant de passer par TCP. Au lieu de cela, ils ont dessiné une forme oblongue représentant la couche Internet un peu plus large que le bloc représentant la couche transport. Avec cet ajustement visuel, l'itinéraire régulier et l'itinéraire rapide pourraient descendre à travers la pile sous forme de lignes parallèles. Cependant, cette astuce a laissé un vide que Postel estimait devoir combler. C'est pourquoi le protocole de datagramme utilisateur a été inventé. C'était juste là pour donner l'impression que le diagramme de la pile de protocoles était équilibré .
Les avantages du TCP
Le protocole de contrôle de transmission fournit des services essentiels aux données en transit. Il garantit que tous les paquets d’un flux arrivent réellement et vérifie qu’ils arrivent dans l’ordre. Ces procédures de contrôle qui garantissent un transfert ordonné ne sont pas possibles sans une mesure de coordination entre les deux parties. Ainsi, TCP établit d'abord un accord entre les deux appareils qui souhaitent échanger des données. Cet accord s'appelle une session . C’est aussi la définition même d’un « connexion .» UDP n'a pas de procédures d'établissement de session et est donc appelé « sans connexion .»
La session donne aux deux côtés de la connexion un numéro de référence qu'ils peuvent marquer sur leurs échanges administratifs. La séance permet également d'introduire la notion de ports. L'ID de session est en fait une combinaison d'identifiants contenus dans l'en-tête TCP . Avec cet ID, les concepteurs de procédures TCP ont pu avoir l’idée d’un « prise .» Les numéros de port sont également attribués à UDP, cependant, ce protocole ne peut utiliser que l'adresse IP de destination et les numéros de port comme identifiant unique. Un identifiant dérivé de cette combinaison bloquerait tous les autres processus tentant d'accéder au même port, même s'ils s'exécutaient sur des ordinateurs différents. UDP est devenu un système de livraison uniquement, sans aucune procédure permettant un dialogue bidirectionnel .
Les concepts de connexion TCP se sont tous développés en une méthode universelle très sophistiquée pour garantir que les données transmises entre les ordinateurs ne soient pas mélangées ou tronquées. Le socket permettait d'ouvrir simultanément plusieurs connexions entre les deux mêmes ordinateurs. . Cette idée a créé la possibilité d’avoir plus d’un canal opérationnel pour transmettre des données. Il s’agit d’une procédure fréquemment utilisée dont de nombreuses premières applications réseau ont profité. Le Protocole de transfer de fichier , par exemple, utilise deux canaux : un pour transmettre les données et un canal distinct pour les communications administratives. Les différents numéros de port pour les canaux de données et de contrôle créent deux sockets distincts.
L'ID unique de chaque session signifiait que TCP ajoutait de la valeur à la communication entre deux ordinateurs. À la fin des années 70 et au début des années 80, seules les grandes organisations et les établissements universitaires disposaient d’ordinateurs et de réseaux. Il était donc fort probable que deux organisations aient besoin que leurs gros ordinateurs centraux se connectent simultanément à des fins différentes. Tandis qu'un professeur envoyait un fichier à un collègue d'une autre université, un chercheur pourrait également souhaiter ouvrir une session Telnet sur l'ordinateur de la même université distante. Grâce à TCP, deux ordinateurs pourraient maintenir plusieurs connexions simultanément et chacune de ces sessions pourrait exploiter plusieurs canaux en même temps . Ces connexions simultanées ne seraient pas possibles si les communications étaient uniquement régies par le protocole Internet avec l'attribution d'une adresse IP par ordinateur. UDP, sans aucun mécanisme de session, était incapable de gérer les applications nécessitant qu'un ordinateur contacté envoie une réponse .
Sécurité des données
Les constructions brillantes de TCP ont rendu possibles les connexions entre les réseaux et Internet a commencé à s’étendre au-delà du monde universitaire pour atteindre le monde des affaires. La création du World Wide Web , qui est devenu public en 1991, n'a été possible que grâce à la facilité avec laquelle la page Web contenant le protocole HTTP (Hypertext Transfer Protocol) pouvait s'asseoir au-dessus de TCP.
Les universitaires et les techniciens qui ont créé Internet puis développé le World Wide Web accessible au public étaient penseurs du ciel bleu . Ils étaient enthousiasmés par la technologie et ses possibilités d’accélérer la recherche et d’améliorer l’interaction entre les personnes du monde entier. Ils n’ont pas tenu compte du fait que leur merveilleuse invention était un cadeau pour les voleurs, les escrocs et les terroristes urbains. . Ni Internet ni le World Wide Web n’avaient la moindre sécurité.
Il a fallu une approche dirigée par le consommateur Société Netscape pour repérer ce problème. Netscape a produit le premier navigateur Web au monde et l'a offert gratuitement pour encourager l'adoption d'Internet auprès du grand public. Le plan a fonctionné et les échanges d'informations et les canaux de contact se sont étendus, encourageant davantage de membres du public à s'inscrire aux services Internet. Cependant, le le manque de sécurité constituait un obstacle à la commercialisation du Web . Sans la capacité d’inciter les gens à payer pour les services en ligne, rien n’incitait les entreprises à investir dans le développement de nouvelles applications, sites Web ou services en ligne.
Le principal obstacle à la collecte de paiements sur le Web était son manque de sécurité. Quelques gros titres sur le vol de données sur les transmissions Internet ont mis fin à la possibilité de rendre Internet commercialement viable. Cependant, Netscape a proposé HTTPS – une version sécurisée de HTTP qui protégeait la transmission . L'emplacement idéal dans la pile TCP/IP pour ces procédures de sécurité se trouvait lors des processus d'établissement de session de TCP. Donc, TCP est devenu encore plus essentiel aux opérations d'Internet et il semblait encore plus probable qu'UDP ne serait jamais utilisé.
UDP prend son envol
Bien qu'il existe depuis 1980, UDP a été complètement négligé jusqu'à ce que les services Internet à haut débit soient disponibles au début de ce siècle. Le protocole de datagramme utilisateur a été largement ignoré tandis que les applications Web et autres applications Internet développaient les fonctionnalités de TCP.
Cependant, la possibilité d'avoir des conversations vocales et des vidéoconférences sur Internet a toujours séduit les entreprises . Ces applications existaient avant le haut débit, mais uniquement pour être utilisées sur des réseaux privés plus rapides. Avec la technologie de transmission du son et de la vidéo sur les réseaux établie , les vitesses plus rapides du haut débit ont offert la possibilité de rendre ces applications accessibles au grand public est devenu une idée réalisable. Cependant, les vitesses disponibles sur Internet n’étaient pas assez bonnes.
La solution immédiate pour obtenir juste assez de vitesse supplémentaire sur Internet était d'abandonner toutes les procédures administratives de TCP et tournez-vous vers l'UDP presque oublié .
Les problèmes avec TCP
Les applications interactives préféreraient traiter elles-mêmes certains des problèmes rencontrés lors de la transmission. L'une des principales fonctionnalités de TCP dont ces applications ne veulent vraiment pas est mise en mémoire tampon .
TCP s'assure que les paquets arrivent dans l'ordre. Si un paquet est absent du flux, l'implémentation TCP réceptrice enverra une demande au programme TCP expéditeur pour renvoyer ce paquet spécifique . En attendant, ce paquet pourrait arriver en retard. TCP utilise un système de trame glissante pour traiter les paquets arrivant et si un segment est en retard ou perdu, cette diapositive est bloquée. Le stockage temporaire d'un certain nombre d'images en mémoire est ce qu'on appelle la mise en mémoire tampon. . TCP attend de pouvoir remplir l'emplacement vide avec le paquet portant le numéro de séquence manquant. Dans le cas de la téléphonie Internet, une telle action entraînerait le silence de la ligne. En streaming vidéo, l'attente d'un paquet manquant ferait geler le lecteur vidéo.
Les applications interactives n'ont pas de procédures pour contourner la mise en mémoire tampon TCP . Le principe derrière les couches de pile est que les couches supérieures demandent un service et laissent à la couche inférieure le soin de le fournir. Il n’y a pas de signal « continuez » qu’une application peut envoyer à la couche transport.
Si un paquet est perdu au cours d'une conversation téléphonique numérique, les appelants subiront un court silence, mais l'application des deux côtés continuera simplement à envoyer et à recevoir les paquets suivants. Au moment où un paquet manquant pourrait être récupéré, la conversation interactive aurait déjà progressé, il ne sert donc à rien d'essayer de le réinjecter dans le flux. ; il vaut simplement mieux amortir la perte et continuer. De même, un paquet perdu signifierait simplement un court saut dans un flux vidéo en direct et les téléspectateurs préféreraient de loin que la vidéo continue d'avancer plutôt que de retarder l'intrigue pendant une milliseconde d'images.
Vous avez probablement vu un lecteur vidéo s'arrêter et superposer le message « mise en mémoire tampon » sur la photo. Il existe généralement également un compteur qui indique le pourcentage de mise en mémoire tampon terminée. Cette mise en mémoire tampon se produit si la vitesse de transfert de la connexion est inférieure à la fréquence d’images de la lecture vidéo. Le point crucial de ce message, cependant, est qu'il montre que la mise en mémoire tampon est gérée par le lecteur et non par le protocole de transport.
Protocoles de partenariat
Même si les applications interactives ne voulaient pas des retards causés par TCP, elles voulaient certaines fonctionnalités de ce protocole. Ils voulaient plus que ce que l'UDP pouvait offrir. D’autres protocoles ont donc été inventés pour compléter une partie des capacités de TCP.
Le protocole d'initiation de session
Le protocole d'initiation de session (SIP) a été inventé pour les applications de voix sur IP (VoIP). La téléphonie Internet ne voulait pas de la mise en mémoire tampon de TCP, mais elle devait imiter les procédures traditionnelles d'établissement d'appel des téléphones. – composer, sonner, être occupé, décrocher et mettre fin à l'appel. Cependant, SIP ne gère pas l’intégralité de la session, il s’occupe simplement des fonctions de création et de suppression de connexion de TCP. Chaque appel transitant sur Internet utilise SIP. À tel point que « SIP » est presque devenu un terme interchangeable avec « VoIP .»
L’acheminement massif du trafic vocal sur des connexions numériques à haut débit est connu sous le nom de « Jonction SIP .» Transférer un appel depuis Internet vers un téléphone fixe ordinaire s’appelle « Résiliation SIP .» L'industrie de la téléphonie numérique utilise SIP pour identifier sa technologie, mais le fondement même de toutes ses activités est UDP.
Le protocole de transport en temps réel
Malgré la décision selon laquelle TCP représentait une surcharge trop importante sur le trafic interactif et devait être abandonné, les ingénieurs en communication revenaient sans cesse aux installations fournies par TCP et ils souhaitaient pouvoir les avoir avec UDP. Le protocole de transport en temps réel (RTP) compense en grande partie le manque de fonctionnalités rencontré lors de l'utilisation d'UDP.
Une caractéristique clé de ces protocoles complémentaires qui rendent UDP pertinent pour le streaming multimédia est qu'ils permettent à certains des processus traditionnellement gérés par TCP d'être transmis à l'application. RTP gère certaines fonctions de gestion du trafic de TCP, mais pas toutes. .
RTP est capable de réorganiser les paquets hors séquence et de noter les paquets perdus. Cependant, la fonction de séquençage n'a pas besoin d'être implémentée et est impossible à implémenter sans mise en mémoire tampon au niveau de la couche transport.
Le protocole de contrôle RTP
RTP s'associe toujours à RTCP , qui est le protocole de contrôle RTP. RTPC émule certaines des fonctions de gestion de session de TCP, sauf que le principe directeur du protocole est de ne pas s'immiscer dans le flux et de ne pas ralentir la transmission multimédia ; ses activités sont donc peu fréquentes. Le protocole collectera des données de performances, y compris la perte de paquets , et informations sur le taux de transfert . Le lecteur récepteur peut utiliser ces informations pour décider s'il souhaite passer à une résolution vidéo inférieure ou à une norme de codage vidéo différente.
Si vous utilisez une application vidéo et audio, il est presque certain que RTP et RTCP sont impliqués. Il y a un ' entrelacement » dans la définition de RTSP (voir ci-dessous) qui déplacerait les transmissions RTP vers TCP. Il s’agit cependant d’une proposition inhabituelle qui n’a jamais été mise en œuvre au-delà du laboratoire. Sans cette spécification, toutes les activités RTP et RTCP sont portées par UDP.
Le protocole de streaming en temps réel
Le protocole RTSP (Real Time Streaming Protocol) est presque toujours impliqué dans les applications de lecture ou d'enregistrement vidéo et audio. Ce protocole fournit des boutons de contrôle sur votre lecteur et enregistreur . Ce sont Pause, Enregistrement/Lecture, Avance rapide et Retour. Curieusement, bien que RTSP puisse fonctionner sur UDP, il est généralement transporté via TCP, même s'il est associé à un flux vidéo ou audio pris en charge par UDP.
Applications UDP uniquement
Un certain nombre d'applications réseau légères utilisent UDP sans aucun autre protocole constituant une simulation des fonctions TCP. Ces fonctions sont quasi exclusivement destinées à être utilisées uniquement sur les réseaux privés car ils n’incluent aucune procédure d’authentification ni de cryptage de transmission.
Si vous gérez un réseau, vous connaîtrez Protocole de temps réseau (NTP) , le Système de noms de domaine (DNS) , le Protocole de configuration dynamique d'hôte (DHCP) , et le Protocole de transfert de fichiers trivial (TFTP) . Tous ces services d'administration fonctionnent sur UDP. Au-delà de ces applications de réseau privé, il est très difficile de trouver une application fonctionnant uniquement via UDP.
UDP contre TCP
Une comparaison de la structure d'en-tête UDP et de la structure d'en-tête TCP vous montre les limites d'UDP.
L'en-tête UDP ne comporte que quatre champs. De ces quatre, le Port source Le champ est facultatif et peut rester vide. En IPv4, le Somme de contrôle Le champ est également facultatif, bien qu'il soit obligatoire pour les implémentations IPv6. Cela signifie que dans le cas des transmissions IPv4, l'en-tête UDP ne doit contenir que deux informations.
L'en-tête TCP est capable de contenir beaucoup plus d'informations.
Comme vous pouvez le voir sur l'illustration, l'en-tête du paquet TCP comporte une série de neuf indicateurs qui adaptent la signification de l'en-tête. Cet événement possède un champ « urgent ». Cela donne au système TCP beaucoup plus de flexibilité qu'UDP et montre que beaucoup plus de temps a été investi dans les procédures pour TCP et la structure de son en-tête de paquet que dans le développement d'UDP.
Le fait que l'en-tête TCP doive inclure le port source permet de créer un socket plus unique, en créant un identifiant de session à partir des adresses IP source et de destination et des numéros de port source et destination. Avec UDP, comme il ne dispose pas de procédures pour créer une session, chaque message est traité comme une tâche terminée , et le protocole ne tente pas de regrouper les paquets. Par conséquent, les applications qui utilisent USP doivent gérer elles-mêmes cette continuité.
Sécurité pour UDP
Les méthodes TCP orientées connexion rendent la sécurité beaucoup plus facile à mettre en œuvre dans ce protocole en UDP. Cependant, il existe des normes de chiffrement pour UDP. La principale option qui vise directement la sécurité UDP est la Sécurité de la couche de transport des datagrammes protocole ou DTLS.
Heureusement, DTLS est disponible dans un certain nombre de bibliothèques open source gratuites , vous n'avez donc pas besoin de parcourir la définition du protocole et d'écrire votre programme ouvert pour l'implémenter. OuvertSSL , qui est une bibliothèque de code open source, est la source la plus courante pour une implémentation de Transport Layer Security, qui est le système de sécurité le plus largement implémenté pour TCP. Cette bibliothèque également inclut une implémentation DTLS , vous devriez donc pouvoir rencontrer des options UDP sécurisées dans les mêmes applications qui offrent des connexions TCP sécurisées.
Une autre option pour les utilisateurs UDP consiste à s'appuyer sur un système de sécurité conçu pour fonctionner au niveau de la couche Internet. C'est IPSec , ou sécurité du protocole Internet. Comme IPSec fonctionne sous la couche transport, il n'est pas capable de fonctionner avec les ports et le fait qu'UDP ne soit pas capable de maintenir une session n'a pas d'importance lorsque IPSec est activé. – Les protocoles de couche IP ne peuvent pas non plus créer de sessions . En tant que système de couche inférieure , IPSec est capable de prendre en charge n'importe quel protocole de couche de transport, y compris UDP .
IPSec inclut des méthodes d'authentification et crypte également les paquets pour les protéger des écoutes téléphoniques. L’informatique offre autant de sécurité que le populaire TLS, mais est moins largement mise en œuvre. IPSec utilise le système Internet Key Exchange (IKEv2) pour configurer l'authentification, donc très souvent, IPSec est facturé comme IKEv2. La méthodologie IKEv2 utilise Procédures d'échange de clés Diffie-Hellman , qui est exactement le même système que celui utilisé par TLS pour la méthodologie de session de page Web sécurisée HTTPS.
Kerberos et le Négociation Internet Kerberisée des clés (KINK) sont deux éléments d'un système de sécurité généralement appelé Kerberos. Les procédures d'établissement de session Kerberos utilisent un système de « tickets » similaire à la méthode TLS d'utilisation de « certificats ». Tout en bas de la pile, Kerberos s'appuie sur IPSec. La couche Kerberos éponyme se trouve au-dessus d'UDP et utilise des sockets UDP pour faciliter la communication. Il s'agit donc d'un système de sécurité compatible UDP. Une fonctionnalité intéressante de Kerberos est qu'il vous permet d'utiliser le cryptage AES pour protéger vos transferts UDP. . AES est probablement le chiffrement le plus sécurisé couramment utilisé aujourd’hui et c’est la méthode de sécurité recommandée pour les meilleurs systèmes de protection de la vie privée VPN au monde.
Malgré les difficultés apparentes de négociation des clés de chiffrement dans un environnement qui ne propose aucune gestion des connexions, UDP propose néanmoins des options de sécurité. Ainsi, lorsque vous implémentez une application basée sur UDP, n’abandonnez pas la tâche de sécuriser vos transmissions.
L'avenir de l'UDP
Les applications purement basées sur UDP qui n’impliquent pas de protocoles secondaires pour imiter TCP sont rares et risquent de le devenir encore plus. Les utilitaires réseau légers qui utilisent UDP prospèrent sur des réseaux locaux sécurisés. Cependant, alors que les menaces de sécurité liées aux nouvelles attaques Zero Day augmentent chaque semaine, l'idée de disposer de protocoles non sécurisés gérant les services cruciaux de gestion de la configuration et d'adressage semble bêtement complaisante.
À mesure que les réseaux migrent leurs services vers le cloud, les services TFTP et DHCP basés sur UDP commenceront à être remplacés par des alternatives plus sécurisées. . La solution simple consistant à surfer sur les applications via HTTPS pour leur assurer la sécurité sans effort de programmation supplémentaire fait pencher l'avenir vers TCP, qui transporte HTTPS et supprime les opportunités de la liste de compétences UDP.
Le créneau UDP de prise en charge des transmissions multimédias est susceptible de perdurer. De nombreux systèmes de transport concurrents ont déjà été proposés pour le support d'applications interactives, mais aucun d'entre eux n'a fait perdre à UDP sa position de premier choix pour la VoIP et le streaming vidéo. Cette liste de rivaux comprend :
Le protocole de datagramme utilisateur fiable (RUDP), qui a des implémentations Cisco et Microsoft.
Le protocole de transmission de contrôle de flux (SCTP) , qui a été proposé sans succès en remplacement du combo UDP/RTP/RTCP, mais n'a jamais vraiment décollé.
Ce vilain petit canard appelé UDP s'est révélé être un cygne, grâce aux pouvoirs de transformation magiques du haut débit et des applications interactives. Cette étoile revitalisée continuera de planer sans effort sur les eaux d’Internet.
Quels modes de transmission utilisez-vous ? Voyez-vous le vilain petit canard UDP comme un cygne ? Écrivez sur vos expériences dans la section Commentaires ci-dessous.
FAQ sur le protocole de datagramme utilisateur
A quoi sert le protocole UDP ?
Le protocole de datagramme utilisateur (UDP) crée des communications sans connexion. Il s'agit d'un protocole léger de couche de transport utilisé pour les systèmes interactifs, tels que les jeux en ligne, la VoIP et le streaming vidéo.
Quelle est la différence entre UDP et TCP ?
Le Transmission Control Protocol (TCP) est le principal protocole de couche transport de la pile TCP/IP. Il fournit des services de gestion de session, tels que garantir que les paquets perdus sont renvoyés et mettre en mémoire tampon les paquets arrivant pour s'assurer qu'ils sont dans le bon ordre. Le protocole UDP (User Datagram Protocol) ne fait rien de tout cela – il peut être compris comme « non TCP ». TCP est appelé protocole orienté connexion et UDP est appelé protocole sans connexion.
Quel est le principal avantage d’UDP ?
Le protocole UDP (User Datagram Protocol) ne fait presque rien. Son avantage par rapport au Transmission Control Protocol (TCP) est que son manque d'activité offre aux applications les vitesses de transfert les plus rapides possibles. Les applications interactives, telles que la VoIP, la vidéoconférence et les jeux en ligne, n'ont pas le temps de s'occuper des fonctionnalités de gestion de session de TCP. Si un paquet est perdu, personne ne s’en soucie : il s’agit d’un intervalle d’une milliseconde dans une conversation en direct que personne ne remarquera. Les utilisateurs remarqueraient si le flux audio était retenu pendant quelques secondes afin qu'un paquet perdu puisse être identifié et retransmis.
En rapport:
Guide ultime de TCP/IP
Qu’est-ce que TCPdump ?
Examen du serveur TFTP SolarWinds
Examen du serveur TFTPD32 TFTP
Images:
En-tête de UDP par Devarshi à Wikilivres anglais Autorisé sous CC BY-SA 2.5
Disposition des paquets TCP avec échelle de bits par Guliyevferman via Wikimédia Commons . Autorisé sous CC BY-SA 4.0