4.4 - UDP

Le protocole UDP (User Datagram Protocol) est un protocole de transport d’acheminement au mieux, décrit dans le document RFC 768. Le protocole UDP est un protocole de transport léger qui offre les mêmes fonctions de segmentation et de réorganisation des données que le protocole TCP, mais sans la fiabilité et le contrôle de flux du protocole TCP.

Caractéristiques du protocole UDP

Sans connexion – le protocole UDP n’établit pas de connexion entre les hôtes avant que les données puissent être envoyées et reçues.
Acheminement non fiable – le protocole UDP ne fournit pas de services garantissant que les données sont acheminées de façon fiable. Il n’existe pas de processus dans le protocole UDP permettant de faire retransmettre à l’expéditeur les données perdues ou endommagées.
Aucune reconstitution ordonnée des données – parfois, les données sont reçues dans un ordre différent de celui dans lequel elles ont été envoyées. Le protocole UDP n’offre aucun mécanisme permettant de réorganiser les données dans leur ordre initial. Les données sont simplement remises à l’application dans l’ordre où elles arrivent.
Aucun contrôle de flux – le protocole UDP ne propose aucun service permettant de contrôler la quantité de données envoyées par la source pour éviter de submerger le périphérique de destination. La source envoie les données. Si les ressources sur l’hôte de destination sont surexploitées, l’hôte de destination abandonne généralement les données envoyées jusqu’à ce que des ressources soient disponibles. Contrairement au protocole TCP, le protocole UDP ne fournit aucun mécanisme permettant de retransmettre automatiquement les données abandonnées.

Segment UDP

Bien que le protocole UDP n’inclue pas les mécanismes de fiabilité et de contrôle de flux du protocole TCP, comme l’illustre la figure, la faible surcharge pour l’acheminement des données du protocole UDP fait de ce dernier un protocole de transport idéal pour les applications qui peuvent tolérer certaines pertes de données. Les blocs de communications utilisés dans le protocole UDP sont appelés des datagrammes. Ces datagrammes sont envoyés « au mieux » par le protocole de couche transport. Le système de noms de domaine (DNS), la transmission vidéo en continu et la voix sur IP (VoIP) comptent parmi les applications utilisant le protocole UDP.

L’une des conditions les plus importantes pour fournir une vidéo en direct et faire transiter des données vocales sur un réseau est que le flux de données soit rapide. Les applications vidéo et de communication vocale peuvent tolérer certaines pertes de données, qui ont un impact faible ou nul, et sont donc parfaitement adaptées au protocole UDP.

UDP est un protocole sans état, c’est-à-dire que ni le client ni le serveur ne sont tenus de surveiller l’état de la session de communication. Comme l’illustre la figure, le protocole UDP n’est pas concerné par la fiabilité et le contrôle de flux. Les données peuvent être perdues ou reçues dans le désordre sans qu’aucun mécanisme UDP ne puisse récupérer ou réorganiser les données. Si la fiabilité est nécessaire dans le cadre de l’utilisation d’UDP comme protocole de transport, elle doit être prise en charge par l’application.

Communication UDP

Faible surcharge et fiabilité

Le protocole UDP est un protocole simple offrant des fonctions de couche transport de base. Il crée beaucoup moins de surcharge que le protocole TCP car il n’est pas orienté connexion et ne propose pas de mécanismes sophistiqués de fiabilité (retransmission, séquençage et contrôle de flux).

Cela ne signifie pas que les applications utilisant le protocole UDP ne sont jamais fiables, ni que le protocole UDP n’est pas efficace. Cela signifie simplement que ces fonctions ne sont pas fournies par le protocole de couche transport et qu’elles doivent être implémentées à un autre niveau, le cas échéant.

Bien que le volume total de trafic UDP d’un réseau standard soit relativement faible, des protocoles importants de couche application utilisent le protocole UDP, notamment :

