TCP était trop cassé pour être réparé, alors Internet a construit un nouveau protocole au-dessus d'UDP

TCP est la couche de transport d'Internet depuis 1974. Chaque page web que vous chargez, chaque requête API que votre application effectue, chaque e-mail que vous envoyez — pendant cinquante ans, presque tout a transité via TCP. Le protocole est fiable, éprouvé par l'usage et déployé sur tous les appareils connectés au réseau sur Terre. Il constitue également un goulot d'étranglement croissant pour le fonctionnement réel du web moderne, et le réparer s'est avéré politiquement impossible. L'industrie a donc construit quelque chose de nouveau au-dessus d'UDP.

Ce quelque chose de nouveau est QUIC, normalisé par l'IETF en 2021 sous le nom de RFC 9000. HTTP/3, la dernière version du protocole qui alimente le web, fonctionne sur QUIC. Cloudflare a servi HTTP/3 à plus de 40 % de son trafic. Google a déployé QUIC sur ses propres services depuis 2013. Le protocole qui était censé être une expérience transporte désormais une part substantielle d'Internet.

Qu'est-ce qui n'allait pas avec TCP

La conception fondamentale de TCP a été bâtie pour un monde de connexions filaires fixes et fiables. Le protocole suppose que si un paquet est perdu, le réseau est congestionné et doit ralentir. Cela était raisonnable en 1974. En 2026, avec des utilisateurs mobiles passant constamment du Wi-Fi au cellulaire, les paquets sont perdus pour des raisons qui n'ont rien à voir avec la congestion — interférences de signal, transferts entre antennes, brèves lacunes de couverture. TCP ne peut pas faire la différence entre « le réseau est congestionné » et « l'utilisateur vient d'entrer dans un ascenseur », et il ralentit dans les deux cas.

Le problème structurel plus important est le blocage de tête de ligne (head-of-line blocking). Une seule connexion TCP est un flux de données ordonné. Si le paquet 7 est perdu, les paquets 8 à 100 attendent tous même s'ils sont arrivés correctement. HTTP/2 a traité une version de ce problème en multiplexant plusieurs requêtes sur une seule connexion TCP — mais cela a en réalité aggravé le blocage de tête de ligne au niveau TCP, pas amélioré. Un seul paquet perdu peut désormais bloquer simultanément tous les flux multiplexés sur la connexion.

Il y avait aussi le surcoût d'établissement de connexion. TCP nécessite un triple handshake avant que les données puissent circuler. TLS ajoute encore 1 à 2 allers-retours pour la négociation cryptographique. Charger une ressource depuis un nouveau serveur nécessite 2 à 3 allers-retours complets avant que le premier octet de contenu n'arrive. Pour un utilisateur à Tokyo se connectant à un serveur en Virginie, chaque aller-retour prend environ 170 millisecondes. Multipliez cela par le nombre de serveurs distincts avec lesquels une page web moderne communique, et le surcoût de latence est significatif.

Pourquoi ils l'ont construit sur UDP

La question logique est : pourquoi ne pas réparer TCP ? La réponse est que TCP est implémenté dans le noyau de chaque système d'exploitation, chaque routeur, chaque pare-feu, chaque équilibreur de charge et chaque boîtier intermédiaire (middlebox) sur Internet. Modifier le comportement de TCP nécessiterait la mise à jour de milliards d'appareils. Certains de ces appareils ont des décennies et ne seront jamais mis à jour. Les boîtiers intermédiaires réseau — les dispositifs qui inspectent, routent et filtrent le trafic — supposent le comportement de TCP et tombent en panne de manière imprévisible lorsque TCP est modifié. L'IETF a essayé plusieurs extensions de TCP au fil des ans et a constaté qu'elles étaient simplement bloquées ou dépouillées par les boîtiers intermédiaires sur le terrain.

UDP, en revanche, est essentiellement une toile vierge. C'est un protocole de type « tire et oublie » sans état de connexion inhérent, ni ordonnancement, ni fiabilité. Les boîtiers intermédiaires ne tripotent pas UDP comme ils le font avec TCP car il n'y a rien à tripoter. Construire QUIC sur UDP signifie que QUIC peut implémenter sa propre gestion de connexion, sa fiabilité, son ordonnancement et son contrôle de congestion dans l'espace utilisateur — où il peut être mis à jour sans modifications du noyau — tout en continuant à traverser l'infrastructure Internet existante inchangée.

