Une annonce ne garantit pas le fonctionnement
Un serveur annonce HTTP/3 dans l’en-tête de réponse Alt-Svc, que le client reçoit via HTTP/1.1 ou HTTP/2. Cet en-tête n’est qu’une promesse. HTTP/3 utilise QUIC sur UDP : la page peut donc se charger normalement alors qu’UDP est entièrement bloqué, et le navigateur reste silencieusement sur HTTP/2.
curl -sI https://server.example/ | grep -i alt-svcConfirmer un véritable transfert
Seule une requête terminée via QUIC confirme HTTP/3. Utilisez un curl compilé avec la prise en charge de HTTP/3 ; de nombreux paquets système ne l’incluent pas. L’option est alors rejetée, ce qui ne dit rien sur le serveur. Dans un navigateur, ouvrez les outils de développement et consultez la colonne du protocole, qui affiche h3 pour une telle requête. Le navigateur peut utiliser HTTP/2 lors de la première visite ; rechargez donc la page.
curl -V | grep -i http3
curl -sS --http3-only -o /dev/null -w '%{http_version}\n' https://server.example/Vérifier la configuration de NGINX
NGINX a besoin d’un point d’écoute QUIC en plus de celui de TCP, et sa version comme sa compilation doivent le prendre en charge. TLS 1.3 est requis, car QUIC l’utilise directement. Vérifiez la configuration avant de la recharger. La valeur ma dans Alt-Svc est la durée en secondes pendant laquelle les clients mémorisent la promesse ; utilisez donc une durée courte pendant les tests.
listen 443 ssl;
listen 443 quic reuseport;
http2 on;
add_header Alt-Svc 'h3=":443"; ma=300' always;
nginx -V 2>&1 | grep -o with-http_v3_module
sudo nginx -tOuvrir UDP 443 sur tout le trajet
La cause d’échec la plus fréquente est un pare-feu qui autorise TCP 443, mais pas UDP 443. Vérifiez le serveur et tous les filtres externes. Vous pouvez confirmer sur le serveur que le socket est en écoute. Certains réseaux d’entreprise et publics bloquent volontairement QUIC : un test échoué depuis un réseau ne prouve donc pas que le serveur est en cause. Recommencez depuis un autre réseau.
sudo ss -lunp | grep ':443'
sudo ufw allow 443/udp
sudo tcpdump -ni any udp port 443Le nouveau protocole est-il plus rapide ?
HTTP/3 est surtout utile sur les connexions avec perte de paquets ou lors de changements de réseau, car un paquet perdu ne bloque pas les autres flux. Sur une bonne connexion filaire, la différence peut être faible et l’utilisation du CPU sur le serveur plus élevée. Mesurez votre propre cas au lieu de présumer un gain et gardez HTTP/2 disponible pour les clients qui ne peuvent pas utiliser UDP.
Le test HTTP/3 dans CH-J Server Manager
Server Diagnostics inclut un client HTTP ; le test ne dépend donc pas du curl du système. Il n’indique HTTP/3 comme confirmé qu’après un transfert QUIC terminé et traite Alt-Svc comme une simple annonce. En cas d’expiration du délai UDP, il indique que la prise en charge par le serveur reste non vérifiée, car la cause peut être le réseau entre vous et le serveur. Un repli vers un autre protocole n’est pas compté comme un succès.