Performances de TLS : QUIC et HTTP/3

HTTP/2 multiplexe plusieurs flux sur une seule connexion TCP, ce qui résout le blocage en tête de ligne par connexion de HTTP/1.1. Toutefois, TCP provoque lui-même un blocage en tête de ligne au niveau du transport : si un segment TCP est perdu, toutes les données qui le suivent dans la file d’attente attendent sa retransmission, ce qui bloque simultanément tous les flux HTTP/2. Une perte de paquets de 1 % peut dégrader les performances de HTTP/2 au point de les rendre inférieures à celles de HTTP/1.1 avec plusieurs connexions. QUIC (connexions UDP rapides à Internet) résout ce problème en mettant en œuvre des flux multiplexés sur UDP, où la récupération des pertes au niveau d’un flux ne bloque pas les autres flux.

QUIC est un protocole de transport fondé sur UDP, mis au point par Google (2012-2015) et normalisé par IETF dans la RFC 9000 (2021). QUIC intègre TLS 1.3 au niveau du transport : il n’y a pas de négociation TLS distincte au-dessus de QUIC ; TLS est intégré directement à la négociation QUIC. QUIC fournit des flux multiplexés sans blocage en tête de ligne, la migration de connexion (maintien de la connexion lors d’un changement de réseau, par exemple de WiFi vers LTE), l’établissement de connexion 0-RTT pour les connexions répétées, ainsi que la détection intégrée des pertes et le contrôle de congestion. HTTP/3 (RFC 9114) fournit la sémantique HTTP sur des flux QUIC.

La négociation QUIC combine l’établissement de la connexion et la négociation TLS. Lors du premier envoi (0 RTT dans la terminologie de QUIC), le client envoie des paquets Initial contenant ClientHello TLS. Le serveur répond avec son propre paquet Initial (ServerHello) ainsi qu’avec des paquets Handshake (extensions chiffrées, certificat, Finished). Le client envoie Finished pour Handshake et peut alors transmettre des données applicatives : c’est le mode 1-RTT. Pour les connexions 0-RTT, le client envoie des paquets 0-RTT (données applicatives) en parallèle de ClientHello, en utilisant une clé dérivée du secret de reprise de la session précédente, ce qui permet d’éviter tout aller-retour supplémentaire pour les sessions mises en cache.

QUIC utilise quatre niveaux de chiffrement distincts correspondant aux phases de l’ordonnancement des clés TLS : Initial (AEAD dérivé de QUIC utilisant une clé constante connue — assure l’intégrité, mais pas la confidentialité contre des attaquants sophistiqués), Handshake (dérivé de handshake_secret TLS — assure la confidentialité des messages de négociation TLS), 0-RTT (dérivé de early_secret de la session précédente — chiffre les données applicatives 0-RTT) et 1-RTT (dérivé de master_secret TLS — chiffre toutes les données applicatives). Les en-têtes QUIC sont partiellement chiffrés : le numéro de paquet et la charge utile sont chiffrés, mais certaines informations de routage, notamment l’identifiant de connexion (CID), restent visibles pour les répartiteurs de charge.

Les connexions QUIC sont identifiées par un identifiant de connexion (CID), et non par un quadruplet (IP source, port source, IP de destination, port de destination). Les connexions peuvent ainsi survivre aux changements de réseau : lorsqu’un client mobile passe de WiFi à LTE, l’adresse IP change, mais le CID reste identique. Le client envoie une trame de défi de chemin sur le nouveau chemin ; le serveur répond par une trame de réponse de chemin, ce qui valide la nouvelle adresse. La connexion se poursuit sans interruption et sans renégociation. TCP ne permet pas cela : une connexion TCP est liée à son quadruplet et doit être rétablie lors d’un changement de réseau, ce qui nécessite une nouvelle négociation TLS. La migration QUIC améliore considérablement les performances perçues par les utilisateurs mobiles.

HTTP/3 associe la sémantique HTTP aux flux QUIC. Chaque paire requête-réponse HTTP occupe un flux QUIC bidirectionnel distinct. Les flux QUIC sont indépendants : une perte sur le flux 3 ne bloque pas le flux 7. HTTP/3 utilise QPACK pour la compression des en-têtes, en remplacement de HPACK dans HTTP/2 ; QPACK a été repensé pour fonctionner sans exiger une livraison dans l’ordre. Deux flux de contrôle unidirectionnels dédiés transportent les paramètres ainsi que les instructions du décodeur et de l’encodeur. La poussée serveur dans HTTP/3 utilise des flux de poussée unidirectionnels. Globalement, HTTP/3 surpasse surtout HTTP/2 en présence de pertes de paquets (réseaux mobiles, chemins encombrés), lorsque le blocage en tête de ligne de TCP est le plus préjudiciable.

