UDP : à quoi cor­res­pond le User Datagram Protocol ?

La com­mu­ni­ca­tion entre les systèmes de réseaux do­mes­tiques et d’en­tre­prises locaux, et les réseaux publics, comme Internet, repose par défaut sur la suite des pro­to­coles Internet. Le composant le plus célèbre de cette pile de pro­to­coles est in­con­tes­ta­ble­ment l’Internet Protocol (IP), qui est non seulement res­pon­sable de l’adressage et de la frag­men­ta­tion des paquets de données, mais qui définit également la façon dont sont décrites les in­for­ma­tions sur la source et la des­ti­na­tion. La trans­mis­sion des données est toutefois ha­bi­tuel­le­ment assurée par le protocole de transport orienté connexion TCP (« Trans­mis­sion Control Protocol »), ce qui explique pourquoi les réseaux sont souvent qualifiés de réseaux TCP/IP. Si le TCP garantit une sécurité, il s’ac­com­pagne également d’un retard de la trans­mis­sion. C’est pourquoi David Patrick Reed a présenté en 1980 son concept de User Datagram Protocol (UDP) comme une al­ter­na­tive plus simple et plus rapide au protocole standard.

Le User Datagram Protocol, abrégé en UDP, est un protocole per­met­tant l’envoi sans connexion de da­ta­grammes dans des réseaux basés sur le protocole IP. Afin d’atteindre les services souhaités sur les hôtes de des­ti­na­tion, le protocole utilise des ports qui cons­ti­tuent un élément essentiel de l’entête UDP. À l’instar de nombreux autres pro­to­coles de réseau, l’UDP fait partie de la suite des pro­to­coles Internet. Il in­ter­vient au niveau de la couche transport et joue ainsi le rôle d’in­ter­mé­diaire entre la couche réseau et la couche ap­pli­ca­tion.

En utilisant le User Datagram Protocol, une ap­pli­ca­tion peut donc envoyer très ra­pi­de­ment des in­for­ma­tions, étant donné qu’aucune connexion au des­ti­na­taire n’est établie et qu’aucune réponse ne doit être attendue. En revanche, il n’y a aucune garantie que les paquets arrivent entiers et dans le même ordre que celui dans lequel ils ont été envoyés. Par ailleurs, le protocole n’offre aucune pro­tec­tion contre les ma­ni­pu­la­tions ou accès de tiers. Les paquets erronés peuvent toutefois être iden­ti­fiés à l’aide d’une somme de contrôle fa­cul­ta­tive (obli­ga­toire avec IPv6).

Afin de com­prendre dans le détail comment la trans­mis­sion des paquets est effectuée avec ce protocole, il est judicieux de se pencher plus pré­ci­sé­ment sur les ca­rac­té­ris­tiques du User Datagram Protocol déjà men­tion­nées.

1. L’UDP est sans connexion : le transport des données via le protocole UDP se démarque par le fait qu’il a lieu sans connexion existante entre l’ex­pé­di­teur et le des­ti­na­taire. Les paquets concernés sont ensuite envoyés à l’adresse IP pri­vi­lé­giée en indiquant le port de des­ti­na­tion, sans que l’or­di­na­teur auquel cette adresse est attribuée n’ait à envoyer une réponse. Si des paquets doivent être renvoyés à l’ex­pé­di­teur, l’entête UDP peut également contenir le port source.
2. Ports utilisés par l’UDP : à l’instar du TCP, l’UDP a recours à des ports afin de remettre les paquets aux bons pro­to­coles ul­té­rieurs ou aux ap­pli­ca­tions sou­hai­tées sur le système de des­ti­na­tion. Comme le modèle éprouvé, les ports sont définis à l’aide d’une nu­mé­ro­ta­tion, dont les numéros compris entre 0 et 1023 sont attribués à des services fixes.
3. L’UDP permet une com­mu­ni­ca­tion rapide, sans délai : ce protocole de transport est adapté à une trans­mis­sion rapide des données, car il n’établit pas de connexion. Ceci résulte également du fait que la perte de paquets in­di­vi­duels impacte uni­que­ment la qualité de la trans­mis­sion. En cas de connexion TCP, il est en revanche procédé au­to­ma­ti­que­ment à une nouvelle demande des paquets perdus, ce qui bloque l’in­té­gra­lité du processus de trans­mis­sion.
4. L’UDP n’offre aucune garantie quant à la sécurité et à l’au­then­ti­cité des données : le fait de renoncer à l’au­then­ti­fi­ca­tion mutuelle de l’ex­pé­di­teur et du des­ti­na­taire permet au protocole UDP d’assurer une vitesse de trans­mis­sion ex­cep­tion­nelle. Toutefois, le protocole ne peut garantir l’intégrité et la sécurité des paquets de données. L’ordre dans lequel les paquets ont été envoyés n’est pas non plus garanti. C’est pourquoi les services faisant appel à l'UDP doivent mettre à dis­po­si­tion des mesures de cor­rec­tion et de pro­tec­tion propres.

Comme c’est souvent le cas pour les pro­to­coles, les paquets UDP sont composés d’un entête, également appelée « header », et des données utiles à pro­pre­ment parler. L’entête UDP contient ici toutes les in­for­ma­tions né­ces­saires à la trans­mis­sion des données avec un protocole de transport, et à l’iden­ti­fi­ca­tion d’un paquet UDP en tant que tel. La structure est divisée en deux blocs de 32 bits avec quatre champs de données distincts et se présente comme suit :

