Mon site a-t-il besoin d’une implémentation HTTP/3 distincte ?

Si vous êtes assis derrière un CDN prenant en charge HTTP/3 (Cloudflare, Fastly, Akamai, CloudFront), il est déjà là. Si vous exécutez directement un serveur d'origine, vous avez besoin d'un serveur prenant en charge HTTP/3 (nginx 1.25+, Caddy, LiteSpeed, h2o). La plupart des utilisateurs obtiennent HTTP/3 en déployant derrière un CDN.

Comment puis-je savoir si un site utilise HTTP/3 ?

L'onglet Réseau du navigateur DevTools affiche le protocole par requête — « h3 » ou « http/3 » indique HTTP/3. Des outils en ligne comme http3check.net testent également des sites arbitraires. La barre d'adresse du navigateur ne fait pas apparaître cela ; c'est une question d'outils de développement.

HTTP/3 est-il toujours plus rapide ?

Sur les connexions avec perte ou à latence élevée, oui. Sur un réseau local propre et à faible latence, la différence réside souvent dans le bruit. Sur les réseaux qui bloquent UDP, HTTP/3 échoue complètement et revient à HTTP/2 avec une latence de configuration supplémentaire, ce qui est plus lent que d'ignorer complètement QUIC.

Que signifie HTTP/3 pour les VPN ?

Les VPN modernes (WireGuard, OpenVPN) tunnelent UDP et HTTP/3. Certaines configurations VPN plus anciennes ou restrictives tunnelisent uniquement TCP, auquel cas HTTP/3 revient silencieusement à HTTP/2. Vérifiez le support UDP de votre VPN si vous remarquez une lenteur inhabituelle sur les sites HTTP/3.

HTTP/4 existera-t-il ?

Finalement probablement, mais pas de sitôt. HTTP/3 n’a été livré qu’en 2022 et son adoption continue de croître. Une future version HTTP s'appuierait probablement davantage sur QUIC plutôt que de le remplacer ; QUIC lui-même est le point d'évolution le plus intéressant.

HTTP/3 expliqué : le protocole Web basé sur QUIC qui alimente les navigateurs modernes

HTTP/3 est la troisième version majeure du protocole qui alimente le Web. Là où HTTP/2 était une évolution (même HTTP, livraison plus rapide), HTTP/3 est une refonte du transport, fonctionnant sur QUIC au lieu de TCP+TLS. C'est la valeur par défaut pour les principaux sites depuis 2022 et alimente discrètement la plupart du trafic que les utilisateurs perçoivent désormais comme « rapide ».

Le corps complet de l’article est fourni en anglais ci-dessous.

HTTP/3 est HTTP sur QUIC — le protocole Web de nouvelle génération qui remplace la pile TCP+TLS+HTTP/2 par une seule conception intégrée basée sur UDP. Il a été standardisé dans la RFC 9114 en 2022 et constitue désormais le protocole par défaut pour la plupart des sites majeurs, notamment les propriétés Google, Cloudflare, Meta et Microsoft. métadonnées. Intérêt historique uniquement.

HTTP/1.0 (1996) : en-têtes, méthodes multiples, types MIME. Chacun demande une nouvelle connexion TCP.

HTTP/1.1 (1997, révisé 2014) : connexions persistantes, pipeline, en-têtes d'hôte. Le cheval de bataille du Web depuis deux décennies.

HTTP/2 (2015) : protocole binaire, compression d'en-tête (HPACK), multiplexage de flux, push serveur. S'exécute sur TLS sur TCP.

HTTP/3 (2022) : s'exécute sur QUIC sur UDP. Élimine le blocage de tête de ligne TCP, prise de contact plus rapide, prend en charge la migration de connexion.

Qu'est-ce que HTTP/3 a corrigé

Trois problèmes HTTP/2 spécifiques ont conduit à la refonte :

Blocage de tête de ligne de la couche de transport. HTTP/2 multiplexe de nombreux flux sur un seul TCP connexion. Lorsqu'un paquet est perdu, TCP bloque toute la connexion jusqu'à ce que le paquet perdu soit retransmis, même si un seul flux avait besoin de ce paquet. La fiabilité par flux de QUIC élimine cela. QUIC les fusionne en 1 aller-retour (0 dans certains cas 0-RTT). Sur une connexion à latence de 100 ms, cela représente une amélioration du chargement de page de 200 à 300 ms.
Mort de connexion lors d'un changement de réseau. Le passage du Wi-Fi au cellulaire tue chaque connexion TCP. La migration de connexion QUIC survit au changement en identifiant la connexion avec un ID de connexion plutôt que le 5-tuple.

