HTTP/3 et protocole QUIC : ce que ça change pour votre site

Chaque fois qu'un visiteur ouvre une page, son navigateur établit une connexion avec le serveur avant de recevoir le moindre octet de contenu. Sur une connexion mobile instable, cette étape et les pertes de paquets peuvent coûter de précieuses centaines de millisecondes. HTTP/3, qui repose sur le protocole QUIC, a été conçu pour réduire ces délais. Normalisé en 2022, il est aujourd'hui pris en charge par tous les navigateurs majeurs. Voyons ce qu'il apporte réellement et comment l'activer.

De HTTP/1.1 à HTTP/3 : un rapide historique

• HTTP/1.1 (1997) : une requête à la fois par connexion. Les navigateurs ouvraient plusieurs connexions en parallèle pour compenser ;
• HTTP/2 (2015) : plusieurs requêtes circulent en même temps sur une seule connexion TCP, grâce au multiplexage ;
• HTTP/3 (2022) : le même principe de multiplexage, mais sur QUIC, un protocole qui remplace TCP.

HTTP/2 avait un défaut structurel : comme TCP livre les données dans l'ordre, un seul paquet perdu bloque toutes les requêtes de la connexion jusqu'à sa retransmission. C'est le blocage en tête de file (head-of-line blocking). Sur un réseau parfait, l'effet est invisible ; sur un réseau mobile qui perd des paquets, il ralentit tout.

Ce que le protocole QUIC change

QUIC, normalisé par l'IETF dans la RFC 9000, fonctionne au-dessus d'UDP et intègre directement le chiffrement TLS 1.3. HTTP/3 lui-même est décrit dans la RFC 9114. Leurs apports concrets :

Une connexion établie plus vite

Avec TCP et TLS, il faut plusieurs allers-retours entre le navigateur et le serveur avant d'envoyer la première requête. QUIC combine l'établissement de la connexion et la négociation du chiffrement en un seul aller-retour. Lors d'une reconnexion à un serveur déjà visité, le navigateur peut même envoyer ses données dès le premier paquet (mode 0-RTT).

Plus de blocage général sur perte de paquet

Chaque flux est indépendant : la perte d'un paquet ne retarde que la ressource concernée, pas toutes les autres. Les images, feuilles de style et scripts continuent d'arriver.

Une connexion qui survit au changement de réseau

Une connexion TCP est identifiée par les adresses IP et les ports des deux côtés. Quand un smartphone passe du Wi-Fi à la 4G, l'adresse change et la connexion est perdue. QUIC utilise un identifiant de connexion indépendant de l'adresse : le transfert peut continuer après le changement de réseau.

Quels gains attendre réellement ?

Soyons honnêtes : sur une connexion fibre stable, la différence entre HTTP/2 et HTTP/3 est faible. Les gains se mesurent surtout :

• sur les réseaux mobiles avec une latence élevée ou des pertes de paquets ;
• pour les visiteurs éloignés du serveur ;
• sur les pages qui chargent beaucoup de ressources.

HTTP/3 ne compense pas un site trop lourd : il accélère le transport, pas le contenu. Commencez par les fondamentaux décrits dans mon guide de performance web et par un bon cache HTTP.

Activer HTTP/3 dans nginx

nginx prend en charge HTTP/3 depuis la version 1.25, selon sa documentation officielle. Le module doit être compilé avec l'option --with-http_v3_module, ce qui est le cas des paquets officiels de nginx.org. Vérifiez avec nginx -V.

server {
    # HTTP/3 sur UDP
    listen 443 quic reuseport;
    listen [::]:443 quic reuseport;

    # HTTP/2 et HTTP/1.1 sur TCP, toujours nécessaires
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;

    server_name exemple.fr;

    ssl_certificate     /etc/letsencrypt/live/exemple.fr/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/exemple.fr/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;

    # Annonce au navigateur que HTTP/3 est disponible
    add_header Alt-Svc 'h3=":443"; ma=86400' always;
}

Quelques points d'attention :

• L'option reuseport ne doit figurer qu'une seule fois par couple adresse-port sur l'ensemble du serveur, même si plusieurs sites y sont hébergés ;
• Le pare-feu doit laisser passer l'UDP sur le port 443, en plus du TCP : sudo ufw allow 443/udp ;
• L'en-tête Alt-Svc est indispensable : la première visite se fait toujours en HTTP/2, et c'est cet en-tête qui indique au navigateur qu'il peut passer en HTTP/3 pour les requêtes suivantes ;
• Le 0-RTT est désactivé par défaut, et c'est préférable : les données envoyées en 0-RTT peuvent être rejouées par un attaquant.

Si vous découvrez la configuration de nginx, mon guide nginx sur VPS pose les bases.

Vérifier que HTTP/3 fonctionne

Dans les outils de développement de Chrome ou Firefox, onglet Réseau, affichez la colonne « Protocole » : les ressources servies en HTTP/3 indiquent h3. Pensez à recharger la page une seconde fois, puisque la première requête passe par HTTP/2. En ligne de commande, une version de curl compilée avec la prise en charge de HTTP/3 permet aussi le test :

curl --http3 -I https://exemple.fr

Certains réseaux d'entreprise bloquent l'UDP : les navigateurs reviennent alors automatiquement à HTTP/2, sans erreur pour le visiteur. C'est pourquoi il faut toujours conserver l'écoute TCP.

Et sur un hébergement mutualisé ?

Sur un hébergement mutualisé, l'activation dépend de l'hébergeur. Beaucoup de CDN proposent HTTP/3 d'un simple clic. C'est un critère à ajouter à votre liste au moment de choisir un hébergement web.

Sur les serveurs que j'administre, HTTP/3 fait partie de la configuration standard, aux côtés de HTTPS et des en-têtes de sécurité. Si vous voulez moderniser l'hébergement de votre site, contactez-moi.