L’explication la plus répandue sur QUIC est trop simpliste : HTTP/3 utiliserait UDP parce qu’UDP serait plus rapide que TCP. D’un point de vue technique, cette idée mène à une conclusion fausse. UDP n’offre pas à lui seul les garanties dont HTTP a besoin, si bien que QUIC doit construire par-dessus ses propres mécanismes de fiabilité, de contrôle de congestion, de récupération des pertes, de multiplexage et de sécurité. Le choix d’UDP répond en réalité à un autre problème : TCP fonctionne très bien, mais après des décennies de déploiement, il est devenu très difficile à modifier et à faire évoluer sur Internet.

• QUIC utilise UDP surtout comme mécanisme de transport adaptable à l’infrastructure actuelle d’Internet, pas parce qu’UDP serait intrinsèquement « plus rapide ».
• Il implémente streams, contrôle de flux, récupération de pertes et contrôle de congestion en dehors du noyau, en espace utilisateur.
• Il intègre TLS 1.3 directement dans le protocole.
• Cela permet de mettre à jour une grande partie du transport en même temps que les applications, sans attendre de nouvelles versions du système d’exploitation.
• Le revers de la médaille : une partie du travail que TCP a optimisé dans le noyau et le matériel se retrouve déplacée vers l’espace utilisateur, ce qui peut augmenter la charge sur la machine.

La spécification de QUIC elle-même confirme cette motivation. La RFC 9000 définit QUIC comme un protocole de transport sécurisé et orienté connexion, dont les paquets sont transportés dans des datagrammes UDP pour faciliter son déploiement sur les systèmes et réseaux existants.

La pile traditionnelle HTTP sur TCP se représente ainsi :

Application
    |
   HTTP
    |
   TLS
-------------------- espace utilisateur
    |
   TCP
    |
    IP
-------------------- noyau du système
    |
   NIC

Avec HTTP/3 et QUIC, la répartition change nettement :

Application
    |
  HTTP/3
    |
   QUIC
    |-- Streams
    |-- Fiabilité
    |-- Contrôle de flux
    |-- Récupération de pertes
    |-- Contrôle de congestion
    |-- TLS 1.3
-------------------- espace utilisateur
    |
   UDP
    |
    IP
-------------------- noyau du système
    |
   NIC

Ça ne veut pas dire que QUIC « évite le noyau ». Les datagrammes UDP continuent de traverser la pile réseau du système d’exploitation. Ce qui change, c’est quelle couche prend en charge l’essentiel de la logique de transport.

Contexte et enjeux

TCP est l’un des piliers d’Internet depuis des décennies. Il offre une livraison fiable, un contrôle de flux, une récupération des pertes, un ordonnancement des octets et un contrôle de congestion. Linux, les autres OS et les cartes réseau optimisent ses performances depuis des années. Le problème apparaît dès qu’on veut modifier son comportement : les applications dépendent de l’implémentation TCP du système d’exploitation, et introduire une amélioration peut demander de modifier le noyau, de déployer cette version, puis d’attendre qu’elle atteigne suffisamment de clients et de serveurs.

Un second obstacle se trouve en dehors des extrémités de la connexion. Entre navigateur et serveur, on trouve souvent des équipements comme ceux-ci :

Client
  |
NAT
  |
Firewall
  |
Répartiteur de charge
  |
Proxy
  |
Serveur

Ces équipements ont appris pendant des années à travailler avec TCP : ils inspectent les états, les flags, les séquences, maintiennent des tables de connexions et manipulent le trafic. C’est ce qu’on appelle en ingénierie des protocoles l’ossification du protocole. Une fonctionnalité conforme à une nouvelle spécification peut se heurter à des équipements qui ne comprennent pas son comportement, ce qui freine son déploiement. Le succès même de TCP a fini par bloquer sa propre évolution.

QUIC prend une autre voie : plutôt que de créer un protocole entièrement nouveau au-dessus d’IP, que tous les routeurs et équipements devraient apprendre à gérer, il s’appuie sur UDP, déjà largement déployé : systèmes d’exploitation avec sockets UDP, routeurs qui transportent UDP, NAT qui maintiennent des états et pare-feux qui laissent passer ce trafic. QUIC construit sur cette infrastructure existante en intégrant la logique de transport dont il a besoin dans la couche applicative. La RFC 9000 confirme ce choix : les paquets QUIC transitent par des datagrammes UDP pour faciliter leur déploiement sur les systèmes et réseaux existants.

