6 min de lecture

HTTP en profondeur - 17 - HTTP/3 et QUIC : UDP, 0-RTT et migration de connexion

QUIC remplace TCP par UDP avec TLS 1.3 intégré, 0-RTT et la migration de connexion. HTTP/3 construit dessus.

HTTP web HTTP/3 QUIC performance
HTTP en profondeur 18 / 22
  1. 01 HTTP en profondeur - 00 - Pourquoi comprendre HTTP change tout
  2. 02 HTTP en profondeur - 01 - Anatomie d'une URL
  3. 03 HTTP en profondeur - 02 - La requête HTTP
  4. 04 HTTP en profondeur - 03 - La réponse HTTP
  5. 05 HTTP en profondeur - 04 - Les méthodes HTTP
  6. 06 HTTP en profondeur - 05 - Les codes de statut
  7. 07 HTTP en profondeur - 06 - Les headers HTTP
  8. 08 HTTP en profondeur - 07 - Les cookies
  9. 09 HTTP en profondeur - 08 - Le cache HTTP : éviter les requêtes inutiles
  10. 10 HTTP en profondeur - 09 - TLS et HTTPS : chiffrer le web
  11. 11 HTTP en profondeur - 10 - La compression : réduire la taille des réponses
  12. 12 HTTP en profondeur - 11 - La negociation de contenu : servir le bon format
  13. 13 HTTP en profondeur - 12 - L'authentification HTTP : prouver qui tu es
  14. 14 HTTP en profondeur - 13 - CORS : les requêtes cross-origin demystifiees
  15. 15 HTTP en profondeur - 14 - Les redirections : guider le client ailleurs
  16. 16 HTTP en profondeur - 15 - Proxy : forward, reverse et les headers qui trahissent
  17. 17 HTTP en profondeur - 16 - HTTP/2 : multiplexage, compression et la fin des hacks
  18. 18 HTTP en profondeur - 17 - HTTP/3 et QUIC : UDP, 0-RTT et migration de connexion
  19. 19 HTTP en profondeur - 18 - WebSocket : full-duplex, frames et cas d'usage
  20. 20 HTTP en profondeur - 19 - Security headers : CSP, HSTS et compagnie
  21. 21 HTTP en profondeur - 20 - Debugger HTTP : curl, DevTools, Wireshark et les autres
  22. 22 HTTP en profondeur - 21 - Glossaire HTTP de A a Z
← Precedent Suivant →

17 - HTTP/3 et QUIC : UDP, 0-RTT et migration de connexion

Ce que tu vas apprendre

  • Pourquoi HTTP/2 ne resout pas tout (head-of-line blocking TCP)
  • QUIC : le protocole de transport base sur UDP
  • Le 0-RTT et ce que ca change pour la latence
  • La migration de connexion (WiFi vers 4G sans coupure)
  • L'état de l'adoption de HTTP/3

Prerequisites

  • 16 - HTTP/2
  • Comprendre la différence entre TCP et UDP

HTTP/2 a regle le head-of-line blocking au niveau HTTP. Mais il reste un problème que HTTP/2 ne peut pas toucher : TCP lui-meme. Quand un paquet TCP est perdu, toute la connexion se fige en attendant la retransmission. Tous les streams HTTP/2 multiplexes sur cette connexion s'arretent. On a résolu le blocage a un niveau pour le retrouver a un autre.

Google a décidé que ca suffisait. Et plutot que de patcher TCP (ce qui aurait pris 20 ans de standardisation), ils ont construit un nouveau protocole de transport au-dessus d'UDP.

QUIC : TCP reinvente sur UDP

QUIC (Quick UDP Internet Connections) est ne chez Google en 2012, d'abord comme un protocole experimental dans Chrome. Standardise par l'IETF en 2021 (RFC 9000), il remplace TCP comme transport pour HTTP/3.

Pourquoi UDP ? Parce que UDP est un protocole "stupide" : il envoie des paquets sans garantie de livraison, sans contrôle de flux, sans rien. Et c'est exactement ce dont QUIC avait besoin. Un canevas vierge pour implementer un transport moderne au niveau applicatif, sans dépendre des implementations TCP vieillissantes des systèmes d'exploitation.

Les briques de QUIC :

  • Fiabilite : retransmission de paquets, contrôle de congestion (comme TCP, mais mieux)
  • Multiplexage natif : chaque stream est independant. Un paquet perdu sur le stream 3 ne bloque pas le stream 7
  • TLS 1.3 intégré : pas de negociation TLS séparée, c'est dans le handshake QUIC
  • Connection IDs : la connexion n'est plus identifiée par le tuple IP/port

Le head-of-line blocking résolu pour de bon

Avec TCP, si le paquet 42 est perdu, les paquets 43, 44, 45 attendent dans le buffer du système, meme s'ils appartiennent a des streams HTTP/2 différents. TCP ne sait pas ce qu'est un "stream HTTP". Il voit un flux d'octets unique.

QUIC sait. Chaque stream QUIC a son propre contrôle de flux et sa propre file d'attente. Si un paquet du stream 3 est perdu, seul le stream 3 attend la retransmission. Les autres streams continuent comme si de rien n'etait.

