TCP versus UDP pour les développeurs — Quand le protocole est vraiment pertinent

Vous construisez un jeu en mode multijoueur. Les joueurs se plaignent de retards. Vous avez optimisé votre code serveur, réduit les requêtes de base de données, et votre latence p99 semble correcte. Le problème est plus simple : vous utilisez TCP. C’est tout. C’est le retard.

TCP et UDP ne sont pas simplement deux boîtes sur une liste de protocoles — ils représentent deux paris fondamentaux sur ce que le réseau fera. Le mauvais choix ne vous coûte pas seulement en performance. Il change la nature des échecs lorsque les choses vont mal.

Le pari que TCP fait

TCP vous promet un flux de données fiable et ordonné. Si un paquet est perdu, TCP le retransmet. Si les paquets arrivent dans un ordre incorrect, TCP les réorganise. Votre application voit toujours des données séquentielles et propres.

Cette garantie coûte trois choses :

• Latence de mise en connexion — TCP exige une mise en connexion à trois voies avant qu’un seul octet de données d’application ne parte. Sur un réseau avec un temps de réponse de 50 ms, vous perdez 150 ms avant que votre première requête ne commence.
• Blocage en tête de flux — C’est celui qui tue les jeux. Si le paquet #5 est perdu, TCP retient les paquets #6, #7 et #8 dans un tampon en attendant que #5 soit retransmis et arrive. Le flux est bloqué. La mise à jour de la position du joueur il y a 100 ms est en attente dans un tampon pendant que le réseau s’organise.
• Surcharge de contrôle de congestion — L’algorithme de fenêtre de congestion de TCP (CUBIC, BBR, etc.) réduit le taux d’envoi lorsqu’il détecte une perte. Sur un réseau perte, cela signifie que TCP réduit le débit au moment où le réseau est le plus sollicité — c’est précisément le moment où les utilisateurs le ressentent le plus.

Ce que UDP vous donne réellement

UDP envoie un datagramme et ne regarde pas en arrière. Aucun échange, aucune reconnaissance, aucune retransmission. Si un paquet est perdu, il est perdu. Le récepteur reçoit ce qui arrive, dans l’ordre dans lequel il arrive.

Ce n’est pas une limitation — c’est le point. Quand vous avez besoin de latence faible plutôt que de garanties de livraison, UDP vous permet de faire ce choix explicitement. La logique de fiabilité passe dans votre couche d’application, où vous pouvez prendre des décisions plus intelligentes sur ce qui nécessite une retransmission.

Dans un jeu, une mise à jour de la position d’un joueur il y a 50 ms est inutile — vous voulez la mise à jour actuelle. Avec TCP, vous devez buffer et attendre. Avec UDP, vous envoyez l’état le plus récent et vous ignorez ce qui est obsolète. L’expérience est plus fluide même en cas de perte de paquets plus importante.

TCP vs UDP : la comparaison qui compte vraiment

Propriété	TCP	UDP
Mise en connexion	Échange à trois voies (ajoute 1,5× RTT avant le premier octet)	Aucun — lancer immédiatement
Garantie de livraison	Oui — retransmission en cas de perte	Non — envoyer et oublier
Ordre des paquets	Assuré par le pilote	Problème de votre application
Blocage en tête de flux	Oui — une perte de paquet bloque le flux	Non — chaque datagramme est indépendant
Contrôle de congestion	Intégré (CUBIC, BBR, etc.)	Aucun — implémenter votre propre solution ou l’ignorer
Surcharge de latence typique	150 à 300 ms sur des connexions fraîches	Sous-millisecondes
Cas d'utilisation	HTTP/1.1, HTTP/2, bases de données, transfert de fichiers, courriels	DNS, jeux, diffusion en direct, HTTP/3 (QUIC)

Où chaque protocole appartient réellement

DNS fonctionne sur UDP — et il y a une leçon là-dedans

Chaque requête DNS que votre application effectue se fait par défaut sur UDP. La requête s’inscrit dans un seul paquet, la réponse s’inscrit dans un seul paquet, et vous obtenez votre réponse en un seul tour de réseau. Aucune latence de mise en connexion, aucune état à maintenir sur le serveur.

Si la réponse est trop grande (enregistrements DNSSEC, nombreux enregistrements A), DNS passe à TCP. Mais dans le cas courant — une recherche d’un nom d’hôte — c’est purement UDP parce que le pari est évident : le troisième échange prendrait plus de temps que la requête elle-même.

Vous pouvez observer ce comportement avec l’outil IO Tools Recherche DNS — saisissez un domaine et regardez combien de temps les types de records se résolvent. Cette vitesse est due à UDP qui élimine une entière itération de latence de mise en connexion.

Jeux : UDP est la seule réponse réelle

