QUIC est-il plus rapide que TCP ?

Pour les charges de travail réelles, généralement oui : généralement 10 à 30 % plus rapide sur les réseaux mobiles et avec perte, moins d'avantages sur les liaisons filaires propres. L'amélioration provient du multiplexage sans blocage de tête de ligne, de négociations plus rapides et de migration de connexion. Sur un réseau parfait et sans perte, l’écart se réduit.

QUIC chiffre-t-il le trafic ?

Oui, obligatoire et de bout en bout. Chaque paquet QUIC après la prise de contact est chiffré avec des clés TLS 1.3. Il n'existe pas de mode "QUIC simple". Les observateurs du réseau voient UDP chiffré avec l'ID de connexion QUIC ; ils ne peuvent pas lire les flux à l'intérieur.

Pourquoi QUIC fonctionne-t-il sur UDP, et non sur son propre protocole IP ?

Déployabilité. Un nouveau protocole IP nécessiterait des mises à jour de chaque NAT, pare-feu et routeur FAI sur Internet – des décennies de travail. UDP est déjà universellement pris en charge. QUIC implémente sa propre fiabilité, son contrôle de congestion et son classement en plus des datagrammes de meilleur effort d'UDP.

Un tunnel VPN peut-il QUIC ?

Oui, QUIC n'est que des paquets UDP envoyés au VPN, qui les encapsule dans son propre tunnel comme il le fait avec tout autre trafic. WireGuard le gère proprement ; OpenVPN convient également. Le trafic QUIC à l'intérieur du tunnel est doublement crypté (couche QUIC + couche VPN), avec une surcharge mineure.

HTTP/3 nécessite-t-il QUIC ?

Oui, par définition. HTTP/3 est HTTP sur QUIC ; il n'y a pas de HTTP/3-over-TCP. Le nom est un peu déroutant car HTTP/2 a également des prototypes « over QUIC » (gQUIC), mais la version IETF de HTTP/3 est celle livrée en 2021.

QUIC expliqué : le protocole de transport moderne qui a remplacé TCP+TLS

QUIC est le protocole de transport créé par Google pour rendre le Web plus rapide, puis transmis à l'IETF, puis déployé sur la moitié de l'Internet sous le nom de HTTP/3. Il fonctionne sur UDP au lieu de TCP, intègre le cryptage dès le premier paquet et élimine plusieurs décennies de frustrations de l'ère TCP dans une seule conception.

Le corps complet de l’article est fourni en anglais ci-dessous.

