UDP : qu'est-ce que c'est, protocole sans connexion et comment il fonctionne

Qu'est-ce qu'UDP ?

UDP (User Datagram Protocol) est l'un des principaux protocoles de la couche de transport du modèle TCP/IP, conçu par David Reed en 1980. Il fournit un mécanisme minimal de transmission de données : l'application envoie un datagramme et le protocole ne vérifie pas s'il est arrivé au destinataire.

L'en-tête UDP se compose de seulement quatre champs : port source, port de destination, longueur et somme de contrôle. Chaque champ occupe 2 octets, donc la taille totale de l'en-tête est de 8 octets. À titre de comparaison, un en-tête TCP sans options occupe 20 octets, et avec options — jusqu'à 60 octets.

Le protocole ne prend pas en charge la fragmentation à son propre niveau — si un datagramme dépasse l'MTU (Maximum Transmission Unit), il est fragmenté au niveau IP. Si un fragment est perdu, tout le datagramme est rejeté, car UDP ne peut pas demander la retransmission de fragments individuels. Les développeurs doivent contrôler la taille du datagramme — pour les réseaux mobiles, l'MTU est souvent de 1400 octets, donc la taille maximale ne doit pas dépasser cette valeur.

Comment fonctionne UDP

Une application utilisant UDP crée un socket de type SOCK_DGRAM, spécifie le port et l'adresse IP de destination et envoie un datagramme. Le protocole ajoute un en-tête minimal et transmet le paquet à la couche IP. Le récepteur écoute sur son port et extrait les données des datagrammes entrants.

UDP n'effectue pas de contrôle de congestion — l'application peut envoyer des datagrammes à la vitesse maximale supportée par le réseau. Cela peut entraîner une congestion du canal, mais dans les scénarios en temps réel, cette agressivité est justifiée : pour un appel vidéo, un flux de données avec des pertes possibles est plus important que l'arrêt de la transmission.

import socket

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.sendto(b'Hello, UDP!', ('192.168.1.100', 8888))
sock.close()

Dans cet exemple, un socket SOCK_DGRAM est créé pour UDP. La méthode sendto envoie un datagramme sans établir de connexion — il suffit de connaître l'IP et le port du destinataire. La méthode recvfrom côté serveur renvoie à la fois les données et l'adresse de l'expéditeur pour la réponse. Les sockets UDP sur les plateformes mobiles sont configurés de manière similaire mais nécessitent des autorisations supplémentaires : sur iOS, il faut ajouter NSAppTransportSecurity pour les connexions UDP non chiffrées, et sur Android, l'autorisation INTERNET dans le manifeste.

Avantages et inconvénients d'UDP

Choisir UDP est justifié dans les scénarios où la vitesse est plus critique que la fiabilité. Le protocole ne perd pas de temps en établissement de connexion, accusés de réception et retransmissions — cela offre une latence minimale, mais exige que le développeur gère les pertes de manière indépendante.

Dans les applications mobiles, UDP est utilisé via des frameworks comme WebRTC, qui ajoutent le contrôle des pertes, le débit adaptatif et le jitter buffer au-dessus d'UDP. Cela offre les avantages de vitesse sans les inconvénients du protocole brut.

Un autre aspect important d'UDP est l'absence de contrôle de congestion. Dans TCP, les algorithmes Slow Start et Congestion Avoidance réduisent la vitesse de transmission en cas de perte de paquets pour éviter la surcharge du réseau. UDP ne dispose pas de tels mécanismes, donc les développeurs doivent implémenter leurs propres stratégies de contrôle de débit — par exemple, le débit adaptatif dans les appels vidéo ou le rate limiting dans les serveurs de jeux pour éviter une congestion excessive du réseau.

Où UDP est utilisé

UDP est indispensable dans les scénarios où la tolérance à la latence est plus importante que la tolérance à la perte de paquets. Explorons les principaux domaines d'application du protocole dans le développement mobile et web.

Streaming audio et vidéo

Les protocoles RTP et RTSP, fonctionnant sur UDP, sont utilisés pour transmettre des flux audio et vidéo en temps réel. WebRTC — la norme pour les appels vidéo dans les navigateurs et les applications mobiles — utilise UDP comme transport principal pour les données média et TCP pour la signalisation. La perte d'un paquet dans une vidéo à 30 ips est imperceptible pour l'utilisateur, contrairement au délai de retransmission qui provoque un gel notable de l'image.

