UDP — La vitesse avant tout

Qu'est-ce qu'UDP ?

UDP (User Datagram Protocol) est le second grand protocole de la couche Transport, défini dans la RFC 768 en 1980 par Jon Postel. Là où TCP est le service de livraison recommandé avec accusé de réception, UDP est le service postal "best-effort" : on envoie le datagramme et on espère qu'il arrive.

UDP est sans connexion, sans fiabilité garantie, et sans contrôle de congestion. Ce n'est pas un défaut de conception — c'est un choix délibéré pour les applications qui ont besoin de vitesse et de faible latence plutôt que de garanties de livraison.

Philosophie d'UDP

"Je vous envoie ce datagramme. Il arrivera peut-être, peut-être pas, peut-être dans le désordre. À vous de gérer."

Cette simplicité est précisément ce qui rend UDP indispensable pour certains cas d'usage. Moins d'overhead = moins de latence = meilleures performances pour les données en temps réel.

Structure de l'en-tête UDP : 8 octets seulement

L'en-tête UDP est d'une simplicité remarquable. 8 octets, c'est tout.

 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 (16 b)   │        Port destination (16 b)          │
├─────────────────────────┼─────────────────────────────────────────┤
│    Longueur (16 b)      │        Checksum (16 b)                  │
└─────────────────────────┴─────────────────────────────────────────┘
│                        Données...                                  │

Comparaison de taille d'en-tête :