Système de noms de domaine (DNS)
SNMP (Simple Network Management Protocol)
Protocole DHCP (Dynamic Host Configuration Protocol)
Protocole RIP (Routing Information Protocol)
TFTP (Trivial File Transfer Protocol)
Téléphonie IP ou voix sur IP (VoIP)
Jeux en ligne

Certaines applications, comme les jeux en ligne ou la VoIP, peuvent tolérer la perte d’une certaine quantité de données. Si ces applications utilisaient le protocole TCP, elles risqueraient d’être confrontées à des retards importants lorsque le protocole TCP détecterait les pertes de données et retransmettrait les données. Ces délais seraient plus préjudiciables à l’application que la perte d’une petite quantité de données. Certaines applications, comme le système DNS, renvoient simplement la requête si aucune réponse n’est reçue. Par conséquent, elles n’ont pas besoin du protocole TCP pour garantir l’acheminement des messages.

La faible surcharge qu’engendre le protocole UDP rend celui-ci très intéressant pour de telles applications.

Réassemblage datagrammes UDP

Comme le protocole UDP n’est pas orienté connexion, les sessions ne sont pas établies avant que la communication n’ait lieu comme c’est le cas avec le protocole TCP. On dit que le protocole UDP est basé sur les transactions : en d’autres termes, quand une application doit envoyer des données, elle les envoie tout simplement.

De nombreuses applications utilisant le protocole UDP envoient de petites quantités de données pouvant tenir dans un seul segment. Cependant, certaines applications envoient des volumes de données plus importants qui doivent être découpés en plusieurs segments. L’unité de données de protocole UDP est appelée un datagramme, bien que les termes segment et datagramme soient parfois utilisés indifféremment pour décrire une unité de données de protocole de la couche transport.

Quand plusieurs datagrammes sont envoyés vers une destination, ils peuvent emprunter des chemins différents et arriver dans le désordre. Le protocole UDP n’effectue pas de suivi des numéros d’ordre comme le fait le protocole TCP. Le protocole UDP ne peut pas réassembler les datagrammes dans leur ordre de transmission, comme illustré dans la figure.

Le protocole UDP se contente donc de réassembler les données dans l’ordre dans lequel elles ont été reçues, puis de les transmettre à l’application. Si l’ordre des données est important pour l’application, cette dernière doit identifier l’ordre correct et déterminer le mode de traitement des données.

Processus de requêtes client-serveur

Serveur

Comme c’est le cas avec des applications basées sur le protocole TCP, des numéros de port réservés ou inscrits sont affectés aux applications serveur basées sur le protocole UDP. Quand ces applications ou processus s’exécutent sur un serveur, ils ou elles acceptent les données correspondant au numéro de port attribué. Quand le protocole UDP reçoit un datagramme destiné à l’un de ces ports, il transmet les données applicatives à l’application appropriée d’après son numéro de port.

Client

Comme c’est le cas avec le protocole TCP, la communication client-serveur est initiée par une application cliente qui demande des données à un processus serveur. Le processus client UDP sélectionne aléatoirement un numéro de port dans une plage de numéros de port dynamiques et l’utilise comme port source pour la conversation. Le port de destination est généralement le numéro de port réservé ou inscrit affecté au processus serveur.

Le choix aléatoire des numéros de port source présente également un avantage en matière de sécurité. Quand il existe un modèle prévisible de sélection du port de destination, il est plus facile pour un intrus de simuler un accès à un client en tentant de se connecter au numéro de port le plus susceptible d’être ouvert.

Étant donné que le protocole UDP ne crée pas de session, dès que les données sont prêtes à être envoyées et que les ports sont identifiés, le protocole UDP peut créer des datagrammes et les transmettre à la couche réseau, pour qu’ils soient adressés et envoyés sur le réseau.

Une fois qu’un client a choisi le port source et le port de destination, la même paire de ports est utilisée dans l’en-tête de tous les datagrammes employés dans la transaction. Quand des données sont renvoyées du serveur vers le client, les numéros de port source et de port de destination sont inversés dans l’en-tête du datagramme.