Pourquoi UDP est le protocole transport de choix pour la VoIP : faible overhead & latence
La Voix sur IP (VoIP) utilise massivement UDP (User Datagram Protocol) plutôt que TCP (Transmission Control Protocol) comme couche transport. Le facteur décisif n'est pas une seule fonctionnalité mais une constellation de caractéristiques UDP qui s'alignent parfaitement aux exigences de la voix temps réel. Voici la ventilation technique.
L'avantage principal : Overhead d'en-tête minimal
En-tête UDP : 8 octets fixe vs En-tête TCP : 20–60 octets (20 base + options).
Pour un paquet VoIP typique :
- Charge utile : 20 ms G.711 = 160 octets | G.729 = 20 octets | Opus = 20-60 octets
- En-tête IP : 20 octets (IPv4) / 40 octets (IPv6)
- Total UDP : 188 octets (G.711) → 4,3 % overhead
- Total TCP : 200+ octets → 20 %+ overhead
Sur un flux 50 paquets/seconde (packetization 20ms), UDP économise ~600 octets/sec = ~4,8 kbps par appel. Sur des milliers d'appels concurrents, c'est une efficacité bande passante massive.
Latence & Jitter : Les victoires structurelles d'UDP
Pas d'établissement de connexion
- TCP : Handshake 3 voies (SYN, SYN-ACK, ACK) = 1,5–3 RTT avant premier octet
- UDP : Tirer et oublier — premier paquet arrive en 1 RTT
- Critique pour : Mise en place appel (SIP INVITE), récupération session après handoff
Pas de blocage tête de ligne (Head-of-Line Blocking)
- TCP : Paquet perdu → récepteur met en tampon paquets suivants jusqu'à retransmission
- UDP : Paquet perdu → trou dans lecture (masqué par PLC) — paquets suivants lisent à l'heure
- La voix tolère la perte (1-5 % imperceptible avec PLC) ; ne peut pas tolérer délai variable
Pas de recul contrôle congestion
- TCP : Interprète perte comme congestion → réduit cwnd → réduit débit → ajoute délai
- UDP : Application contrôle débit (débit constant pour voix) — pas d'étranglement auto
- VoIP utilise RTCP pour rapports récepteur, pas contrôle congestion style TCP
Ce qu'UDP manque — Et pourquoi la VoIP n'en a pas besoin
| Fonction TCP | But | Pourquoi VoIP ne l'utilise pas |
|---|---|---|
| Livraison fiable (ACK/retransmission) | Intégrité données | Retransmission tardive > perte. Budget 150ms. PLC masque perte. |
| Ordre | Intégrité séquence | Numéros séquence RTP gèrent réordonnancement couche app |
| Contrôle flux | Protection tampon récepteur | Voix débit constant n'écrase pas ; tampon jitter absorbe |
| Contrôle congestion | Équité réseau | RTCP/XR surveillent ; app adapte codec/débit (ex: Opus VBR) |
La pile protocolaire VoIP
Application : SIP (signalisation) / RTP (média) Transport : UDP (RTP) | TCP/TLS (SIP souvent) Réseau : IP Liaison : Ethernet / Wi-Fi / 5G
Note : La signalisation SIP utilise souvent TCP/TLS pour fiabilité (mise en place appel doit réussir). Mais le média (RTP) utilise toujours UDP.
Quand TCP est utilisé pour le média (Rare)
- Pare-feu restrictifs bloquant UDP (entreprise, hôtel, certains pays)
- Tunneling TCP : relais TURN, VPN, proxy TLS
- WebRTC : Utilise ICE → essaie UDP → fallback TCP (TURN-TCP) → dernier recours
- Qualité souffre : Latence, jitter, glare plus élevés. Acceptable seulement quand UDP impossible.
Améliorations modernes sur UDP
- QUIC (HTTP/3) : Basé UDP, inclut flux fiables — pas pour voix (trop lourd)
- RTP/RTCP : Compensation jitter, NACK, FEC, estimation bande passante
- Codec Opus : Débit adaptatif, FEC, DTX, PLC — rend UDP résilient à la perte
- SRTP : Chiffrement/authentification sur UDP — pas TCP nécessaire pour sécurité
L'essentiel
L'en-tête 8 octets d'UDP, sa sémantique sans connexion et l'absence de blocage tête de ligne en font le seul protocole transport qui tient dans le budget latence strict de la voix (150ms aller simple, ITU-T G.114). Les fonctions de fiabilité de TCP deviennent des passifs pour le média temps réel. La VoIP ne tourne pas sur UDP parce qu'il est « rapide » — elle tourne sur UDP parce que les garanties de TCP sont fondamentalement incompatibles avec la physique de la conversation.