UDP — User Datagram Protocol
UDP est un protocole de transport (couche 4) sans connexion, sans garantie de livraison. Là où TCP établit une connexion fiable avant d’envoyer, UDP envoie directement les données — ce qui le rend beaucoup plus rapide, au prix de la fiabilité.
UDP est le protocole de choix quand la latence prime sur la fiabilité : streaming, jeux, DNS, VoIP.
Anatomie d’un datagramme UDP
Le header UDP est minimaliste : 8 octets seulement, contre 20 minimum pour TCP.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
┌──────────────────────────┬──────────────────────────────────────┐
│ Port source │ Port destination │
├──────────────────────────┼──────────────────────────────────────┤
│ Length │ Checksum │
├──────────────────────────┴──────────────────────────────────────┤
│ Data (payload) │
└─────────────────────────────────────────────────────────────────┘
| Champ | Taille | Rôle |
|---|---|---|
| Port source | 16 bits | Port de l’émetteur (optionnel, peut être 0) |
| Port destination | 16 bits | Port de l’application cible |
| Length | 16 bits | Taille totale du datagramme (header + données) en octets |
| Checksum | 16 bits | Vérification d’intégrité (optionnel en IPv4, obligatoire en IPv6) |
Pas de numéro de séquence, pas d’ACK, pas de flags, pas de window size — UDP fait confiance à l’application pour gérer ce dont elle a besoin.
Ce qu’UDP ne fait PAS (contrairement à TCP)
| Mécanisme TCP | UDP |
|---|---|
| Établissement de connexion (3-way handshake) | Aucun — envoi direct |
| Acquittements (ACK) | Aucun |
| Retransmission des paquets perdus | Aucune |
| Garantie d’ordre des datagrammes | Aucune |
| Contrôle de flux (Window Size) | Aucun |
| Contrôle de congestion | Aucun |
TCP vs UDP — quand choisir ?
| Critère | TCP | UDP |
|---|---|---|
| Fiabilité | Garantie (retransmissions) | Aucune |
| Ordre | Garanti | Non garanti |
| Latence | Plus haute (handshake + ACK) | Minimale |
| Overhead header | 20 octets minimum | 8 octets |
| Connexion | Établie avant envoi | Aucune |
| Contrôle de flux | Oui (Window Size) | Non |
| Broadcast / Multicast | Non | Oui |
| Cas d’usage | HTTP, SSH, SMTP, BDD | DNS, streaming, jeux, VoIP, DHCP |
Cas d’usage détaillés
DNS (port 53)
La résolution DNS utilise UDP par défaut : la requête et la réponse tiennent en un seul datagramme (< 512 octets).
Si la réponse est trop grande (DNSSEC, zones larges), DNS bascule automatiquement sur TCP.
Client Serveur DNS
│ ── UDP:53 "A example.com?" ──► │
│ ◄── UDP:53 "93.184.216.34" ─── │
[terminé en 1 aller-retour, sans handshake]
Streaming vidéo / audio
Un paquet perdu provoque un artefact visuel d’une fraction de seconde — bien moins gênant qu’attendre la retransmission TCP (qui gèlerait la vidéo).
Serveur streaming
│ ── paquet 1 ──────────────────► Client
│ ── paquet 2 ──────────────────►
│ ── paquet 3 (perdu ❌)
│ ── paquet 4 ──────────────────► Client reçoit 1, 2, 4
│ [légère dégradation, lecture continue]
Jeux en ligne
La position d’un joueur est envoyée plusieurs dizaines de fois par seconde. Une donnée retransmittée avec 200ms de retard est inutile — mieux vaut l’ignorer et attendre la prochaine mise à jour.
VoIP (téléphonie IP)
Un silence ou un micro-grésil vaut mieux qu’une conversation qui “freeze” en attendant une retransmission TCP.
DHCP (port 67/68)
Attribution d’IP au démarrage — le client n’a pas encore d’IP, il ne peut pas établir une connexion TCP. Il diffuse (broadcast) une requête UDP.
Client (0.0.0.0) Serveur DHCP
│ ── DISCOVER (broadcast) ──────► │
│ ◄── OFFER (192.168.1.50) ────── │
│ ── REQUEST (192.168.1.50) ─────► │
│ ◄── ACK ─────────────────────── │
UDP et la gestion des erreurs côté application
Puisqu’UDP ne gère rien, c’est à l’application de gérer ce dont elle a besoin :
| Besoin | Solution applicative |
|---|---|
| Détecter les pertes | Numéros de séquence maison dans le payload |
| Retransmettre | Timer applicatif + renvoi si pas de réponse |
| Ordonner | Buffer de réassemblage dans l’application |
| Fiabilité partielle | QUIC (HTTP/3) ajoute de la fiabilité sur UDP |
QUIC — UDP avec fiabilité (HTTP/3)
QUIC (Quick UDP Internet Connections) est un protocole développé par Google, standardisé par l’IETF. Il implémente sur UDP ce que TCP + TLS font, mais avec des améliorations majeures :
HTTP/1.1 et HTTP/2 : HTTP → TLS → TCP → IP
HTTP/3 : HTTP → QUIC (TLS intégré) → UDP → IP
| Avantage QUIC vs TCP+TLS | Explication |
|---|---|
| 0-RTT / 1-RTT | Connexion établie en 0 ou 1 aller-retour (vs 3 pour TCP+TLS 1.2) |
| Pas de head-of-line blocking | La perte d’un paquet ne bloque pas les autres streams |
| Migration de connexion | Change de réseau (Wi-Fi → 4G) sans couper la connexion |
| TLS 1.3 intégré | Pas de négociation séparée, chiffrement dès le premier paquet |
Ports UDP courants
| Port | Protocole | Usage |
|---|---|---|
53 | DNS | Résolution de noms |
67/68 | DHCP | Attribution d’adresses IP |
69 | TFTP | Transfert de fichiers simplifié |
123 | NTP | Synchronisation de l’horloge |
161/162 | SNMP | Supervision réseau |
500 | IKE | Négociation VPN IPsec |
514 | Syslog | Envoi de logs réseau |
4789 | VXLAN | Réseaux overlay (Kubernetes, Docker) |
8472 | Flannel/Cilium | Tunnels réseau Kubernetes |
En relation avec
- Paquets IP et TCP — TCP, le pendant fiable d’UDP
- Couches OSI — UDP opère en couche 4 (Transport)
- DNS — utilise UDP par défaut (port 53)
- RPC — gRPC repose sur HTTP/2 (TCP) mais QUIC (UDP) est l’avenir
- Requêtes HTTP et HTTPS — HTTP/3 utilise QUIC sur UDP