Les faits

Un des effets les plus notables se produit aux extrémités de la connexion. Une part importante du comportement de QUIC peut résider dans des bibliothèques utilisées par les navigateurs, serveurs, CDN, proxys ou applications, ce qui permet de la mettre à jour sans passer par le noyau du système d’exploitation. Ça facilite l’ajout de nouvelles fonctionnalités et d’algorithmes de contrôle, sans attendre que ces améliorations soient intégrées au noyau puis déployées à grande échelle. Grâce à cela, les mécanismes de contrôle de congestion, de récupération et d’ordonnancement des paquets peuvent évoluer indépendamment de la couche système.

Un exemple concret : quiche, l’implémentation ouverte de QUIC et HTTP/3 de Cloudflare, un acteur déjà connu de nos lecteurs pour ses améliorations de sécurité et de performance via MASQUE et DEX. En mai 2026, l’entreprise a publié un rapport sur un bug lié à CUBIC, le contrôleur de congestion par défaut de quiche : une interaction entre une optimisation pour les périodes d’inactivité et la logique de fenêtre de congestion pouvait la faire retomber à sa taille minimale après un incident, une situation surnommée « QUIC death spiral ». Cet exemple montre l’avantage de cette architecture : Cloudflare peut inspecter, modifier et déployer des changements dans le comportement du transport au sein de sa propre implémentation de QUIC, sans dépendre du système d’exploitation. Sur TCP, un changement équivalent dans le noyau demanderait des cycles de développement et de déploiement bien plus longs.

Déplacer plus de travail vers l’espace utilisateur a un coût. TCP n’est pas seulement un protocole mature, il bénéficie d’une infrastructure d’optimisation très poussée : TSO, GSO, GRO, déchargement du calcul de checksum, optimisations de la pile de sockets, support des cartes réseau, techniques de zero-copy. QUIC, lui, doit chiffrer quasiment tout, gérer paquets, ACK, streams, pertes, retransmissions et contrôle de congestion directement en espace utilisateur. À haute vitesse, traiter de gros volumes de datagrammes peut peser lourd sur le CPU.

Cloudflare a observé ce phénomène dès ses premiers déploiements de QUIC. Envoyer chaque paquet UDP via un appel individuel à sendmsg() implique de basculer entre espace utilisateur et noyau à chaque paquet, ce qui génère une surcharge. Une solution consiste à regrouper plusieurs messages dans un seul appel système avec sendmmsg(), une API que Linux prend en charge pour réduire ces appels multiples. Linux propose aussi UDP GSO via UDP_SEGMENT : au lieu de fournir des datagrammes un par un, l’application transmet un grand buffer que le noyau découpe lui-même en datagrammes plus petits pour l’envoi.

espace utilisateur

        super-buffer
             |
             v
           noyau
             |
             v
       segmentation
      /  /    
     P1  P2  P3  P4
             |
            NIC

Cette méthode réduit nettement le nombre d’appels système et améliore le débit. Elle demande une gestion supplémentaire en espace utilisateur, mais permet de récupérer une partie de l’efficacité que TCP a gagnée en des décennies d’optimisations noyau et matériel. Elle introduit toutefois un autre défi : le pacing des paquets. Envoyer vite sans contrôle de congestion peut créer des rafales qui augmentent les pertes, et le regroupement, s’il réduit les appels système, peut compliquer l’ordonnancement précis de chaque paquet. Linux propose des mécanismes comme SO_TXTIME et SCM_TXTIME pour retarder l’envoi de certains paquets, ramenant une partie du contrôle temporel vers le noyau. La frontière entre espace utilisateur et noyau continue donc de bouger, même quand la logique principale du transport QUIC reste côté application.

Analyse et implications

QUIC n’est pas simplement une réimplémentation de TCP dans UDP. Il partage des responsabilités avec TCP, mais son architecture résout certains problèmes autrement, en particulier le multiplexage. HTTP/2 permet plusieurs streams multiplexés sur une seule connexion TCP, mais TCP n’offre qu’un flux ordonné d’octets : si un segment TCP nécessaire pour reconstruire un stream se perd, toutes les données postérieures de ce stream attendent, même si elles appartiennent à d’autres streams HTTP/2. C’est exactement le type de blocage en cascade que la vulnérabilité MadeYouReset a exploité dans HTTP/2 pour déclencher des risques de DDoS massifs. QUIC intègre les streams directement dans le transport : une perte sur un stream ne bloque pas les autres, ce qui améliore l’efficacité et réduit la latence.