Les 16 premiers bits de l’entête renvoient au port source par lequel le paquet de données concerné est envoyé. Le des­ti­na­taire a besoin de cette in­for­ma­tion pour pouvoir répondre au paquet. Comme l’UDP est sans connexion et ne prévoit en principe aucun échange entre l’ex­pé­di­teur et le des­ti­na­taire, ce champ est fa­cul­ta­tif. C’est pourquoi la valeur est gé­né­ra­le­ment définie sur « 0 » à cet endroit.

Dans le champ suivant, le port de des­ti­na­tion, et donc le service contrôlé, est renseigné. Con­trai­re­ment au port source, cette in­for­ma­tion est obli­ga­toire puisque, dans le cas contraire, le da­ta­gramme ne pourrait pas être attribué cor­rec­te­ment.

La longueur du da­ta­gramme est définie dans le champ Longueur. Elle comprend la longueur de l’entête (8 octets) et la longueur des données utiles (en théorie maximum : 65 535 octets). En cas d’uti­li­sa­tion de IPv4, la limite effective pour les données utiles est de 65 507 octets – après déduction des entêtes IP et UDP. Dans IPv6, des paquets dépassant le maximum (« jum­bo­grams ») sont par ailleurs possibles. D'après la RFC 2675, la valeur du champ Longueur est dans ce cas définie sur « 0 ».

La fin de l’entête UDP est cons­ti­tuée par la somme de contrôle qui sert à iden­ti­fier les erreurs lors de la trans­mis­sion. De cette façon, les ma­ni­pu­la­tions des données trans­mises peuvent être iden­ti­fiées, mais les paquets cor­res­pon­dants sont rejetés sans nouvelle demande. Pour calculer la somme, on utilise des parties

• de l’entête UDP,
• des données utiles
• et du pseudo entête (contient les in­for­ma­tions de l’entête IP)

La somme de contrôle est fa­cul­ta­tive en IPv4, mais elle est toutefois utilisée par défaut par la plupart des ap­pli­ca­tions. En l’absence de somme de contrôle, ce champ prend également la valeur « 0 ». Si l’UDP est utilisé en as­so­cia­tion avec IPv6, la somme de contrôle est obli­ga­toire.

Du fait de sa structure mi­ni­ma­liste et de l’absence de mé­ca­nismes visant à garantir une trans­mis­sion complète et réussie, le User Datagram Protocol n’est pas utilisé comme protocole de transport universel. Au départ, il a plutôt été conçu pour les ap­pli­ca­tions ne né­ces­si­tant pas (encore) de service de trans­mis­sion fiable. Par con­sé­quent, le domaine d’ap­pli­ca­tion de l’UDP est plutôt limité, mais souligne son énorme valeur comme le prouvent les classes d’ap­pli­ca­tions suivantes pour UDP :

• les ap­pli­ca­tions « best effort delivery » (livraison des données best effort) : le scénario d’uti­li­sa­tion classique de l’UDP porte sur les ap­pli­ca­tions basées sur une « livraison des données best effort ». Une trans­mis­sion peu fiable des in­for­ma­tions suffit aux pro­grammes utilisant le User Datagram Protocol comme service « best effort », car ils re­nou­vel­lent ré­gu­liè­re­ment les in­for­ma­tions quoi qu’il arrive. On peut citer comme exemple les ap­pli­ca­tions qui trans­met­tent les valeurs mesurées ou qui exécutent toujours les mêmes tâches.
• les ap­pli­ca­tions légères : la faible surcharge de ce protocole de transport offre une aide optimale aux ap­pli­ca­tions cons­truites de façon ex­trê­me­ment simple. En as­so­cia­tion avec une absence d’éta­blis­se­ment de connexion, ces pro­grammes profitent d’une per­for­mance par­ti­cu­liè­re­ment élevée dans le cadre du trai­te­ment et de la trans­mis­sion de paquets de données dans les réseaux.
• les ap­pli­ca­tions disposant de mé­ca­nismes propres pour une trans­mis­sion fiable : l’UDP peut également s’avérer in­té­res­sant pour les ap­pli­ca­tions qui dépendent d’un échange d’in­for­ma­tions fiable, mais disposent de mé­ca­nismes propres pour répondre aux paquets. L’avantage de tels services est qu’ils ne sont pas tenus à des modèles fixes pour garantir l’intégrité et l’exac­ti­tude des paquets de données envoyés. Ils peuvent décider de façon autonome comment et quand réagir à des in­for­ma­tions man­quantes ou classées de façon ar­bi­traire.
• les ap­pli­ca­tions multicast : tandis que les pro­to­coles de transport fiables comme le TCP sont limités à l’uti­li­sa­tion d’une com­mu­ni­ca­tion de bout en bout, le protocole UDP supporte également les con­nexions IP multicast. Si une ap­pli­ca­tion doit pouvoir envoyer si­mul­ta­né­ment des paquets IP de façon rapide et efficace à de nombreux des­ti­na­taires, l’UDP constitue une base adaptée.
• ap­pli­ca­tions en temps réel (real-time ap­pli­ca­tions) : pour finir, l’UDP est également adapté comme protocole de transport pour les services tra­vail­lant avec des exigences temps réel – par exemple le streaming audio ou vidéo. Ces derniers doivent pouvoir gérer de façon autonome l’envoi, la réception et la diffusion de flux de données, ce qui est par­fai­te­ment possible avec la trans­mis­sion UDP sans connexion.