HTTP/2 vs HTTP/3 Qu'est-ce qui a réellement changé (et si votre API s'y intéresse)

Réponse courte : si vous êtes derrière un CDN, HTTP/3 est probablement déjà géré pour vous et il n'y a rien à configurer. Si vous gérez votre propre serveur, HTTP/2 couvre le cas 95% et HTTP/3 constitue une amélioration intéressante, mais pas urgente.

Voici la version plus longue, car la mise en œuvre technique derrière les différences est en réalité intéressante — et en connaissant ces points, vous pouvez prendre de meilleures décisions sur les cas où la version du protocole importe vraiment.

Ce que HTTP/2 a vraiment corrigé

HTTP/1.1 présentait deux problèmes que HTTP/2 a résolus efficacement.

Trop de connexions TCP pour charger une seule page. Les navigateurs ouvraient 6 à 8 connexions TCP par origine juste pour télécharger des ressources en parallèle. Chaque connexion comporte un coût d'initialisation (handshake TCP, négociation TLS), et cette approche était gaspilleuse à l'échelle. HTTP/2 a remplacé cela par le multiplexing : une seule connexion TCP, plusieurs flux de requêtes/réponses en cours en parallèle. Aucun plus de jonglage de connexions.

Des en-têtes redondants sur chaque requête. Dans HTTP/1.1, chaque requête envoyait ses en-têtes complets — User-Agent, Accept-Encoding, Authorization, tous ensemble — même si rien n’avait changé par rapport à la requête précédente. HTTP/2 utilise la compression HPACK pour dédoubler les en-têtes en maintenant une table de recherche partagée entre client et serveur. Dans un API où vous envoyez le même Authorization: Bearer ... token à chaque appel, cela réduit significativement les surcoûts dans les volumes élevés de trafic.

Le push de serveur était censé être un troisième gain (envoyer préventivement des ressources dont le client a besoin avant de les demander), mais il n’a jamais fonctionné réellement en pratique. Chrome a abandonné son support en 2022. Considérez-le comme déprécié et ne construisez rien autour de cela.

Le problème que HTTP/2 ne pouvait pas corriger

Voici la partie souvent ignorée : le multiplexing sur TCP a un plafond rigide. Lorsqu’un paquet TCP est perdu en transit, TCP met fin à toute la connexion jusqu’à ce que ce paquet soit retransmis et reconnu. Tous vos flux HTTP/2 parallèles — indépendamment de celui auquel le paquet perdu appartient — restent inactifs en attente. C’est le blocage en tête de file (HOL) au niveau du TCP, et ce n’est pas une erreur dans HTTP/2 — c’est comment fonctionne le TCP.

Sur une connexion filaire fiable, le taux de perte de paquets est suffisamment bas pour que cela ne cause rarement de problèmes. Mais sur les réseaux mobiles, les liaisons satellitaires ou tout chemin présentant une perte significative de paquets, l'avantage de multiplexage d'HTTP/2 s'effondre. Vous pouvez avoir 20 flux multiplexés sur une seule connexion, et une seule perte de paquet ralentit tous les 20. 😬

Ce n’est pas une limitation corrigable. C’est une caractéristique structurelle de la construction d’un protocole de multiplexage de requêtes sur un transport de flux de bytes qui ne connaît pas ce qu’est un « flux ».

Ce que HTTP/3 a vraiment changé

HTTP/3 ne se contente pas d'ajuster le format de cadre ou d'ajouter une nouvelle option. Il remplace TCP par QUIC — un protocole de transport qui fonctionne sur UDP.

QUIC gère le multiplexing au niveau du transport, de sorte qu’un paquet perdu ne bloque que le flux auquel il appartient, et non tous les autres flux sur la connexion. Le problème de blocage en tête de file est résolu au bon niveau de la pile. C’est le cœur de la question.

Quelques autres fonctionnalités apportées par QUIC :

• Migration de connexion. QUIC identifie les connexions par un identifiant de connexion, et non par une quadruplet composé de l'IP source, du port source, de l'IP destination et du port destination. Passer de Wi-Fi à un réseau mobile pendant une transfert, et la connexion persiste. Cela importe pour les applications mobiles ; pour les appels entre serveurs, cela est principalement sans importance.
• Prise en charge des négociations 0-RTT. Pour les connexions vers des serveurs connus, QUIC peut ombrer la négociation TLS et envoyer les données immédiatement. Gain réel de latence lors des reconnexion. Note : le 0-RTT comporte une limitation de répétition — ne l'utilisez pas pour des endpoints non idempotents sans comprendre les compromis.
• TLS 1.3 obligatoire. QUIC ne supporte pas les connexions non chiffrées. Aucun HTTP/3 sans TLS, c’est terminé.

