UDP : quand et pourquoi

Prérequis : cours 6.1 ; TCP et UDP.

Pourquoi

Tout n'a pas besoin de la fiabilité TCP : parfois, une donnée fraîche vaut mieux qu'une donnée vieille retransmise. UDP = TCP sans filet : rapide, simple, à la charge de l'app de gérer.

Concepts

• Datagramme : un message indépendant, sans connexion ni ordre ni garantie. Perdu = perdu, dupliqué = possible. L'app gère (ou s'en fiche).
• Idéal pour : temps réel (voix, vidéo, jeux — mieux vaut sauter une image que geler), requêtes simples (DNS : une question, une réponse), découverte (DHCP, mDNS/Bonjour).
• QUIC (HTTP/3) : le meilleur des deux — construit sur UDP : handshake rapide (0-1 RTT), multiplexé sans head-of-line blocking, chiffré d'office. Si ton site est lent sur mobile, QUIC/HTTP-3 change souvent la donne.

Exemple : voir l'UDP

ss -unp                    # sockets UDP : DNS (:53), DHCP (:67), QUIC (:443/udp) ?
sudo tcpdump -i any udp port 53 -c 5   # regarder passer du DNS réel

Un serveur web moderne : port 443 en TCP (HTTP/1-2) et en UDP (HTTP/3). Les deux doivent être ouverts au firewall — l'oubli classique du passage à HTTP/3.

Cas réel

Visioconférence qui « robotise » : 8 % de perte sur le WiFi. En TCP ça gelerait ; en UDP ça dégrade (voix métallique) mais ça continue. Solution réseau (pas logicielle) : câble ou 5 GHz moins encombré, QoS sur la box.

Pièges

• Firewall « TCP-only » : règles 443/tcp sans 443/udp = HTTP/3 mort en silence (fallback lent vers TCP).
• UDP + NAT : les translations expirent vite (30 s-2 min) — d'où keepalives fréquents (ex. WireGuard toutes les 25 s).
• Tester UDP au telnet : telnet = TCP uniquement. Pour UDP : nc -u (netcat).

À retenir

UDP = sans filet, parfait pour temps réel et requêtes simples ; QUIC = TCP-like sur UDP ; ouvrir 443/udp aussi.