Votre serveur parle peut-être encore un dialecte des années 1990
HTTP/1.1 date de 1997. La majorité des serveurs web déployés aujourd'hui l'utilisent encore par défaut, y compris pour des applications modernes construites avec Symfony ou Laravel. Ce n'est pas un problème sur un réseau d'entreprise stable, mais sur une connexion mobile avec du signal instable, les conséquences sont visibles : chaque paquet perdu bloque entièrement la connexion TCP concernée, et le navigateur doit attendre avant de relancer la requête. Vos utilisateurs, eux, voient une page qui charge lentement.
HTTP/2 et HTTP/3 ont précisément été conçus pour corriger ces limites. Ce guide explique ce que chaque protocole apporte concrètement, comment vérifier ce que votre serveur Nginx utilise aujourd'hui, et comment activer HTTP/3 sur Ubuntu 24.04.
Ce que HTTP/2 change réellement
HTTP/1.1 ouvre plusieurs connexions TCP en parallèle (généralement six par domaine) pour compenser l'impossibilité d'envoyer plusieurs requêtes simultanées sur une même connexion. Cela crée du bruit réseau, consomme des ressources côté serveur et ne résout pas le problème de fond.
HTTP/2 introduit le multiplexage : toutes les requêtes transitent sur une seule connexion TCP, entrelacées. Un seul handshake TLS, un seul aller-retour pour établir la connexion, et les ressources (scripts JS, CSS, images, fontes) sont transmises en parallèle sans file d'attente artificielle. Pour une application Symfony avec un bundle Vite et plusieurs feuilles de style, le gain sur une connexion moyenne est mesurable.
L'activation sur Nginx se résume à deux mots dans le bloc listen :
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
# reste de la configuration
}
Avant de continuer, vérifiez que HTTP/2 est bien actif avec curl :
curl -I --http2 https://votre-domaine.com
La réponse doit contenir HTTP/2 200. Si vous voyez HTTP/1.1, le protocole n'est pas activé malgré la directive, ce qui peut indiquer un problème de version de Nginx ou de configuration TLS.
HTTP/3 : QUIC à la place de TCP
HTTP/3 remplace TCP par QUIC, un protocole de transport basé sur UDP. La différence fondamentale : sur TCP, un paquet perdu bloque toute la connexion jusqu'à sa retransmission. Sur QUIC, chaque flux de données est indépendant. Un paquet perdu retarde uniquement le fichier concerné, pas les autres ressources qui continuent de charger.
Sur une connexion mobile instable, c'est un changement de comportement perceptible. Google a mesuré une réduction de latence de 8 % en moyenne sur les recherches desktop lors du déploiement initial de QUIC, avec des gains plus marqués sur les connexions dégradées (source : Enabling HTTP/2 and HTTP/3 for Your Laravel App: A Practical Nginx Guide).
Environ un tiers des sites web servent aujourd'hui HTTP/3. La plupart des navigateurs le supportent. Le déploiement côté serveur reste pourtant rare, faute de documentation claire.
Prérequis sur Ubuntu 24.04
Nginx doit être compilé avec le support de QUIC. Le paquet nginx des dépôts Ubuntu standards ne l'inclut pas. Il faut utiliser le dépôt officiel Nginx :
apt install curl gnupg2 ca-certificates lsb-release ubuntu-keyring
curl https://nginx.org/keys/nginx_signing.key | gpg --dearmor \
| tee /usr/share/keyrings/nginx-archive-keyring.gpg > /dev/null
echo "deb [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] \
http://nginx.org/packages/ubuntu $(lsb_release -cs) nginx" \
| tee /etc/apt/sources.list.d/nginx.list
apt update && apt install nginx
Vérifiez que votre build inclut QUIC :
nginx -V 2>&1 | grep -o 'with-http_v3_module'
Configuration Nginx avec HTTP/3
server {
listen 443 ssl;
listen [::]:443 ssl;
http2 on;
listen 443 quic reuseport;
listen [::]:443 quic reuseport;
ssl_certificate /etc/ssl/certs/votre-cert.pem;
ssl_certificate_key /etc/ssl/private/votre-key.pem;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
add_header Alt-Svc 'h3=":443"; ma=86400';
root /var/www/html/public;
index index.php;
location / {
try_files $uri $uri/ /index.php?$query_string;
}
location ~ \.php$ {
fastcgi_pass unix:/run/php/php8.3-fpm.sock;
fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
include fastcgi_params;
}
}
Le header Alt-Svc est indispensable : il indique au navigateur qu'une connexion HTTP/3 est disponible sur ce domaine. Sans lui, le navigateur ne tentera jamais la connexion QUIC, même si le serveur l'accepte.
Pensez également à ouvrir le port UDP 443 dans votre pare-feu :
ufw allow 443/udp
HTTP/3 utilise QUIC sur UDP. Si le port UDP est fermé, les connexions HTTP/3 échouent silencieusement et le navigateur bascule sur HTTP/2.
Vérifier que HTTP/3 fonctionne
Les navigateurs ne passent pas en HTTP/3 dès la première visite : ils ont besoin d'avoir reçu le header Alt-Svc lors d'une connexion HTTP/2 précédente. Pour tester directement depuis le terminal :
curl --http3 -I https://votre-domaine.com
Si curl renvoie HTTP/3 200, HTTP/3 est opérationnel. Vous pouvez aussi utiliser l'outil en ligne http3check.net pour un diagnostic rapide.
Dans Chrome, l'onglet chrome://net-internals/#quic liste les sessions QUIC actives. Dans Firefox, les DevTools réseau affichent le protocole utilisé dans la colonne dédiée.
Conclusion
Activer HTTP/2 demande moins d'une heure sur un serveur Nginx déjà configuré en HTTPS. HTTP/3 nécessite quelques étapes supplémentaires (version de Nginx, port UDP, header Alt-Svc) mais reste accessible à tout développeur ayant la main sur sa configuration serveur.
Le retour sur investissement est particulièrement visible pour les applications avec beaucoup de ressources statiques (SPAs, applications avec Vite, interfaces riches) et pour les utilisateurs mobiles. Si votre application Symfony ou Laravel tourne en production sur un VPS ou un serveur dédié, c'est probablement l'optimisation infrastructure avec le meilleur ratio effort/impact disponible aujourd'hui.