TCP  : 20 octets minimum (jusqu'à 60 avec options)
UDP  : 8 octets toujours
Gain : 12 octets par datagramme (150% de réduction d'overhead !)

Pour un flux VoIP de 50 paquets par seconde, cela représente 600 octets par seconde économisés sur l'overhead seul — significatif à grande échelle.

Caractéristiques d'UDP

Sans connexion (Connectionless)

Il n'y a pas de handshake, pas d'établissement de session. L'émetteur envoie directement ses données sans préambule. Cela économise le temps du three-way handshake TCP (un aller-retour complet = 1 RTT).

TCP :  SYN → SYN-ACK → ACK → données  (2 RTT avant données)
UDP :  données                          (0 RTT, envoi immédiat)

Best-effort (Sans garantie de livraison)

UDP ne garantit pas que le datagramme :

• Arrive à destination
• N'arrive qu'une seule fois
• Arrive dans l'ordre d'envoi

Si un datagramme UDP est perdu, personne ne le sait sauf l'application elle-même (si elle implémente un mécanisme de détection).

Sans contrôle de flux ni de congestion

UDP n'a pas de fenêtre de réception, pas de slow start. Si une application envoie des données UDP à 100 Mbps sur une liaison de 10 Mbps, tous les paquets en excès sont silencieusement droppés. C'est pour cela qu'une application UDP doit gérer elle-même son débit ou accepter les pertes.

Préservation des frontières de message

Contrairement à TCP (flux d'octets), UDP préserve les frontières de datagramme : un sendto() de 1000 octets produit exactement un datagramme de 1000 octets. Le récepteur reçoit exactement 1000 octets en un recvfrom().

Cas d'usage : quand choisir UDP ?

DNS — Domain Name System (port 53)

La résolution DNS est l'exemple quintessentiel d'UDP. Chaque requête DNS est un petit datagramme (quelques dizaines d'octets), et la réponse aussi. L'overhead TCP (handshake, teardown) doublerait le temps de résolution.

Si la réponse est perdue, le resolver réessaie après un timeout. Si la réponse est trop grande pour UDP (>512 octets, voire >4096 avec EDNS0), DNS bascule automatiquement sur TCP.

# Requête DNS standard en UDP
dig google.com
# ;; Query time: 12 msec
# ;; SERVER: 8.8.8.8#53(8.8.8.8)
# ;; MSG SIZE rcvd: 55

# Forcer une requête DNS en TCP
dig google.com +tcp

# Capture du trafic DNS
sudo tcpdump -i eth0 udp port 53 -n

DHCP — Attribution d'adresses IP (ports 67/68)

DHCP utilise UDP car au moment où un client demande une adresse IP, il n'en a pas encore ! Il ne peut donc pas établir une connexion TCP. Il envoie en broadcast via UDP.

VoIP et Téléphonie IP

La voix en temps réel peut tolérer des pertes (un paquet vocal perdu provoque un léger craquement, à peine perceptible), mais ne peut pas tolérer la latence de la retransmission TCP. Une retransmission TCP prendrait 100-500ms, rendant la conversation incompréhensible.

UDP + RTP (Real-time Transport Protocol) est la combinaison standard pour la VoIP (SIP, Zoom, Teams).

Streaming vidéo (RTP/RTSP)

Pour la vidéo en direct, mieux vaut manquer une image (freeze momentané) que d'attendre une retransmission et décaler tout le flux. Les encodeurs modernes peuvent masquer les pertes ponctuelles.

Gaming en ligne

Les jeux multijoueurs (FPS, MOBA) envoient l'état du jeu plusieurs dizaines de fois par seconde. Un paquet de position perdu ? Le prochain paquet donnera la position mise à jour. L'attendre avec TCP ajouterait de la latence inacceptable (lag).

NTP — Network Time Protocol (port 123)

La synchronisation d'horloge nécessite des timestamps très précis. L'overhead TCP perturberait les mesures de délai. NTP utilise UDP.

QUIC / HTTP/3

QUIC (Quick UDP Internet Connections), développé par Google et standardisé dans la RFC 9000, est le protocole de transport d'HTTP/3. Il est construit sur UDP mais implémente au niveau applicatif :

• Chiffrement TLS 1.3 intégré
• Multiplexage de flux sans head-of-line blocking
• Reprise de connexion rapide (0-RTT)
• Contrôle de congestion avancé

# Vérifier si un site utilise HTTP/3 (QUIC)
curl -I --http3 https://cloudflare.com 2>/dev/null | head -5
# ou
curl -I https://www.google.com | grep Alt-Svc
# Alt-Svc: h3=":443"; ma=2592000  ← supporte HTTP/3/QUIC

Tableau comparatif TCP vs UDP

Le processus DHCP DORA

DHCP illustre parfaitement pourquoi UDP est nécessaire. Le processus d'attribution d'une adresse IP est composé de 4 messages (acronyme DORA) :

Étape 1 — DISCOVER (Client broadcast)

Le client n'a pas d'adresse IP. Il envoie un broadcast UDP pour trouver un serveur DHCP.

Source IP  : 0.0.0.0 (pas encore d'adresse)
Dest IP    : 255.255.255.255 (broadcast)
Source Port: 68 (DHCP client)
Dest Port  : 67 (DHCP server)

Étape 2 — OFFER (Serveur → Client)

Le serveur DHCP répond avec une offre d'adresse IP :

Source IP  : 192.168.1.1 (serveur DHCP)
Contenu    : "Voici une adresse offerte : 192.168.1.100
              Masque : /24
              Gateway : 192.168.1.1
              DNS : 8.8.8.8
              Bail : 86400 secondes"

Étape 3 — REQUEST (Client broadcast)

Le client accepte l'offre et le diffuse en broadcast (pour informer les autres serveurs DHCP potentiels qu'il a choisi) :

"J'accepte l'offre de 192.168.1.1 pour l'adresse 192.168.1.100"

Étape 4 — ACKNOWLEDGE (Serveur → Client)

Le serveur confirme définitivement l'attribution :

"Confirme : 192.168.1.100/24 est à toi pour 86400 secondes"

# Forcer un renouvellement DHCP
sudo dhclient -r eth0  # libère l'adresse
sudo dhclient eth0     # redemande une adresse

# Capturer le processus DORA
sudo tcpdump -i eth0 udp port 67 or udp port 68 -n -v

# Voir les baux DHCP actifs (si vous êtes le serveur)
cat /var/lib/dhcp/dhcpd.leases

# Sur un client avec systemd-networkd
sudo networkctl renew eth0

Fiabilité applicative sur UDP

Certaines applications implémentent leur propre mécanisme de fiabilité par-dessus UDP pour bénéficier du meilleur des deux mondes :

Commandes UDP essentielles

# Afficher tous les sockets UDP en écoute
ss -unp

# Lister les ports UDP ouverts
ss -ulnp

# Exemple de sortie :
# Netid  State   Recv-Q  Send-Q  Local Address:Port  Peer Address:Port
# udp    UNCONN  0       0       0.0.0.0:68          0.0.0.0:*       users:(("dhclient"))
# udp    UNCONN  0       0       0.0.0.0:123         0.0.0.0:*       users:(("ntpd"))
# udp    UNCONN  0       0       127.0.0.1:323       0.0.0.0:*       users:(("chronyd"))

# Capturer du trafic UDP
sudo tcpdump -i eth0 udp -n

# Envoyer un datagramme UDP (test)
echo "Hello" | nc -u 192.168.1.100 9999

# Écouter sur un port UDP (test)
nc -ul 9999

# Tester la résolution DNS (UDP par défaut)
dig google.com
# ;; Query time: 8 msec → temps UDP (très rapide)

dig google.com +tcp
# ;; Query time: 15 msec → temps TCP (handshake overhead)

Performances et limitations

Taille maximale d'un datagramme UDP

Taille max des données UDP = 65535 - 8 (en-tête UDP) - 20 (en-tête IP) = 65507 octets

En pratique, la MTU Ethernet de 1500 octets impose :
Données max sans fragmentation = 1500 - 20 (IP) - 8 (UDP) = 1472 octets

Si un datagramme UDP dépasse la MTU, il est fragmenté au niveau IP. La fragmentation IP est à éviter pour les performances (la perte d'un fragment invalide tout le datagramme).

Le problème du buffer UDP plein

Si une application ne consomme pas les datagrammes UDP assez vite, le buffer du kernel se remplit et les nouveaux datagrammes sont silencieusement droppés sans notification à l'émetteur.

# Voir la taille des buffers UDP
cat /proc/sys/net/core/rmem_default  # buffer réception par défaut
cat /proc/sys/net/core/rmem_max      # buffer réception maximum

# Augmenter les buffers pour les applications haute performance
sudo sysctl -w net.core.rmem_max=26214400    # 25 MB
sudo sysctl -w net.core.wmem_max=26214400    # 25 MB

# Voir les paquets UDP droppés (compteur global)
cat /proc/net/udp | awk 'NR>1 {sum+=$7} END {print "Drops:", sum}'

Récapitulatif

Passez maintenant au chapitre suivant : Ports et Sockets — comment les applications se trouvent et communiquent via les numéros de port.