Jeux en ligne

Les jeux de tir multijoueurs et les MOBA nécessitent une latence inférieure à 50 ms pour une synchronisation correcte. UDP transmet les positions des joueurs, les tirs et les événements plus rapidement que TCP, et la perte de paquets est simplement ignorée — la prochaine mise à jour arrivera dans 16 à 33 ms. Les moteurs de jeux populaires, dont Unity et Unreal Engine, utilisent UDP via leurs propres couches de transport avec une fiabilité supplémentaire pour les événements critiques via des accusés de réception au niveau applicatif.

DNS et DHCP

Les requêtes DNS utilisent UDP sur le port 53 car chaque requête est un seul petit datagramme (généralement jusqu'à 512 octets). Si aucune réponse n'arrive, le client réessaie simplement après un délai d'attente, ce qui est plus rapide que d'établir une connexion TCP avec sa poignée de main à trois voies. DHCP fonctionne également sur UDP, car le client n'a pas encore d'adresse IP et ne peut pas établir de connexion TCP, tandis que les paquets UDP de diffusion permettent de trouver un serveur DHCP sur le réseau local.

Comparaison UDP vs TCP

Le choix entre UDP et TCP est un compromis entre vitesse et fiabilité. Chaque protocole est optimal pour sa classe de tâches, et comprendre leurs différences aide à prendre les bonnes décisions architecturales lors de la conception de communications réseau dans les applications mobiles.

Les projets mobiles adoptent souvent une approche hybride : TCP pour les requêtes fiables (authentification, chargement de données) et UDP pour les flux médias. QUIC — un protocole moderne de Google fonctionnant sur UDP — combine la vitesse d'UDP avec la fiabilité de TCP et est déjà utilisé dans HTTP/3.

Exemple de code UDP

Examinons un serveur UDP simple en Python qui reçoit des messages des clients et envoie une réponse. Le serveur écoute sur le port 8888 et traite les datagrammes entrants dans une boucle infinie.

import socket

server = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
server.bind(('0.0.0.0', 8888))
print('Serveur UDP démarré sur le port 8888')

while True:
    data, addr = server.recvfrom(1024)
    print(f'Reçu de {addr} : {data.decode()}')
    server.sendto(b'OK', addr)

Le serveur crée un socket UDP, se lie au port 8888 et attend les datagrammes entrants. recvfrom renvoie les données et l'adresse du client, permettant de répondre via sendto. Contrairement à TCP, le serveur ne maintient pas d'état de connexion — chaque datagramme est traité indépendamment. Cela rend les serveurs UDP évolutifs : un seul serveur peut gérer des millions de clients sans allouer de mémoire pour chaque connexion individuelle, ce qui est important pour les serveurs DNS et les systèmes de matchmaking de jeux.

Dans le développement mobile, UDP est souvent utilisé via des bibliothèques de haut niveau. Par exemple, CocoaAsyncSocket pour iOS fournit des sockets UDP avec des délégués et GCD pour le traitement asynchrone des événements. Sur Android, la classe DatagramSocket fait partie de la bibliothèque standard java.net et ne nécessite aucune dépendance supplémentaire. Pour Flutter, il existe le paquet udp qui fournit une interface simple pour envoyer et recevoir des datagrammes sans configurer de sockets natifs.

Il est important de noter que de nombreux réseaux mobiles et pare-feu d'entreprise bloquent le trafic UDP, en particulier sur les ports supérieurs à 1024. Si votre application utilise UDP, vous devez prévoir un repli vers TCP ou vérifier la disponibilité du protocole via des serveurs STUN, comme le fait WebRTC. Sur iOS, le framework système Network.framework avec NWConnection prend en charge à la fois TCP et UDP, choisissant automatiquement le protocole optimal en fonction de la disponibilité. Pour les applications en temps réel, il est également recommandé d'implémenter un débit adaptatif, qui réduit la qualité du flux en cas de perte de paquets, garantissant une lecture continue même sur des canaux instables avec des taux d'erreur élevés.