HTTP/3 en production : activer et diagnostiquer QUIC sans avancer à l’aveugle

ParKelvin Carretero-Corrales

HTTP/3 n’est plus un joli badge à afficher dans un rapport de performance. Bien déployé, il peut réduire certains temps d’établissement de connexion et éviter qu’une perte de paquet bloque tous les échanges multiplexés. Mal déployé, il donne surtout un résultat trompeur : le serveur annonce HTTP/3, le navigateur essaie, l’UDP ne passe pas, puis tout retombe discrètement en HTTP/2.

Le vrai sujet n’est donc pas seulement « comment l’activer ? », mais « comment prouver que le chemin complet fonctionne ? ». Voici une méthode propre, reproductible et réversible.

Ce qui change réellement avec HTTP/3

HTTP/2 transporte plusieurs flux dans une même connexion TCP. C’est efficace, mais une perte de paquet au niveau TCP peut suspendre temporairement l’ensemble des flux de cette connexion. HTTP/3 conserve les sémantiques HTTP, mais les transporte sur QUIC, lui-même basé sur UDP. Les flux QUIC sont indépendants : un flux touché par une perte n’empêche pas les autres de progresser.

QUIC intègre aussi TLS 1.3 à son établissement de connexion. On ne parle donc pas d’un HTTP « en clair sur UDP ». Le chiffrement, l’authentification du serveur et l’intégrité font partie du protocole.

En pratique, le trio à garder en tête est simple :

  • HTTP/3 décrit les échanges HTTP ;
  • QUIC fournit le transport multiplexé et sécurisé ;
  • UDP porte les paquets, souvent sur le port 443.

Avant l’activation : cartographier le vrai point de terminaison

Le serveur applicatif n’est pas toujours celui qui termine la connexion du visiteur. Un CDN, un reverse proxy, un pare-feu applicatif ou un load balancer peut recevoir le trafic public avant Nginx, Apache ou l’application. C’est ce premier point visible depuis Internet qui doit prendre en charge HTTP/3.

Posez quatre questions avant de modifier quoi que ce soit :

  1. Qui termine TLS pour le nom de domaine public ?
  2. Quel équipement écoute réellement en UDP sur le port annoncé ?
  3. Le pare-feu autorise-t-il ce trafic dans les deux sens ?
  4. Le service sait-il continuer en HTTP/2 ou HTTP/1.1 si QUIC échoue ?

Cette cartographie évite le grand classique : activer HTTP/3 sur le serveur d’origine alors que le CDN situé devant ne lui transmet que du HTTP/2, ou ouvrir l’UDP sur la machine alors qu’un pare-feu amont le bloque encore.

L’annonce Alt-Svc ne prouve pas que QUIC répond

Un serveur peut annoncer un point de terminaison HTTP/3 avec l’en-tête Alt-Svc. Par exemple :

Alt-Svc: h3=":443"; ma=86400

Cet en-tête dit au client qu’il peut tenter HTTP/3 sur le port UDP 443 pendant la durée indiquée. Il ne garantit pas que le port est joignable, que le certificat est correct ou que le service QUIC répond. Une annonce erronée peut donc provoquer des essais inutiles avant le repli vers une version HTTP sur TCP.

Autrement dit : vérifiez séparément l’annonce et le transport.

Une procédure de test en quatre couches

1. Vérifier les capacités du client

Toutes les versions de curl ne sont pas compilées avec une bibliothèque HTTP/3. Commencez donc par regarder les protocoles et fonctions disponibles :

curl -V

Si la sortie ne mentionne pas HTTP3, un échec de curl --http3 ne dit rien sur le serveur. Il dit seulement que le client de test n’a pas le support nécessaire.

2. Contrôler l’annonce depuis le chemin TCP classique

curl -sSI --http2 https://exemple.fr/

Recherchez l’en-tête Alt-Svc et vérifiez le port annoncé. Ce test confirme la découverte du service, pas encore son accessibilité en QUIC.

3. Forcer un test HTTP/3 strict

curl -sS --http3-only -o /dev/null -w 'Version HTTP : %{http_version}\nCode : %{response_code}\nTotal : %{time_total}s\n' https://exemple.fr/