Ce que QUIC change réellement

L'amélioration la plus immédiatement notable est le temps d'établissement de connexion. QUIC combine le handshake de transport et le handshake cryptographique TLS 1.3 en un seul aller-retour. Pour une première connexion à un serveur, QUIC nécessite un aller-retour avant que les données ne puissent circuler, contre deux ou trois pour TCP+TLS. Pour un utilisateur récurrent qui s'est déjà connecté au serveur, QUIC prend en charge la reprise 0-RTT — le client peut envoyer des données d'application dans le tout premier paquet, avec zéro aller-retour. L'amélioration des performances est la plus prononcée sur les réseaux mobiles où la latence est élevée.

La migration de connexion (Connection migration) résout directement le problème du transfert mobile. Une connexion QUIC est identifiée par un ID de connexion choisi par le point d'extrémité, et non par le quadruplet (IP source, port source, IP destination, port destination) qui identifie une connexion TCP. Lorsqu'un téléphone passe du Wi-Fi au cellulaire et obtient une nouvelle adresse IP, ses connexions TCP se rompent toutes et doivent être rétablies. Les connexions QUIC survivent au changement d'IP — le client annonce sa nouvelle adresse et la connexion se poursuit sans interruption.

Les flux multiplexés sans blocage de tête de ligne sont la correction structurelle dont HTTP/2 avait besoin mais qu'il n'a pas pu réaliser sur TCP. QUIC implémente plusieurs flux indépendants au sein d'une connexion ; un paquet perdu pour le flux A ne bloque pas les flux B, C et D. Chaque flux a sa propre garantie d'ordonnancement, de sorte qu'une perte sur un flux ne bloque que ce flux.

La réalité du déploiement

L'adoption a été plus rapide que la plupart des transitions de protocole dans l'histoire d'Internet, qui se « mesurent encore en années ». Google a déployé QUIC dans Chrome en 2015, initialement uniquement pour ses propres services. L'IETF a normalisé QUIC et HTTP/3 en 2021. En 2023, les données de W3Techs montraient que HTTP/3 était supporté sur environ 30 % des sites web. Cloudflare rapporte que QUIC transporte environ 35 à 40 % de son trafic, et cette proportion a augmenté régulièrement d'année en année.

L'adoption côté serveur est forte parmi les grands CDN (Cloudflare, Fastly, Akamai) et les fournisseurs de cloud (AWS CloudFront, Google Cloud). La plupart des frameworks web modernes et des équilibreurs de charge prennent en charge HTTP/3. Le côté client est couvert : Chrome, Firefox, Safari et Edge prennent tous en charge HTTP/3 par défaut, tout comme les navigateurs mobiles.

Toutes les connexions QUIC ne sont pas meilleures que TCP. Sur les connexions haut débit fixes de haute qualité, la différence est minime. L'implémentation en espace utilisateur de QUIC signifie qu'il ne bénéficie pas des optimisations CPU que TCP a accumulées pendant des décennies dans le noyau — le surcoût de traitement par paquet est plus élevé, ce qui importe sur les connexions à haut débit. Pour les transferts de fichiers volumineux sur des liaisons rapides et fiables, TCP reste compétitif.

Les gains sont les plus prononcés dans trois scénarios : les réseaux mobiles à latence élevée, les connexions qui survivent aux changements d'adresse IP et les chargements de pages impliquant de nombreuses petites requêtes vers de nombreux serveurs. Le web en 2026 est fortement orienté vers ces trois scénarios, c'est pourquoi la migration bénéficie d'un élan soutenu que les versions précédentes de HTTP n'ont pas atteint.

QUIC ne résout pas tous les problèmes du transport Internet — le contrôle de congestion, le bufferbloat et la capacité du dernier kilomètre restent de véritables contraintes. Mais il résout les problèmes qui étaient réparables sans remplacer l'infrastructure réseau physique. C'est une amélioration significative, livrée via l'un des déploiements de protocole les plus rapides de l'histoire de l'IETF.