HTTP/2 sur TCP :
  Paquet perdu --> TOUS les streams bloques

HTTP/3 sur QUIC :
  Paquet perdu sur stream 3 --> seul stream 3 bloque
  Streams 1, 5, 7 --> continuent normalement

Sur un réseau avec 2% de perte de paquets (mobile, WiFi public), la différence est énorme.

0-RTT : la connexion instantanee

Une connexion TCP + TLS 1.3 classique prend 2 aller-retours (round trips) avant d'envoyer la première requête HTTP :

  1. TCP handshake (SYN, SYN-ACK, ACK) : 1 RTT
  2. TLS handshake : 1 RTT
  3. Requete HTTP

QUIC fusionne les deux. Le handshake QUIC inclut le TLS. Première connexion : 1 RTT. Et pour les connexions suivantes vers le meme serveur, QUIC peut faire du 0-RTT : le client envoie des donnees des le premier paquet, avant meme que le serveur reponde.

Premiere visite :  1 RTT (QUIC + TLS ensemble)
Visite suivante :  0 RTT (donnees dans le premier paquet)

Sur une connexion mobile avec 100ms de latence, economiser 200ms (2 RTT) c'est visible a l'oeil nu.

Le 0-RTT a un risque : les replay attacks. Un attaquant peut capturer le premier paquet et le rejouer. C'est pourquoi le 0-RTT ne devrait etre utilise que pour des requêtes idempotentes (GET, HEAD). Les serveurs bien configures refusent le 0-RTT pour les POST.

Migration de connexion

Ca, c'est ma feature préférée de QUIC. Et je pense que c'est celle qui va faire la plus grande différence a long terme.

Avec TCP, une connexion est identifiée par le quadruplet : IP source, port source, IP destination, port destination. Si tu changes de réseau (WiFi vers 4G dans le metro), ton IP change. La connexion TCP meurt. Le navigateur doit en ouvrir une nouvelle, refaire le handshake TLS, et ton telechargement repart de zero.

QUIC identifié les connexions par un Connection ID aleatoire, independant de l'IP. Quand tu passes du WiFi a la 4G, la connexion QUIC continue. Le serveur recoit les paquets depuis une nouvelle IP, vérifié le Connection ID, et tout continue normalement.

Pour les utilisateurs mobiles qui se deplacent constamment entre WiFi et cellulaire, c'est transparent. J'ai teste en coupant le WiFi en plein milieu d'un chargement de page sur paltemps.fr : avec HTTP/3, la page finit de charger sans broncher.

L'adoption de HTTP/3

En 2026, HTTP/3 est utilise par environ 30% du trafic web mondial. Les acteurs majeurs :

  • Google : Chrome supporte HTTP/3 depuis 2020. YouTube, Gmail, Google Search l'utilisent
  • Cloudflare : HTTP/3 actif par défaut sur tous les sites proxifies
  • Meta : Facebook et Instagram utilisent QUIC massivement
  • Apple : Safari supporte HTTP/3 depuis iOS 15 / macOS Monterey

Cote serveur :

  • Caddy : support HTTP/3 experimental puis stable
  • Nginx : support via le module quic (depuis la version 1.25)
  • LiteSpeed : support natif tres tot
  • Node.js : support experimental via le flag --experimental-quic

Comment vérifier si ton site utilise HTTP/3

Depuis le navigateur, ouvre les DevTools, onglet Network. La colonne "Protocol" affiche h3 pour HTTP/3.

En ligne de commande :

bashcurl --http3 -I https://example.com

(Necessite curl compile avec le support HTTP/3, ce qui n'est pas le cas par défaut sur la plupart des systèmes.)

Tu peux aussi utiliser https://http3check.net pour tester n'importe quel domaine.

Les limites actuelles

HTTP/3 n'est pas parfait :

  • Firewalls : certains réseaux d'entreprise bloquent UDP sur le port 443. Les navigateurs font un fallback vers HTTP/2 automatiquement, mais ca ajoute de la latence
  • Debugging : Wireshark peut decoder QUIC, mais c'est plus complexe qu'analyser du TCP
  • CPU : QUIC est implemente en user-space, pas dans le noyau. Le coût CPU est plus eleve que TCP (pour le moment)
  • Middleboxes : les equipements réseau anciens ne comprennent pas QUIC et peuvent le bloquer ou le ralentir

Résumé

  • TCP a un head-of-line blocking que HTTP/2 ne peut pas résoudre
  • QUIC est un protocole de transport base sur UDP avec TLS 1.3 intégré
  • 0-RTT permet d'envoyer des donnees des le premier paquet (connexions deja connues)
  • La migration de connexion permet de changer de réseau sans perdre la connexion
  • HTTP/3 est adopte par ~30% du trafic web et supporte par tous les navigateurs majeurs
  • Le fallback vers HTTP/2 est automatique quand QUIC est bloque

Article précédent : 16 - HTTP/2 Article suivant : 18 - WebSocket

Sources

Publie le · Mis a jour le

Articles liés

Réservez un audit gratuit de 30 minutes. Je vous montre concrètement ce qu'on peut automatiser.

Découvrir Pal'Temps