L’option --http3-only est importante pour le diagnostic : elle évite qu’un repli automatique masque la panne QUIC. Faites ce test depuis plusieurs accès — réseau local, partage de connexion mobile et, si possible, une sonde externe. Un seul réseau qui réussit ne valide pas tous les chemins Internet.

4. Observer les paquets et les journaux

Sur une machine Linux placée au bon endroit, une capture limitée au trafic UDP 443 permet de savoir si les paquets arrivent réellement :

sudo tcpdump -ni any udp port 443

Aucun paquet reçu ? Cherchez côté DNS, routage, pare-feu, NAT ou équipement amont. Des paquets arrivent mais aucune réponse ne repart ? Regardez l’écoute du service, sa configuration TLS et ses journaux. Les réponses partent mais le client échoue ? Vérifiez le retour réseau, le MTU, le certificat, le SNI et le protocole ALPN négocié.

Les pannes les plus fréquentes

  • UDP 443 est fermé. Autoriser TCP 443 ne suffit pas pour QUIC.
  • Le mauvais équipement est configuré. Le reverse proxy public doit comprendre HTTP/3, même si l’origine reste en HTTP/2.
  • Alt-Svc annonce un port inaccessible. Le navigateur essaie puis revient sur TCP, ce qui rend le problème peu visible.
  • Le test utilise un curl sans HTTP/3. On accuse le serveur alors que l’outil ne sait pas parler QUIC.
  • IPv4 fonctionne, IPv6 non. Le DNS publie les deux familles d’adresses, mais le filtrage ou le routage n’est pas symétrique.
  • La mesure compare deux choses différentes. Cache chaud contre cache froid, connexions réutilisées contre nouvelles connexions, ou réseaux différents : le résultat devient inutilisable.

Mesurer sans vendre du rêve

HTTP/3 ne rend pas automatiquement un site rapide. Il peut surtout aider quand la latence ou les pertes de paquets comptent, notamment sur les réseaux mobiles et les changements de chemin réseau. Si le serveur met deux secondes à générer une page ou si les images sont beaucoup trop lourdes, QUIC ne corrigera pas le fond du problème.

Pour comparer proprement, gardez le même poste, le même réseau, la même URL et le même état de cache. Répétez plusieurs fois les mesures en HTTP/2 puis en HTTP/3. Notez au minimum le temps total, le temps avant le premier octet et la version réellement négociée. Regardez la distribution des résultats, pas seulement le meilleur essai.

Dans le navigateur, ajoutez la colonne « Protocol » aux outils réseau. Une valeur comme h3 confirme l’usage d’HTTP/3 pour la requête observée. Là encore, une capture ou des journaux côté serveur restent utiles pour une preuve de bout en bout.

Déployer progressivement et garder un retour arrière

La bonne méthode consiste à conserver HTTP/2 pendant l’introduction d’HTTP/3. QUIC est un chemin supplémentaire, pas une raison de supprimer immédiatement le chemin TCP éprouvé.

  1. Activez HTTP/3 sur un environnement ou un sous-domaine de test.
  2. Validez IPv4, IPv6, le certificat, l’UDP 443 et le repli HTTP/2.
  3. Ajoutez l’annonce Alt-Svc avec une durée courte au début.
  4. Surveillez les erreurs, le taux de connexions QUIC et les temps de réponse.
  5. Allongez la durée d’annonce seulement après validation.
  6. Pour revenir en arrière, retirez l’annonce et désactivez l’écoute QUIC sans toucher au service HTTPS sur TCP.

Évitez aussi d’activer des fonctions avancées comme les données précoces 0-RTT sans comprendre leur risque de rejeu. Une optimisation de poignée de main ne doit pas transformer une requête non idempotente en opération rejouable.

En conclusion

Un déploiement HTTP/3 réussi se prouve à chaque étage : annonce, résolution, UDP, TLS, ALPN, réponse HTTP et repli. Tant que vous n’avez testé que l’en-tête Alt-Svc ou vu une case « HTTP/3 activé » dans une interface, vous avez une intention, pas une validation.

Si votre problème se situe dans cette zone grise entre configuration, réseau et service web, la page Services & tarifs de FuretLabs présente notamment le diagnostic et la remise en service. L’objectif reste le même : comprendre l’origine avant de modifier la moitié de l’infrastructure.

Sources

Publications similaires