L’UDP (User Datagram Protocol) est un protocole de transport réseau, comme TCP, mais conçu pour aller vite et avec très peu de mécanismes de contrôle. Il envoie des petits paquets appelés datagrammes vers une adresse IP et un port, sans établir de connexion préalable.

L’idée principale

TCP fonctionne comme un envoi recommandé : il établit une connexion, numérote les données, confirme leur réception et retransmet ce qui manque. UDP ressemble davantage à l’envoi de cartes postales : l’émetteur les envoie immédiatement, sans attendre de confirmation.

Cette simplicité réduit la latence et la surcharge, mais UDP ne garantit ni la livraison, ni l’ordre d’arrivée, ni l’absence de doublons. Si un datagramme est perdu, UDP ne le renvoie pas automatiquement.

Application émettrice

Datagramme UDP

Paquet IP

Réseau

Application destinataire, via son port UDP

Sans connexion

Avec TCP, le client et le serveur effectuent d’abord un échange d’ouverture, le three-way handshake. UDP n’a pas cette étape : une application peut transmettre directement un datagramme au destinataire.

Cela ne veut pas dire qu’UDP est incapable d’échanges dans les deux sens. Un serveur DNS, par exemple, reçoit une requête UDP et renvoie une réponse UDP ; simplement, le protocole ne maintient pas une session fiable et persistante entre les deux hôtes.

Contenu d’un datagramme

L’en-tête UDP est très léger : il fait seulement 8 octets et contient quatre champs.

ChampRôle
Port sourceIdentifie l’application émettrice, si nécessaire
Port destinationIdentifie le service destinataire
LongueurIndique la taille totale du datagramme UDP
Somme de contrôleDétecte certaines altérations de données

La somme de contrôle aide à détecter une corruption, mais elle ne rend pas UDP fiable : un datagramme erroné ou perdu n’est pas automatiquement récupéré par le protocole. Elle est facultative en IPv4, mais obligatoire avec IPv6.

Pourquoi l’utiliser ?

UDP est pertinent lorsqu’une information reçue trop tard perd sa valeur. Mieux vaut parfois ignorer un paquet absent et continuer la lecture plutôt que bloquer tout le flux en attendant une retransmission.

Cas d’usage courants :

  • DNS : une petite requête et une petite réponse doivent être rapides.
  • Voix sur IP et visioconférence : perdre un fragment audio est souvent moins gênant qu’ajouter un délai audible.
  • Jeux en ligne : la position actuelle d’un joueur compte davantage que celle d’il y a une seconde.
  • Streaming temps réel et diffusion vidéo interactive.
  • Protocoles de découverte sur le réseau local.

UDP face à TCP

CaractéristiqueUDPTCP
Ouverture de connexionNonOui
Accusés de réceptionNonOui
RetransmissionNonOui
Ordre garantiNonOui
Contrôle de fluxNon natifOui
Latence et surchargeFaiblesPlus élevées
Cas typiquesDNS, jeu, voix, vidéo directeWeb, e-mail, fichiers, SSH

Le choix ne consiste donc pas à dire qu’UDP est « meilleur » que TCP : UDP privilégie l’immédiateté ; TCP privilégie l’intégrité et la fiabilité.

Exemple simple

Dans un appel vidéo, une syllabe audio perdue peut produire un bref défaut, mais la conversation continue. Si TCP devait retransmettre systématiquement le paquet manquant, l’audio suivant devrait parfois attendre, ce qui créerait du décalage et donnerait une impression de coupure plus gênante.

À l’inverse, télécharger une archive ZIP avec UDP brut serait risqué : un seul fragment absent peut rendre le fichier inutilisable. On choisit alors TCP, ou un protocole construit au-dessus d’UDP qui ajoute lui-même les mécanismes nécessaires.

UDP moderne

Certains protocoles modernes utilisent UDP comme base puis ajoutent, au niveau applicatif, les fonctions dont ils ont besoin : chiffrement, contrôle de congestion, retransmission sélective ou gestion de plusieurs flux. QUIC, employé notamment par HTTP/3, suit cette approche.

Ainsi, UDP est une base volontairement simple : il remet rapidement des datagrammes à une application, qui peut ensuite décider elle-même du niveau de fiabilité, d’ordre et de délai acceptable.

Recommended Posts