UDP — La vitesse avant tout

Qu'est-ce qu'UDP ?

UDP (User Datagram ProtocolUDPRéseauxProtocole de transport sans connexion ni garantie de livraison, réduit à un en-tête de 8 octets. Sa légèreté convient au DNS, à la voix et à la vidéo, où un retard coûte plus qu'une perte.Voir dans le glossaire) est le second grand protocole de la couche Transport, défini dans la RFC 768 en 1980 par Jon Postel. Là où TCPTCPRéseauxProtocole de transport qui garantit que les données arrivent complètes, dans l'ordre et sans doublon. Il établit une connexion, numérote chaque segment et retransmet ce qui manque.Voir dans le glossaire 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éesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire 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 handshakethree-way handshakeRéseauxSéquence en trois messages — SYN, SYN-ACK, ACK — qui ouvre une connexion TCP. Elle synchronise les numéros de séquence des deux extrémités avant tout échange de données.Voir dans le glossaire 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éceptionfenêtre de réceptionRéseauxVolume de données que le récepteur annonce pouvoir absorber. Elle protège le destinataire de la saturation, là où la fenêtre de congestion protège le réseau.Voir dans le glossaire, 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 ?

Le critère n'est pas « ai-je besoin de vitesse », mais « qu'est-ce qui coûte le plus cher : perdre une donnée, ou l'attendre ». En voix sur IP, retransmettre un paquet vieux de 200 ms n'a aucun intérêt : il arriverait après le moment où il aurait dû être joué.

DNS — Domain Name System (port 53)

La résolution DNSDNSRéseauxSystème qui traduit un nom de domaine en adresse IP, par interrogations successives de la racine, des serveurs de premier niveau puis des serveurs faisant autorité.Voir dans le glossaire 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)

DHCPDHCPRéseauxProtocole qui attribue automatiquement une adresse IP et ses paramètres à une machine qui se connecte, en quatre échanges : découverte, offre, requête, accusé.Voir dans le glossaire utilise UDP car au moment où un client demande une adresse IPadresse IPRéseauxIdentifiant numérique attribué à une machine sur un réseau, qui permet de l'atteindre depuis n'importe où. Elle tient sur 32 bits en IPv4 et sur 128 bits en IPv6.Voir dans le glossaire, il n'en a pas encore ! Il ne peut donc pas établir une connexion TCP. Il envoie en broadcastbroadcastRéseauxEnvoi d'une trame à toutes les machines d'un même réseau local simultanément. C'est le mécanisme employé par ARP ou DHCP quand le destinataire n'est pas encore connu.Voir dans le glossaire 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

QUICQUICRéseauxProtocole de transport multiplexé et chiffré reposant sur UDP, base d'HTTP/3, conçu pour réduire la latence de connexion.Voir dans le glossaire (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 :

• ChiffrementchiffrementCybersécuritéTransformation d'une donnée lisible en une forme inintelligible à l'aide d'une clé. Le destinataire disposant de la clé peut retrouver le message original. C'est le socle de la confidentialité sur Internet.Voir dans le glossaire TLSTLSRéseauxProtocole cryptographique assurant confidentialité et intégrité des communications applicatives (notamment HTTPS).Voir dans le glossaire 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 MTUMTURéseauxTaille maximale d'une trame pouvant circuler sur un lien réseau, généralement 1 500 octets en Ethernet. Un paquet plus grand doit être fragmenté ou rejeté.Voir dans le glossaire, 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.

UDP est volontairement minimal : rapide, sans garantie. La fiabilité, si besoin, est dans l'appli ou QUIC.

Choisissez UDP quand une perte ponctuelle vaut mieux qu'une file d'attente TCP.

VoIP préfère perdre un paquet plutôt que d'attendre une retransmission trop tardive.

Quand UDP est le bon outil

DNS, VoIP, jeux, certains tunnels, télémétrie : UDP minimise l’overhead et laisse l’applicatif gérer retransmission/ordre si besoin. QUIC (HTTP/3) réintroduit fiabilité au-dessus d’UDP pour contourner des limitations middlebox sur TCP.

Pas de connexion, mais pas « sans état » partout

UDP est sans connexion au sens transport. Les firewalls, eux, tracent souvent des flux UDP pseudo-stateful avec timeouts courts. Un retour de trafic hors fenêtre est drop. Cela explique des VPNVPNRéseauxRéseau privé virtuel qui chiffre le trafic entre deux points sur un réseau public. Il crée un tunnel sécurisé permettant d'accéder à des ressources distantes comme si on était sur le réseau local.Voir dans le glossaire ou VoIP capricieux derrière NATNATRéseauxMécanisme qui permet à plusieurs machines d'un réseau privé de partager une seule adresse IP publique. Il compense la pénurie d'adresses IPv4 mais complique les connexions entrantes.Voir dans le glossaire.

Perte et gigue

Mesurez loss et jitter, pas seulement la bande passante moyenne. Une file d’attente saturée augmente la latence avant même de perdre. Le QoS et le dimensionnement comptent davantage que « passer en TCP ».

Tester un service UDP avec un outil TCP (ou l’inverse) induit en erreur.

Sécurité UDP