La compression des en-têtes a également changé : HTTP/3 utilise QPACK au lieu de HPACK. La différence est technique — QPACK évite un problème bloquant dans HPACK lorsqu’on compressent les en-têtes entre flux. En pratique, vous ne remarquerez pas de différence ; c’est une amélioration d'infrastructure.

Comparaison des fonctionnalités

Fonctionnalité	HTTP/1.1	HTTP/2	HTTP/3
Protocole de transport	TCP	TCP	QUIC (UDP)
Multiplexage des requêtes	Non (plusieurs connexions)	Oui	Oui
Blocage en tête de file (HOL)	Niveau de requête	Niveau du transport (toujours présent)	Aucun
Compression des en-têtes	Aucun	HPACK	QPACK
TLS requis	Non	Non (spécification), oui (navigateurs)	Oui (obligatoire)
Négociation 0-RTT	Non	Non	Oui
Migration de connexion	Non	Non	Oui
Push de serveur	Non	Oui (déprécié)	Non (supprimé)

Ce que cela signifie pour la latence des API

HTTP/3 aide surtout dans des conditions spécifiques. Il n'améliore pas universellement tout.

Réseaux instables. Les clients mobiles atteignant votre API via un LTE ou une couverture 5G peu optimale verront une amélioration mesurable. Les appels entre datacenters sur un réseau privé fiable où le taux de perte de paquets est effectivement nul ? La différence est négligeable.

Connexions froides et reconnexion. Si vos clients d'API se reconnectent fréquemment — des fonctions serveur à court terme, des redémarrages d'applications mobiles, des conteneurs éphémères — le 0-RTT réduit le coût d'initialisation. Les connexions longues dures qui restent ouvertes pendant des minutes n'obtiennent aucun bénéfice de cette fonctionnalité.

Le volume des requêtes compte. HTTP/2 et HTTP/3 brillent tous deux lorsque le client effectue de nombreuses requêtes parallèles. Un navigateur chargant 80 ressources en parallèle voit de grands gains grâce au multiplexage. Un API REST effectuant 3 requêtes séquentielles voit des gains beaucoup plus faibles. Plus le nombre de requêtes concurrentes que votre client effectue, plus les améliorations du transport importent.

Comment les CDNs gèrent cela

Cloudflare a supporté HTTP/3 depuis 2019 et l'active par défaut. AWS CloudFront a ajouté le support en 2022. Fastly, Akamai, BunnyCDN — tous les supportent.

L'architecture importe ici : votre CDN termine la connexion client à son niveau périphérique. Même si un client se connecte à votre CDN via HTTP/3 avec QUIC, le segment CDN vers l'origine est presque certainement HTTP/1.1 ou HTTP/2 sur TCP. Ainsi, activer HTTP/3 sur votre CDN ne nécessite aucune modification sur votre serveur d'origine.

Si vous êtes sur Cloudflare, vérifiez vos paramètres d'Optimisation → Vitesse — HTTP/3 (avec QUIC) est un interrupteur activé par défaut pour la plupart des zones. Les autres CDNs varient. C’est le changement de plus haut impact que la plupart des équipes peuvent faire : aucune modification sur l’origine, bénéfice immédiat pour les clients sur mobile ou sur des chemins à faible latence.

Devriez-vous faire quoi que ce soit en réalité ?

Derrière un CDN : Vérifiez que HTTP/3 est activé et passez à l'action. Cela prend 30 secondes.

Sur un serveur nginx personnalisé : HTTP/3 nécessite nginx 1.25+ (la branche principale — la version stable est en retard sur QUIC). Vous aurez besoin du --with-http_v3_module paramètre de compilation et d'une listen 443 quic reuseport directive en plus de votre écouteur TCP existant. Assurez-vous que le port UDP 443 est ouvert sur votre pare-feu — certains environnements le bloquent. Faites-le si vous servez des utilisateurs mobiles ; ne le faites pas si vous gérez uniquement des appels entre serveurs.

Utilisation de Caddy : HTTP/3 est activé par défaut sans configuration. Rien à faire.

Construire un client appelant des API tierces : La disponibilité d’HTTP/3 dépend du serveur que vous appelez, pas de votre code. curl supporte HTTP/3 à partir de la version 7.86.0 avec un backend compatible (nghttp3 ou quiche). La plupart des bibliothèques HTTP dans Python et Node ne le supportent pas encore nativement. Go ne le supporte pas dans sa bibliothèque standard ; il existe une bibliothèque séparée si vous en avez besoin. net/http Un point pratique : si vous testez quelle version HTTP un serveur négocie réellement, ou que vous construisez des commandes curl avec quic-go flags,

sur iotools.cloud est utile pour construire la bonne commande sans chercher chaque fois la syntaxe exacte des flags. --http3 drapeaux, Générateur de commande cURL sur iotools.cloud, c'est utile pour construire la bonne commande sans devoir chercher chaque fois la syntaxe exacte du drapeau.

Vous aimerez peut-être aussi