Protocole de datagramme utilisateur

En informatique , le protocole UDP ( User Datagram Protocol ) est l'un des protocoles de communication fondamentaux de la suite de protocoles Internet . Il permet d'envoyer des messages (transportés sous forme de datagrammes dans des paquets ) à d'autres hôtes d'un réseau IP ( Internet Protocol ). Au sein d'un réseau IP, l'UDP ne nécessite aucune communication préalable pour établir les canaux de communication ou les chemins de données.

UDP est un protocole sans connexion , ce qui signifie que les messages sont envoyés sans négociation de connexion et qu'UDP ne conserve aucune trace des données envoyées. UDP fournit des sommes de contrôle pour l'intégrité des données et des numéros de port pour adresser différentes fonctions à la source et à la destination du datagramme. Il ne comporte aucun dialogue d'établissement de liaison et expose donc le programme de l'utilisateur aux aléas du réseau sous-jacent ; il n'existe aucune garantie de livraison, d'ordonnancement ou de protection contre les doublons. Si des mécanismes de correction d'erreurs sont nécessaires au niveau de l'interface réseau, une application peut utiliser le protocole TCP ( Transmission Control Protocol ) ou le protocole SCTP ( Stream Control Transmission Protocol ), conçus à cet effet.

Le protocole UDP convient aux applications où la vérification et la correction des erreurs ne sont pas nécessaires ou sont effectuées par l'application elle-même ; UDP évite la surcharge liée à un tel traitement au niveau de la pile de protocoles . Les applications sensibles au temps utilisent souvent UDP car il est préférable de supprimer des paquets plutôt que d'attendre des paquets retardés par une retransmission , ce qui peut s'avérer impossible dans un système temps réel .

Le protocole a été conçu par David P. Reed en 1980 et formellement défini dans la RFC 768 .

UDP est un protocole de couche transport simple, orienté messages , documenté dans la RFC 768. Bien qu'UDP assure la vérification d'intégrité (par somme de contrôle ) de l'en-tête et de la charge utile , il n'offre aucune garantie de livraison des messages au protocole de couche supérieure et la couche UDP ne conserve aucune trace des messages UDP une fois envoyés. C'est pourquoi UDP est parfois qualifié de protocole de datagramme non fiable . Si la fiabilité de la transmission est requise, elle doit être implémentée dans l'application de l'utilisateur.

Plusieurs attributs du protocole UDP le rendent particulièrement adapté à certaines applications.

• Il est orienté transaction , adapté aux protocoles simples de requête-réponse tels que le système de noms de domaine ou le protocole de temps réseau .
• Il fournit des datagrammes , adaptés à la modélisation d'autres protocoles tels que le tunneling IP ou l'appel de procédure à distance et le système de fichiers réseau .
• Il est simple , adapté à l'amorçage ou à d'autres fins sans pile de protocoles complète , comme le DHCP et le protocole de transfert de fichiers trivial .
• Il est sans état , adapté à un très grand nombre de clients, comme dans les applications de diffusion multimédia telles que l'IPTV .
• L' absence de délais de retransmission le rend adapté aux applications en temps réel telles que la voix sur IP , les jeux en ligne et de nombreux protocoles utilisant le protocole de diffusion en temps réel .
• Grâce à sa prise en charge du multicast , il convient à la diffusion d'informations, notamment dans de nombreux types de découverte de services et d'informations partagées comme le protocole de temps de précision et le protocole d'information de routage .

Les applications peuvent utiliser des sockets de datagrammes pour établir des communications entre hôtes. Une application associe un socket à son point de terminaison de transmission de données, qui est une combinaison d'une adresse IP et d'un port . Ainsi, UDP assure le multiplexage applicatif . Un port est une structure logicielle identifiée par son numéro , une valeur entière de 16 bits, comprise entre 0 et 65 535. Le port 0 est réservé, mais peut être utilisé comme port source si le processus émetteur n'attend pas de réponse.

L' IANA ( Internet Assigned Numbers Authority ) a divisé les numéros de port en trois plages. Les ports 0 à 1023 sont utilisés pour les services courants et bien connus. Sur les systèmes d'exploitation de type Unix , l'utilisation de l'un de ces ports requiert des privilèges d'administrateur . Les ports 1024 à 49151 sont les ports enregistrés utilisés pour les services enregistrés auprès de l'IANA. Les ports 49152 à 65535 sont des ports dynamiques, non officiellement désignés pour un service spécifique et pouvant être utilisés à diverses fins. Ils peuvent également servir de ports éphémères , permettant aux logiciels exécutés sur l'hôte de créer dynamiquement des points de terminaison de communication selon les besoins.