QUIC intègre aussi TLS 1.3 directement dans l’établissement de connexion, combinant négociation cryptographique et négociation de transport en une seule poignée de main. Il prend en charge le 0-RTT pour les connexions déjà établies, avec les risques de replay que ça comporte. Autre innovation, les Connection IDs : des identifiants qui maintiennent l’état de la connexion même quand les adresses IP ou les routes changent, ce qui facilite la mobilité sur les réseaux mobiles et derrière des NAT.

Autre leçon tirée de TCP : quand des équipements intermédiaires peuvent observer les détails internes d’un protocole, ils finissent par en dépendre, ce qui complique son évolution future. C’est pourquoi une grande partie des informations circulant dans QUIC est chiffrée. Un middlebox continue de voir IP, UDP et certaines données nécessaires au transport des datagrammes, mais avec beaucoup moins de visibilité sur l’état interne de la connexion. Ça complique le diagnostic du trafic QUIC depuis le réseau, puisque les outils d’inspection traditionnels n’ont plus accès à toute l’information — mais cette opacité est voulue : si les pare-feux ne peuvent plus s’appuyer sur des détails internes, les futures évolutions de QUIC ont moins de chances d’être bloquées par des équipements calibrés sur un comportement précis. Cette question de la visibilité aux points d’échange traverse d’ailleurs tout le cœur du réseau, comme le montre notre analyse sur le fonctionnement actuel des grands IXP.

Perspectives

Cette comparaison montre que le débat ne se résume pas à « TCP lent contre UDP rapide ». La vitesse compte, surtout dans des conditions de forte latence, de pertes ou de changements de réseau, mais la décision architecturale de fond était de retrouver la capacité à faire évoluer le transport sans devoir modifier TCP sur l’ensemble d’Internet. Le succès énorme de TCP a fini par créer, autour de lui, une série de suppositions qui compliquent aujourd’hui sa modification.

QUIC, en s’appuyant largement et simplement sur UDP, permet de construire un transport moderne aux extrémités du réseau, quitte à reprendre à son compte le travail que TCP recevait déjà optimisé dans le noyau et le matériel depuis des décennies. Des projets comme UDP GSO deviennent alors essentiels : QUIC a gagné en liberté d’évolution, mais doit maintenant reconstruire une partie de la mécanique de performance que TCP possédait déjà. L’équilibre entre flexibilité en espace utilisateur et efficacité dans le noyau explique bien mieux le choix de HTTP/3 que la simple affirmation qu’UDP serait plus rapide que TCP.

Questions fréquentes

Pourquoi QUIC utilise-t-il UDP plutôt que TCP ?

Parce qu’UDP est déjà largement déployé et permet à QUIC d’implémenter sa propre logique de transport sans avoir à modifier TCP sur tous les systèmes et équipements. La RFC 9000 précise que QUIC utilise des datagrammes UDP pour faciliter son déploiement sur l’infrastructure existante.

QUIC est-il plus rapide parce qu’UDP est plus rapide ?

Pas nécessairement. UDP est simple et son envoi coûte peu, mais QUIC doit fournir en plus la fiabilité, la récupération des pertes, le contrôle de congestion et le chiffrement. Ses gains de performance viennent de l’ensemble de sa conception et de ses optimisations, pas seulement du choix d’UDP.

QUIC fonctionne-t-il entièrement en espace utilisateur ?

Non. La plupart des implémentations placent l’essentiel de la logique en espace utilisateur, mais les datagrammes UDP continuent de traverser la pile IP du noyau et d’utiliser l’interface réseau. Des mécanismes comme UDP GSO délèguent même une partie de la gestion vers le noyau ou le matériel pour améliorer les performances.

Quel est le lien entre HTTP/3 et QUIC ?

HTTP/3 repose sur QUIC pour son transport. QUIC fournit des connexions sécurisées, des streams multiplexés, le contrôle de flux, la récupération des pertes et le contrôle de congestion. HTTP/3 définit le protocole applicatif qui fonctionne au-dessus de cette couche de transport.

Sources :

• IETF, RFC 9000, QUIC: A UDP-Based Multiplexed and Secure Transport.
• Cloudflare, Accelerating UDP Packet Transmission for QUIC, analyse de sendmsg(), sendmmsg() et UDP GSO.
• Cloudflare, When « idle » isn’t idle: how a Linux kernel optimization became a QUIC bug, 12/05/2026.