IP spoofing plus facile, amplification (DNS, NTP, etc.), reflection. Rate-limit, filtrage, désactivation services inutiles. Surveillez les réponses asymétriques anormales.

Pour DNS interne, autorisez UDP/TCP 53 explicitement : les réponses tronquées basculent sur TCP.

QUIC et le contournement des middleboxes

HTTP/3/QUIC voyage en UDP, chiffre tôt, et gère perte/retransmission à sa façon. Certains réseaux d’entreprise bloquent encore UDP hors DNS : le fallback HTTP/2 TCP sauve l’utilisateur mais change vos hypothèses de perf. Mesurez le protocole réellement négocié.

Pour la VoIP, priorisez QoS et capacité plutôt que de « forcer TCP ». Un tunnel TCP-over-TCP empire souvent la congestion.

DNS, VPN et jeux : trois UDP différents

Le DNS est petit, sensible au filtrage et à l’amplification. Les VPN UDP (WireGuard, etc.) veulent stabilité de mapping NAT. Les jeux tolèrent la perte, pas le jitter. Appliquer la même config firewallpare-feuRéseauxÉquipement ou logiciel qui filtre le trafic selon des règles (ports, adresses, états) pour réduire la surface d'attaque.Voir dans le glossaire aux trois est une erreur. Créez des règles et timeouts adaptés par classe de flux.

Pour diagnostiquer UDP, les captures et les compteurs d’interface aident plus que ping. Instrumentez l’applicatif (sequence numbers, loss reports) quand c’est possible.

NAT traversal et keepalives UDP

Derrière NAT, un flux UDP doit renvoyer assez souvent pour garder le mapping. Les timeouts varient selon box grand public vs firewall entreprise. Les VPN et VoIP utilisent des keepalives : trop rares = coupures ; trop fréquents = batterie/CPU. Mesurez le timeout réel de votre chemin avec un lab simple.

Les middleboxes qui « aident » (ALG SIP) cassent parfois plus qu’elles n’aident. Préférez des designs modernes sans ALG magique.

Quand vous filtrez UDP, journalisez les drops sur les ports attendus (VPN) pendant les bascules : vous gagnerez des heures.

Observabilité UDP

Exportez pertes applicatives (RTP reports, QUIC stats, VPN counters). Les interfaces saturées avec drops TX/RX expliquent souvent le « UDP pourri ». Vérifiez aussi CPU softirq et file NAPI. Parfois le problème n’est pas le WAN mais l’hôte qui n’arrive plus à absorber les paquets.

Pour DNS, suivez timeouts résolveur, SERVFAIL rates, latence. Un résolveur saturé se manifeste en « Internet lent » global. Ayez un résolveur de secours testé, pas seulement configuré.

Atelier comparatif TCP vs UDP

Prenez le même payload utile : mesurez latence et comportement sous perte artificielle (netem). Observez retransmission TCP vs silence UDP. Puis ajoutez un léger ACK applicatif sur UDP. Vous sentirez pourquoi les protocoles temps réel n’empruntent pas toujours TCP, et pourquoi « tout passer en TCP pour simplifier » est un faux ami.

Documentez pour votre équipe : 5 cas où UDP est justifié chez vous, 5 où il ne l’est pas.

Approfondissement terrain — udp

Dans le chapitre udp, ancrez chaque notion par un exemple vécu ou un lab de cinq minutes. Écrivez le symptôme, l’hypothèse, la commande, le résultat, la conclusion : ce journal personnel accélère votre progression plus que la relecture passive. Partagez ensuite une version anonymisée dans le wiki d’équipe pour capitaliser. Revenez sur ce texte après un incident réel : annotez ce qui manquait. La maîtrise réseau se construit par boucles courtes de pratique, pas par accumulation de slides. Fixez-vous un exercice hebdomadaire de trente minutes jusqu’à ce que les commandes deviennent des réflexes. Variez les contextes : LAN, Wi-Fi, VPN, cloud, conteneur — le même concept change de visage. Quand une explication vous semble floue, reformulez-la sans jargon à un collègue non réseau. Si vous ne pouvez pas la reformuler, la notion n’est pas encore opérationnelle. Fermez chaque session d’étude par une question ouverte que vous résoudrez la fois suivante. Gardez une liste de « myths » à déconstruire : port élevé = sécurité, ping OK = service OK, etc. Ces myths coûtent cher en production ; les tuer est un objectif pédagogique explicite. Mesurez votre temps moyen pour classer un ticket réseau simple : il doit baisser au fil des chapitres. Enfin, reliez toujours la théorie à un risque : disponibilité, confidentialité, ou intégrité. Cas 13: documentez une observation concrète liée à udp dans votre environnement de lab ou de staging. Dans le chapitre udp, ancrez chaque notion par un exemple vécu ou un lab de cinq minutes. Écrivez le symptôme, l’hypothèse, la commande, le résultat, la conclusion : ce journal personnel accélère votre progression plus que la relecture passive. Partagez ensuite une version anonymisée dans le wiki d’équipe pour capitaliser. Revenez sur ce texte après un incident réel : annotez ce qui manquait. La maîtrise réseau se construit par boucles courtes de pratique, pas par accumulation de slides.