Un datagramme UDP est constitué d'un en-tête de datagramme suivi d'une section de données (les données utiles pour l'application). L'en-tête du datagramme UDP est constitué de 4 champs, chacun de 2 octets (16 bits) :

L'utilisation des champs Somme de contrôle et Port source est facultative en IPv4 (fond violet clair dans le tableau). En IPv6, seul le champ Port source est facultatif. S'il n'est pas utilisé, ces champs doivent être définis sur zéro.

Port source : 16 bits

Ce champ identifie le port de l'expéditeur, le cas échéant, et doit être considéré comme le port de réponse. Si l'hôte source est le client, le numéro de port est probablement un port éphémère. Si l'hôte source est le serveur, le numéro de port est probablement un port standard compris entre 0 et 1023.

Port de destination : 16 bits

Ce champ identifie le port du récepteur et est obligatoire. Comme pour le numéro de port source, si le client est l'hôte de destination, le numéro de port sera probablement un port éphémère ; si l'hôte de destination est le serveur, le numéro de port sera probablement un port connu.

Longueur : 16 bits

Ce champ spécifie la longueur du datagramme UDP (en-tête et données) en octets . La longueur minimale est de 8 octets, soit la longueur de l'en-tête. La taille de ce champ fixe une limite théorique de 65 535 octets (8 octets d'en-tête + 65 527 octets de données) pour un datagramme UDP. Cependant, la limite réelle de la longueur des données, imposée par le protocole IPv4 sous-jacent , est de 65 507 octets (65 535 octets – 8 octets d'en-tête UDP – 20 octets d'en-tête IP ).

Grâce aux jumbogrammes IPv6, il est possible d'avoir des datagrammes UDP de taille supérieure à 65 535 octets. Le champ de longueur est défini sur zéro si la longueur de l'en-tête UDP plus les données UDP est supérieure à 65 535 octets.

Somme de contrôle : 16 bits

Le champ de somme de contrôle peut être utilisé pour la vérification des erreurs dans l'en-tête et les données. Ce champ est facultatif en IPv4 et obligatoire dans la plupart des cas en IPv6.

Données : Variable

La charge utile du paquet UDP.

La méthode utilisée pour calculer la somme de contrôle est définie dans la RFC 768 , et un calcul efficace est abordé dans la RFC 1071 :

La somme de contrôle est le complément à un sur 16 bits de la somme en complément à un d'un pseudo-en-tête d'informations provenant de l'en-tête IP, de l'en-tête UDP et des données, complétée par des octets nuls à la fin (si nécessaire) pour obtenir un multiple de deux octets.

Autrement dit, tous les mots de 16 bits sont additionnés en utilisant l'arithmétique du complément à un. On additionne les valeurs de 16 bits. À chaque addition, si une retenue (17e bit) est générée, on inverse cette retenue et on l'ajoute au bit de poids faible du total cumulé. Enfin, la somme est complémentée à un pour obtenir la valeur du champ de somme de contrôle UDP.

Si le calcul de la somme de contrôle donne zéro (les 16 bits à 0), elle doit être envoyée en complément à un (tous les bits à 1), car une somme de contrôle nulle indique qu'aucune somme de contrôle n'a été calculée. Dans ce cas, aucun traitement spécifique n'est requis à la réception, car tous les bits à 0 et tous les bits à 1 sont égaux à zéro en arithmétique du complément à un.

Les différences entre IPv4 et IPv6 résident dans le pseudo-en-tête utilisé pour calculer la somme de contrôle, cette dernière étant obligatoire en IPv6. Sous certaines conditions, une application UDP utilisant IPv6 est autorisée à utiliser un mode UDP sans somme de contrôle avec un protocole de tunnel.