Toutes les bibliothèques de réseau des grands jeux — Valve’s GameNetworkingSockets, Epic’s EOS transport, Unity’s UTP — sont construites sur UDP. La raison est le blocage en tête de flux.

Dans un FPS compétitif, vous envoyez des mises à jour de position toutes les 64 ticks — toutes les 15 ms. Si un paquet est perdu et que TCP retient les prochaines cinq mises à jour en attendant la retransmission, vous introduisez 75 ms de ralentissement au moment précis où cela est le plus problématique. Avec UDP, vous envoyez la mise à jour suivante immédiatement. Le client intercale sur le vide. L’expérience est fluide.

La plupart des bibliothèques de réseau des jeux construites sur UDP implémentent une fiabilité sélective — des numéros de séquence, des files d’attente prioritaires, des ACK sélectifs — mais uniquement pour les données qui en ont vraiment besoin : les messages de chat, les prises d’objets, l’état de match. Les données de position sont fiabilisées par design. Une lecture obsolète est pire qu’aucune lecture.

Diffusion en direct : cela dépend du cas d’usage

La diffusion en direct (Twitch, émissions sportives) utilise des protocoles basés sur UDP — RTP, WebRTC, SRT — parce que quelques frames perdues sont acceptables mais la latence n’est pas. Vous ne pouvez pas buffer 30 secondes d’un match en direct pour garantir une livraison fluide.

Les contenus diffusés en diffusion (Netflix, YouTube) utilisent en réalité TCP, car le buffering masque le coût. Quelques secondes de pré-buffer signifient que les surcharges de retransmission de TCP sont invisibles — vous voyez simplement une lecture fluide. La pénalité de latence n’a pas d’importance quand vous regardez quelque chose qui s’est produit hier.

HTTP/3 fonctionne sur UDP — et cela change les performances du web

HTTP/3 fonctionne sur QUIC, qui fonctionne sur UDP. Google a conçu QUIC spécifiquement pour corriger le problème de blocage en tête de flux de TCP pour le trafic web. Avec HTTP/2 sur TCP, une perte de paquet bloque tous les flux multiplexés partageant cette connexion. QUIC implémente le multiplexage des flux au niveau du transport avec des reconnaissements indépendants — une perte de paquet bloque un seul flux, pas tous les flux.

QUIC intègre également le TLS dans le processus de mise en connexion, réduisant la mise en connexion froide à un tour de réseau (0-RTT en cas de reprise de session). Sur des réseaux perdants — connexions mobiles, WiFi saturé — cela représente une amélioration significative. En 2024, environ 30% de sites web prennent en charge HTTP/3, et tous les navigateurs principaux le activent par défaut. Si vous déployez derrière Cloudflare ou un CDN moderne, vous servez probablement déjà HTTP/3 sans avoir besoin de le configurer explicitement.

L’arbre décisionnel pratique

Lorsque vous choisissez un transport pour un nouveau protocole ou un service, la question n’est pas « TCP ou UDP ? » — c’est « quels échecs peux-je tolérer ? »

• Chaque octet doit arriver, dans l’ordre, ou l’opération échoue → TCP. Téléchargements de fichiers, connexions à une base de données, appels API, courriels. La perte de données signifie des données corrompues ou une erreur de parsing.
• La latence est plus importante que la garantie de livraison → UDP. Jeux, diffusion en direct, appels vocaux, capteurs. Une lecture obsolète est pire qu’aucune lecture.
• Vous avez besoin des deux, par message → Construire sur UDP avec fiabilité sélective. QUIC le fait. Le canal de données SCTP de WebRTC le fait. Des bibliothèques comme ENet et GameNetworkingSockets le font aussi — bien que de le faire vous-même soit un travail non trivial qui est facilement mal implémenté.

Une erreur à souligner : supposer que « le trafic interne » signifie que vous pouvez utiliser UDP sans réfléchir. La perte de paquets dans un datacenter est rare mais pas nulle — défaillances matérielles, congestion réseau sous charge maximale, commutateurs mal configurés. Si votre application corrompt silencieusement les données en cas de perte, un réseau interne ne vous sauvera pas.

Conclusion

TCP est le bon choix par défaut pour la plupart des codes d’application. Si vous faites des appels API, parlez à une base de données ou transférez des fichiers, les garanties de TCP sont exactement ce dont vous avez besoin et les surcharges sont invisibles sur des échelles humaines.

UDP est le bon choix lorsque la latence est une contrainte rigide et que votre application peut contrôler sa relation avec la fiabilité. C’est un ensemble spécifique de problèmes — des jeux en temps réel, des médias en direct, des protocoles personnalisés — et non une optimisation de performance générale à atteindre quand TCP semble lent.

L’erreur réelle n’est pas d’utiliser TCP quand UDP serait plus rapide. C’est de ne pas savoir lequel vous choisissez, ou pourquoi, et d’être surpris quand le mode d’échec arrive.

Vous aimerez peut-être aussi