Ce qui reste le même que HTTP/2

Du point de vue de l'application, HTTP/3 ressemble beaucoup à HTTP/2 :

Cadre binaire
Flux multiplexés (maintenant sans blocage TCP HOL)
Compression d'en-tête (maintenant QPACK au lieu de HPACK, repensé pour fonctionner avec le modèle de flux de QUIC)
Même sémantique HTTP — méthodes, codes d'état, en-têtes

Le code d'application qui fonctionnait sur HTTP/2 fonctionne sur HTTP/3 sans changement ; les différences résident entièrement dans le transport.

Comment un navigateur utilise HTTP/3

Les serveurs signalent la disponibilité HTTP/3 via l'en-tête de réponse alt-svc sur les réponses HTTP/2. Le navigateur mémorise « cette origine prend également en charge h3 sur UDP/443 » et utilise HTTP/3 pour les connexions ultérieures. Si QUIC échoue (le pare-feu bloque UDP, etc.), le navigateur revient à HTTP/2 sur TCP. TCP a le plus souffert :

Réseaux mobiles avec perte de paquets élevée et changements de réseau fréquents
Connexions à latence élevée où l'aller-retour de prise de contact enregistré compte proportionnellement
Pages avec de nombreuses ressources où le multiplexage présente des avantages composé

Sur des connexions filaires propres à un périphérique CDN, HTTP/3 et HTTP/2 fonctionnent de la même manière. L'écart se creuse à mesure que les conditions se dégradent, exactement au moment où les utilisateurs remarquent une lenteur. CloudFront, Microsoft et Meta servent HTTP/3.

Environ 30 à 40 % de toutes les requêtes Web en volume utilisent HTTP/3.

De nombreux réseaux d'entreprise bloquent QUIC au niveau du pare-feu, forçant le recours à HTTP/2. Il s'agit du principal obstacle à une adoption plus élevée.

Ce que HTTP/3 ne change pas

La sémantique HTTP reste inchangée. Les mêmes modèles de mise en cache, de négociation de contenu, de requêtes conditionnelles et d’authentification fonctionnent. Les développeurs Web qui créent des applications ont rarement besoin de réfléchir à la version HTTP utilisée ; la plateforme s’en charge. Les avantages s'étendent automatiquement à toute personne dont le serveur d'origine et le CDN prennent en charge HTTP/3.

Questions fréquemment posées

Mon site a-t-il besoin d’une implémentation HTTP/3 distincte ?: Si vous êtes assis derrière un CDN prenant en charge HTTP/3 (Cloudflare, Fastly, Akamai, CloudFront), il est déjà là. Si vous exécutez directement un serveur d'origine, vous avez besoin d'un serveur prenant en charge HTTP/3 (nginx 1.25+, Caddy, LiteSpeed, h2o). La plupart des utilisateurs obtiennent HTTP/3 en déployant derrière un CDN.
Comment puis-je savoir si un site utilise HTTP/3 ?: L'onglet Réseau du navigateur DevTools affiche le protocole par requête — « h3 » ou « http/3 » indique HTTP/3. Des outils en ligne comme http3check.net testent également des sites arbitraires. La barre d'adresse du navigateur ne fait pas apparaître cela ; c'est une question d'outils de développement.
HTTP/3 est-il toujours plus rapide ?: Sur les connexions avec perte ou à latence élevée, oui. Sur un réseau local propre et à faible latence, la différence réside souvent dans le bruit. Sur les réseaux qui bloquent UDP, HTTP/3 échoue complètement et revient à HTTP/2 avec une latence de configuration supplémentaire, ce qui est plus lent que d'ignorer complètement QUIC.
Que signifie HTTP/3 pour les VPN ?: Les VPN modernes (WireGuard, OpenVPN) tunnelent UDP et HTTP/3. Certaines configurations VPN plus anciennes ou restrictives tunnelisent uniquement TCP, auquel cas HTTP/3 revient silencieusement à HTTP/2. Vérifiez le support UDP de votre VPN si vous remarquez une lenteur inhabituelle sur les sites HTTP/3.
HTTP/4 existera-t-il ?: Finalement probablement, mais pas de sitôt. HTTP/3 n’a été livré qu’en 2022 et son adoption continue de croître. Une future version HTTP s'appuierait probablement davantage sur QUIC plutôt que de le remplacer ; QUIC lui-même est le point d'évolution le plus intéressant.