Lorsque le protocole UDP est utilisé sur IPv4, la somme de contrôle est calculée à l'aide d'un pseudo-en-tête contenant certaines informations similaires à celles de l' en-tête IPv4 réel . Ce pseudo-en-tête n'est pas l'en-tête IPv4 réel utilisé pour l'envoi d'un paquet IP ; il sert uniquement au calcul de la somme de contrôle. Le calcul de la somme de contrôle UDP est optionnel pour IPv4. Si aucune somme de contrôle n'est utilisée, elle doit être définie sur zéro.

La somme de contrôle est calculée sur les champs suivants :

Adresse source : 32 bits

L'adresse source de l'en-tête IPv4.

Adresse de destination : 32 bits

L'adresse de destination figurant dans l'en-tête IPv4.

Zéros : 8 bits ; Zéros == 0

Que des zéros.

Protocole : 8 bits

La valeur du protocole pour UDP : 17 (ou 0x11 ).

Longueur UDP : 16 bits

La longueur de l'en-tête et des données UDP (mesurée en octets).

Comme IPv6 possède des adresses plus longues et une structure d'en-tête différente, la méthode utilisée pour calculer la somme de contrôle est modifiée en conséquence :

Tout protocole de transport ou autre protocole de couche supérieure qui inclut les adresses de l'en-tête IP dans son calcul de somme de contrôle doit être modifié pour être utilisé sur IPv6, afin d'inclure les adresses IPv6 de 128 bits au lieu des adresses IPv4 de 32 bits.

Lors du calcul de la somme de contrôle, un pseudo-en-tête est à nouveau utilisé, imitant le véritable en-tête IPv6 :

La somme de contrôle est calculée sur les champs suivants :

Adresse source : 128 bits

L'adresse dans l'en-tête IPv6.

Adresse de destination : 128 bits

La destination finale ; si le paquet IPv6 ne contient pas d’en-tête de routage, UDP utilise l’adresse de destination figurant dans l’en-tête IPv6 ; sinon, au niveau du nœud d’origine, il utilise l’adresse figurant dans le dernier élément de l’en-tête de routage et, au niveau du nœud de réception, il utilise l’adresse de destination figurant dans l’en-tête IPv6.

Longueur UDP : 32 bits

La longueur de l'en-tête et des données UDP (mesurée en octets).

Zéros : 24 bits ; Zéros == 0

Que des zéros.

En-tête suivant : 8 bits

Valeur du protocole de couche transport pour UDP : 17 .

En raison de leur manque de fiabilité, les applications UDP peuvent subir des pertes de paquets, des réordonnancements, des erreurs ou des duplications. Si elles utilisent UDP, les applications de l'utilisateur final doivent assurer les échanges nécessaires, notamment la confirmation en temps réel de la réception du message. Certaines applications (par exemple, TFTP) peuvent intégrer des mécanismes de fiabilité rudimentaires au niveau de la couche application, selon les besoins. Pour les applications exigeant un haut degré de fiabilité, un protocole alternatif tel que le protocole de contrôle de transmission (TCP) peut être utilisé.

Le plus souvent, les applications UDP n'utilisent pas de mécanismes de fiabilité et peuvent même en être pénalisées. La diffusion multimédia en continu , les jeux multijoueurs en temps réel et la voix sur IP (VoIP) sont des exemples typiques d'applications utilisant UDP. Dans ces applications, la perte de paquets n'est généralement pas un problème critique. En VoIP, par exemple, la latence et la gigue sont les principaux facteurs à prendre en compte. L'utilisation de TCP entraînerait une gigue en cas de perte de paquets, car TCP ne fournit pas de données supplémentaires à l'application pendant qu'elle demande le renvoi des données manquantes.

De nombreuses applications Internet clés utilisent UDP, notamment : le système de noms de domaine (DNS), le protocole de gestion de réseau simple (SNMP), le protocole d'information de routage (RIP) et le protocole de configuration dynamique des hôtes (DHCP).

Le trafic voix et vidéo est généralement transmis via UDP. Les protocoles de diffusion audio et vidéo en temps réel sont conçus pour gérer les pertes occasionnelles de paquets, ce qui limite la dégradation de la qualité par rapport aux délais importants qui se produiraient en cas de retransmission des paquets perdus. Comme TCP et UDP fonctionnent sur le même réseau, au milieu des années 2000, certaines entreprises ont constaté qu'une augmentation du trafic UDP provenant de ces applications en temps réel nuisait légèrement aux performances des applications utilisant TCP, telles que les systèmes de point de vente , de comptabilité et de bases de données (lorsque TCP détecte une perte de paquets, il réduit son débit de données).