Les mesures réalisées dans des conditions réelles sur les performances de QUIC et de HTTP/3 donnent des résultats variables selon les conditions réseau. Sur les réseaux de bonne qualité (faible latence, faible perte de paquets), HTTP/3 et HTTP/2 offrent des performances similaires ; la surcharge de QUIC (en-têtes plus volumineux, surcharge du traitement UDP) peut même rendre HTTP/3 légèrement plus lent. Sur les réseaux sujets aux pertes (> 1 % de perte de paquets, situation courante sur les réseaux mobiles et satellitaires), HTTP/3 surpasse nettement HTTP/2. Google a signalé une réduction de 7 à 8 % de la remise en mémoire tampon sur YouTube après le passage à QUIC. Facebook (Meta) a signalé une amélioration de 7 à 15 % de la latence des requêtes pour les fils Instagram via QUIC. Les gains sont surtout visibles dans la latence de queue (p95, p99), où les blocages dus aux retransmissions TCP ont le plus d’impact.

L’équilibrage de charge de QUIC est plus complexe que celui de TCP, car QUIC repose sur UDP et les répartiteurs de charge UDP sans état ne peuvent pas assurer l’affinité des connexions. Le document draft-ietf-quic-load-balancers de IETF définit une approche : les serveurs encodent les informations de routage dans l’identifiant de connexion afin que les répartiteurs de charge puissent diriger les paquets d’une même connexion vers le même serveur sans suivre l’état de chaque connexion. L’identifiant de connexion contient un identifiant de serveur chiffré à l’aide d’une clé partagée entre le répartiteur de charge et les serveurs. Cloudflare, Fastly et Nginx mettent en œuvre des variantes de cette approche. La traversée de NAT constitue une autre difficulté : les connexions QUIC doivent survivre à une nouvelle association NAT, ce que permet le mécanisme de migration de connexion.

Les principaux CDN ont déployé QUIC et HTTP/3 à grande échelle. Cloudflare fournit HTTP/3 depuis 2019 et indique qu’environ 20 % du trafic utilise QUIC lorsque le client et le serveur le prennent tous deux en charge. Fastly, Akamai et AWS CloudFront prennent en charge HTTP/3 sur leurs points de présence. L’infrastructure propre de Google (Search, YouTube, Gmail) utilise QUIC en interne depuis 2013 et propose publiquement HTTP/3. Les déploiements de CDN bénéficient de la reprise 0-RTT de QUIC : les visiteurs réguliers établissent plus rapidement leurs connexions, et la migration de connexion améliore les performances des utilisateurs mobiles qui passent d’un point d’accès à un autre pendant la diffusion du contenu.

La conception de QUIC fondée sur UDP introduit des considérations de sécurité particulières. Attaques par amplification : un attaquant peut usurper une IP source et envoyer de petits paquets Initial, ce qui force le serveur à envoyer à la victime de volumineuses réponses Handshake — QUIC limite ce risque en plafonnant les réponses du serveur à trois fois la quantité de données reçue jusqu’à la validation de l’adresse, au moyen du mécanisme RETRY. Saturation de connexions : les serveurs QUIC doivent limiter le débit des nouvelles tentatives de connexion provenant d’une même IP. Les attaques contre la négociation de version sont empêchées par l’inclusion de la version dans la négociation protégée cryptographiquement. Le chiffrement intégré de QUIC signifie que les équipements d’inspection ne peuvent pas analyser la charge utile QUIC sans être sur le chemin et disposer du certificat du serveur, ce qui améliore la confidentialité par rapport au trafic TCP inspectable.

Le déploiement de HTTP/3 nécessite : (1) un serveur compatible avec QUIC (nginx 1.25+, Caddy, HAProxy 2.6+, LiteSpeed, ou une prise en charge au niveau de l’application via les bibliothèques quic-go, aioquic et ngtcp2) ; (2) l’ouverture du port UDP 443 sur les pare-feu — de nombreux pare-feu d’entreprise bloquent UDP 443, ce qui force QUIC à repasser sur TCP/TLS ; (3) l’annonce de la prise en charge de HTTP/3 au moyen de l’en-tête de réponse Alt-Svc : Alt-Svc: h3=":443"; ma=86400, afin d’inciter les clients HTTP/2 à passer à HTTP/3 ; (4) des répartiteurs de charge compatibles avec QUIC ou une transmission UDP transparente de niveau L4 ; (5) la surveillance de mesures propres à QUIC : événements de migration de connexion, taux d’acceptation du 0-RTT et taux de repli du protocole. Un déploiement progressif avec repli vers HTTPS est transparent pour les clients qui ne prennent pas QUIC en charge.

Comment QUIC résout-il le problème de blocage en tête de ligne qui affecte HTTP/2 sur TCP ?

QUIC intègre TLS 1.3 au niveau du transport sur UDP, ce qui élimine le blocage en tête de ligne de TCP grâce à une récupération des pertes indépendante pour chaque flux. Les identifiants de connexion permettent la migration lors des changements de réseau sans renégociation. HTTP/3 associe HTTP aux flux QUIC au moyen de la compression d’en-têtes QPACK. La reprise de connexion 0-RTT réutilise les secrets de session TLS. QUIC surpasse surtout HTTP/2 en présence de pertes de paquets (réseaux mobiles ou encombrés). L’équilibrage de charge de QUIC nécessite d’encoder le routage des serveurs dans les identifiants de connexion. Le déploiement nécessite UDP 443, des serveurs compatibles avec QUIC et des en-têtes Alt-Svc pour annoncer le protocole.