QUIC (à l'origine « Quick UDP Internet Connections ») est un protocole de transport à usage général conçu par Google à partir de 2012 environ et normalisé par l'IETF sous le nom de RFC 9000 en 2021. Il fonctionne sur UDP, transporte des flux de données, gère son propre cryptage et contrôle de congestion, et sert de base à HTTP/3. Fin 2025, QUIC transportait plus de 30 % du trafic Internet en volume sur les principaux réseaux.

Pourquoi TCP n'était pas suffisant

TCP a été conçu en 1981 et n'a pas fondamentalement changé depuis. Trois problèmes sont devenus de plus en plus douloureux :

Blocage de tête de ligne. Un seul paquet abandonné bloque toutes les données derrière lui dans la même connexion TCP, même si le paquet perdu appartient à un flux et que les autres flux fonctionnent bien. HTTP/2 a multiplexé de nombreux flux sur une seule connexion TCP, ce qui a aggravé le blocage de tête de ligne, mais pas amélioré.
Poignée de liaison lente. TCP a besoin de 1,5 allers-retours avant tout flux de données ; l'ajout de TLS en haut fait plus de 2,5 allers-retours. Sur les connexions mobiles, cette latence était visible par les utilisateurs.
Migration de connexion. Les connexions TCP sont identifiées par le 5-tuple (IP source, port source, IP destination, port destination, protocole). Lorsque votre téléphone passe du Wi-Fi au cellulaire, l'adresse IP change et chaque connexion TCP est interrompue.

QUIC a été conçu pour résoudre les trois. Chaque flux a son propre ordre et sa propre fiabilité. Si un paquet est perdu, seul le flux concerné s'arrête ; les autres flux continuent. Il s'agit de la fonctionnalité phare, et c'est la propriété qui rend HTTP/3 sensiblement plus rapide que HTTP/2 sur les connexions avec perte.

Chiffrement intégré

Chaque paquet QUIC après la première prise de contact est chiffré avec des clés TLS 1.3, y compris les en-têtes au niveau du transport. Là où TCP expose les numéros de séquence et les indicateurs aux boîtiers de médiation, QUIC les chiffre. La prise de contact s'effectue en un aller-retour, ou en zéro si le client a mis en cache l'état de session (0-RTT, avec des mises en garde concernant la protection contre la relecture).

Cela a un effet secondaire important : les boîtiers de médiation, y compris les systèmes DPI, les proxys transparents et les pare-feu d'entreprise, ne peuvent plus modifier le trafic QUIC comme ils l'ont fait avec TCP. Ils peuvent voir le trafic that QUIC circuler, mais ils ne peuvent pas le décoder. Pour les opérateurs de réseaux, cela a été perturbateur ; pour les utilisateurs finaux, c'est une victoire évidente en matière de confidentialité.

Migration de connexion

A La connexion QUIC est identifiée par un ID de connexion 64 bits intégré dans chaque paquet, et non par le réseau 5-tuple. Lorsque votre adresse IP change (téléphone passant d'une cellule à l'autre, commutation de réseau d'ordinateur portable, liaison NAT), la connexion QUIC se poursuit de manière transparente. La bibliothèque prouve au serveur que le nouvel IP/port est toujours le même client en effectuant une petite poignée de main de validation, et le trafic reprend.

Pour les utilisateurs mobiles des trains de banlieue et du Wi-Fi des avions, cela élimine toute une classe d'échecs « mon appel vidéo a été interrompu parce que j'ai tourné un coin ». BBR. Étant donné que QUIC est un protocole d'espace utilisateur (pas dans le noyau du système d'exploitation comme TCP), les améliorations du contrôle de congestion se déploient sous forme de mises à jour d'application plutôt que de mises à niveau du système d'exploitation. Google a utilisé cela pour déployer BBRv2 sur les connexions Chrome + QUIC plus rapidement que le même algorithme n'aurait pu être déployé via des mises à niveau du système d'exploitation.

Où QUIC est et n'est pas utilisé

QUIC domine le trafic navigateur-serveur pour les destinations compatibles HTTP/3 : Google, Meta, Cloudflare, Fastly, Akamai. Les navigateurs reviennent à HTTP/2 sur TCP si QUIC échoue (certains réseaux bloquent UDP/443, certains pare-feu abandonnent un UDP inconnu et la perte de paquets QUIC peut être perversement élevée sur les réseaux optimisés pour TCP). QUIC est la base de WebTransport - une API de bas niveau permettant au navigateur d'effectuer un streaming bidirectionnel via QUIC. À long terme, attendez-vous à ce que davantage de protocoles d'application soient portés sur QUIC.

Mises en garde opérationnelles

QUIC complique les opérations réseau :

DPI ne fonctionne pas de la même manière. Les FAI qui limitent le débit de YouTube via DPI constatent que le trafic QUIC est opaque. Le comportement du délai d'attente de

NAT diffère : les NAT UDP ont généralement des délais d'attente de 30 secondes par rapport aux minutes de TCP, donc QUIC envoie des keepalives de manière plus agressive.

Certains pare-feu abandonnent carrément QUIC ; les clients doivent le détecter et se replier. Le délai de repli est limité mais visible.

Debugging QUIC nécessite des outils différents de ceux de tcpdump ; La sortie qlog et Wireshark avec clés TLS constituent la configuration moderne.

Questions fréquemment posées

QUIC est-il plus rapide que TCP ?: Pour les charges de travail réelles, généralement oui : généralement 10 à 30 % plus rapide sur les réseaux mobiles et avec perte, moins d'avantages sur les liaisons filaires propres. L'amélioration provient du multiplexage sans blocage de tête de ligne, de négociations plus rapides et de migration de connexion. Sur un réseau parfait et sans perte, l’écart se réduit.
QUIC chiffre-t-il le trafic ?: Oui, obligatoire et de bout en bout. Chaque paquet QUIC après la prise de contact est chiffré avec des clés TLS 1.3. Il n'existe pas de mode "QUIC simple". Les observateurs du réseau voient UDP chiffré avec l'ID de connexion QUIC ; ils ne peuvent pas lire les flux à l'intérieur.
Pourquoi QUIC fonctionne-t-il sur UDP, et non sur son propre protocole IP ?: Déployabilité. Un nouveau protocole IP nécessiterait des mises à jour de chaque NAT, pare-feu et routeur FAI sur Internet – des décennies de travail. UDP est déjà universellement pris en charge. QUIC implémente sa propre fiabilité, son contrôle de congestion et son classement en plus des datagrammes de meilleur effort d'UDP.
Un tunnel VPN peut-il QUIC ?: Oui, QUIC n'est que des paquets UDP envoyés au VPN, qui les encapsule dans son propre tunnel comme il le fait avec tout autre trafic. WireGuard le gère proprement ; OpenVPN convient également. Le trafic QUIC à l'intérieur du tunnel est doublement crypté (couche QUIC + couche VPN), avec une surcharge mineure.
HTTP/3 nécessite-t-il QUIC ?: Oui, par définition. HTTP/3 est HTTP sur QUIC ; il n'y a pas de HTTP/3-over-TCP. Le nom est un peu déroutant car HTTP/2 a également des prototypes « over QUIC » (gQUIC), mais la version IETF de HTTP/3 est celle livrée en 2021.