Certains systèmes VPN , comme OpenVPN , prennent en charge le protocole UDP et offrent un contrôle d'erreurs au niveau applicatif ainsi que des mécanismes pour améliorer la fiabilité de la transmission. WireGuard utilise également UDP et effectue un contrôle d'erreurs, mais n'offre aucune garantie de fiabilité ; celle-ci repose sur les protocoles de couche supérieure au sein du tunnel ou sur les applications finales.

QUIC est un protocole de transport basé sur UDP. QUIC assure une connexion fiable et sécurisée. HTTP/3 utilise QUIC, contrairement aux versions précédentes de HTTPS qui combinaient TCP et TLS pour garantir respectivement la fiabilité et la sécurité. Ainsi, HTTP/3 utilise une seule négociation pour établir une connexion, au lieu de deux négociations distinctes pour TCP et TLS, ce qui réduit le temps global d'établissement de la connexion.

Le protocole TCP (Transmission Control Protocol) est un protocole orienté connexion qui nécessite une prise de contact pour établir une communication de bout en bout. Une fois la connexion établie, les données utilisateur peuvent être transmises de manière bidirectionnelle.

• Fiable – Le protocole TCP gère l'accusé de réception des messages, leur retransmission et les délais d'expiration. Plusieurs tentatives de livraison sont effectuées. Si des données sont perdues, elles sont renvoyées. En TCP, soit aucune donnée n'est perdue, soit, en cas de plusieurs délais d'expiration, la connexion est interrompue.
• Ordonné – Si deux messages sont envoyés successivement sur une connexion, le premier parviendra en premier à l'application destinataire. Lorsque les segments de données arrivent dans le désordre, TCP met en mémoire tampon les données manquantes jusqu'à ce que toutes les données soient correctement ordonnées et transmises à l'application.
• Protocole lourd – TCP nécessite trois paquets pour établir une connexion socket avant que toute donnée utilisateur puisse être envoyée. TCP gère la fiabilité et le contrôle de la congestion .
• Flux continu – Les données sont lues sous forme de flux d'octets ; aucune indication distinctive n'est transmise pour signaler les limites des messages (segments).

Le protocole UDP (User Datagram Protocol) est un protocole sans connexion, basé sur la messagerie et plus simple . Les protocoles sans connexion n'établissent pas de connexion dédiée de bout en bout. La communication s'effectue par la transmission d'informations dans un seul sens, de la source à la destination, sans vérification de l'état de disponibilité du destinataire.

• Non fiable – Lorsqu'un message UDP est envoyé, il est impossible de savoir s'il atteindra sa destination ; il peut se perdre en cours de route. Il n'existe aucune notion d'accusé de réception, de retransmission ou de délai d'expiration.
• Non ordonné – Si deux messages sont envoyés au même destinataire, l’ordre dans lequel ils arriveront ne peut être garanti.
• Léger – Il n'y a pas d'ordonnancement des messages, pas de suivi des connexions, etc. Il s'agit d'une couche de transport très simple conçue au-dessus d'IP.
• Datagrammes – Les paquets sont envoyés individuellement et leur intégrité est vérifiée à leur arrivée. Chaque paquet possède des limites définies, respectées à la réception ; une opération de lecture au niveau du socket de réception permet de récupérer l’intégralité du message tel qu’il a été initialement envoyé.
• Absence de contrôle de la congestion : le protocole UDP lui-même ne permet pas d’éviter la congestion. Des mesures de contrôle de la congestion doivent être mises en œuvre au niveau de l’application ou du réseau.
• Les diffusions – étant sans connexion, le protocole UDP peut diffuser les paquets envoyés afin qu'ils soient reçus par tous les appareils du sous-réseau.
• Multicast – un mode de fonctionnement multicast est pris en charge, permettant d'acheminer automatiquement et sans duplication un seul paquet de données vers un groupe d'abonnés.

• RFC 9868 – Protocole de datagramme utilisateur
• RFC 2460 – Spécification du protocole Internet, version 6 (IPv6)
• RFC 2675 – Jumbogrammes IPv6
• RFC 4113 – Base d'informations de gestion pour l'UDP
• RFC 8085 – Directives d’utilisation du protocole UDP