Chaque requête HTTP traitée par votre API repose sur une couche de transport à laquelle la plupart des développeurs ne pensent jamais. Pendant 25 ans, la réponse fut TCP. Puis Google, lassé d'attendre que TCP s'améliore, a construit le protocole QUIC sur UDP, et l'IETF l'a transformé en standard. HTTP/3 est la version de HTTP conçue pour fonctionner sur ce protocole.
Cela ressemble à de la plomberie. Et c'en est en grande partie. Mais cette "plomberie" modifie la vitesse de connexion de votre API, son comportement sur les réseaux mobiles instables et la manière dont les requêtes parallèles partagent une connexion. Si vous concevez ou exploitez des API, vous devriez savoir ce qui a changé, ce qui n'a pas changé, et comment vérifier ce que vos propres points de terminaison utilisent aujourd'hui.
Une chose reste constante à travers tout cela : vos requêtes, réponses, codes de statut et charges utiles JSON sont identiques sur HTTP/1.1, HTTP/2 et HTTP/3. Des outils comme Apidog testent et déboguent au niveau de l'API, de sorte que tout ce que vous validez sur le comportement d'un point de terminaison reste vrai, quelle que soit la version de transport négociée par votre infrastructure sous-jacente. Si vous avez déjà lu notre analyse de ce qu'est HTTP/2 et comment tester les API HTTP/2, cet article reprend là où le précédent s'est arrêté.
Qu'est-ce que le protocole QUIC ?
QUIC est un protocole de transport standardisé dans la RFC 9000. Il fonctionne sur UDP au lieu de TCP, et il reconstruit les fonctionnalités fournies par TCP (fiabilité, ordonnancement, contrôle de congestion) dans l'espace utilisateur, par flux, avec le chiffrement intégré dès le premier paquet.
Quatre décisions de conception le définissent :
Il fonctionne sur UDP. TCP est implémenté dans les noyaux des systèmes d'exploitation et les "middleboxes" partout sur Internet, ce qui rend son évolution presque impossible. UDP est une enveloppe mince sans garantie de livraison, donc QUIC construit sa propre couche de fiabilité par-dessus et peut livrer des améliorations sous forme de mises à jour de bibliothèques plutôt que de mises à niveau du système d'exploitation.
TLS 1.3 est intégré, pas ajouté. Avec TCP, vous effectuez une poignée de main TCP, puis une poignée de main TLS distincte par-dessus. QUIC les fusionne. La configuration cryptographique a lieu à l'intérieur de la poignée de main de transport elle-même, de sorte qu'une nouvelle connexion sécurisée est prête après un seul aller-retour. Il n'existe pas de QUIC non chiffré.
Les flux sont indépendants. Une connexion QUIC transporte de nombreux flux, et chacun est livré indépendamment. Un paquet perdu ne bloque que le flux auquel il appartient. C'est la solution au problème de blocage en tête de ligne (head-of-line blocking) de TCP, que nous aborderons dans un instant.
Les connexions survivent aux changements de réseau. TCP identifie une connexion par adresse IP et port. Changez l'un ou l'autre (sortez de la portée Wi-Fi, passez à la 5G) et la connexion meurt. QUIC identifie les connexions par un identifiant de connexion à la place, de sorte qu'un client peut se déplacer vers un nouveau réseau et maintenir la même connexion logique active. Pas de reconnexion, pas de nouvelle poignée de main.
HTTP/3, défini dans la RFC 9114, est la transposition de la sémantique HTTP sur les flux QUIC. Mêmes méthodes, mêmes en-têtes, mêmes codes de statut. Format de données différent, transport différent.
HTTP/3 vs HTTP/2 : ce qui a changé en pratique
HTTP/2 fut un grand pas en avant par rapport à HTTP/1.1. Il a introduit le multiplexage, permettant à de nombreuses requêtes de partager une seule connexion TCP au lieu de faire la queue ou d'ouvrir six sockets parallèles. Mais il a conservé TCP en dessous, ce qui a créé un problème que HTTP/2 ne pouvait résoudre seul.
TCP garantit la livraison ordonnée d'un seul flux d'octets. Lorsqu'un paquet est manquant, TCP retient tous les octets suivants jusqu'à ce que la retransmission arrive, même les octets appartenant à des flux HTTP/2 complètement indépendants. Un paquet perdu bloque les 20 requêtes multiplexées sur la connexion. C'est le "head-of-line blocking" au niveau du transport, et sur un réseau avec des pertes, cela peut rendre HTTP/2 plus lent que HTTP/1.1 avec ses multiples connexions.
HTTP/3 supprime le flux d'octets partagé. Chaque requête est mappée à son propre flux QUIC avec son propre ordonnancement de livraison. Perdez un paquet transportant le flux 5, et les flux 6 à 24 continuent de circuler. Le multiplexage fonctionne enfin comme les diagrammes HTTP/2 l'ont toujours prétendu.
La logique de la poignée de main a également changé :
| HTTP/2 sur TCP+TLS 1.3 | HTTP/3 sur QUIC | |
|---|---|---|
| Configuration d'une nouvelle connexion | 2 allers-retours (TCP + TLS) | 1 aller-retour |
| Connexion reprise | 1 aller-retour | 0 allers-retours (0-RTT) |
| Impact d'un paquet perdu | Bloque tous les flux | Bloque un seul flux |
| Changement de réseau (Wi-Fi vers 5G) | La connexion se coupe, reconnexion complète | La connexion migre, et se poursuit |
| Chiffrement | Optionnel en théorie, couche séparée | Obligatoire, TLS 1.3 intégré |
La ligne 0-RTT mérite une mise en garde. Lorsqu'un client se reconnecte à un serveur qu'il a déjà vu, QUIC lui permet d'envoyer des données d'application dans le premier paquet, avant que la poignée de main ne soit terminée. Excellent pour la latence. Mais les données 0-RTT peuvent être capturées et rejouées par un attaquant, de sorte que les serveurs ne doivent accepter que les requêtes idempotentes en 0-RTT. Un GET rejoué est inoffensif. Un POST rejoué qui débite une carte de crédit ne l l'est pas. Si vous activez le 0-RTT à votre périphérie, assurez-vous que les appels d'API non idempotents sont exclus, ou vérifiez que votre CDN le fait pour vous.
Ce que HTTP/3 signifie pour vos API
Les mises à niveau de protocole n'importent que si elles changent quelque chose que vous pouvez mesurer. Voici où HTTP/3 fait bouger les lignes pour le trafic d'API, et où il ne le fait pas.
La configuration de la connexion devient moins coûteuse
Un client mobile typique sur une connexion RTT de 60 ms passe environ 120 ms sur la configuration TCP+TLS avant même que la première requête API ne quitte l'appareil. HTTP/3 réduit cela à environ 60 ms, et presque zéro lors de la reprise. Pour une API appelée depuis une application mobile qui ouvre souvent de nouvelles connexions (démarrages à froid, réveils en arrière-plan, sessions de courte durée), l'économie se manifeste sur chacune de ces premières requêtes. Pour une intégration de serveur à serveur qui maintient un pool de connexions chaudes, la poignée de main est amortie jusqu'à l'insignifiance et vous ne remarquerez rien.
Les clients mobiles ne perdent plus leurs connexions
La migration de connexion est la fonctionnalité "dormante" pour les équipes d'API. Un utilisateur démarre une requête sur le Wi-Fi du bureau, se dirige vers l'ascenseur, et le téléphone passe au réseau cellulaire. Sur TCP, cette requête en cours échoue et votre logique de réessai côté client (vous avez une logique de réessai, n'est-ce pas ?) se déclenche avec une reconnexion complète. Sur QUIC, la connexion suit l'appareil vers le nouveau réseau. Moins d'erreurs de timeout dans vos journaux clients, moins d'écritures à moitié terminées à analyser.
Multiplexage sans le mode de défaillance
Pour les API REST, la correction du blocage HOL est la plus importante lorsqu'un client envoie de nombreuses requêtes en parallèle : un tableau de bord hydratant 15 widgets, un moteur de synchronisation poussant un lot de mises à jour. Sur un réseau propre, HTTP/2 et HTTP/3 fonctionnent à peu près de la même manière. Ajoutez 1 à 2 % de perte de paquets (Wi-Fi de conférence bondé, cellulaire de métro), et HTTP/3 maintient les requêtes parallèles indépendantes tandis que HTTP/2 les bloque en tandem.
gRPC reste principalement sur HTTP/2 pour le moment
gRPC est lié à HTTP/2 par conception ; son contrat de protocole dépend du cadrage et des "trailers" HTTP/2. L'écosystème gRPC n'a pas standardisé de mappage HTTP/3, et les implémentations courantes (Go, Java, Python, Node) ne le proposent pas. Le serveur Kestrel de .NET peut servir gRPC sur HTTP/3 comme une capacité expérimentale, mais considérez cela comme l'exception. Si votre architecture s'appuie sur gRPC et HTTP/2 pour les performances API internes, une migration vers HTTP/3 n'est pas quelque chose que vous devez prévoir cette année.
Streaming et trafic en temps réel
Les Server-Sent Events fonctionnent sur HTTP/3 sans changement, car SSE est une réponse HTTP ordinaire de longue durée. Les WebSockets sont plus délicats : la mise à niveau WebSocket a été conçue pour TCP, et son équivalent HTTP/3 (RFC 9220, plus l'API WebTransport émergente) a un support fragmentaire. Si vous hésitez entre WebSockets et HTTP simple pour une fonctionnalité en temps réel, la disponibilité de HTTP/3 ne devrait pas encore dicter la décision.
La partie honnête : quand HTTP/3 ne sera d'aucune aide
La plupart des problèmes de latence des API n'ont rien à voir avec le protocole de transport. Si votre point de terminaison prend 400 ms à cause d'une requête de base de données non indexée, HTTP/3 délivrera cette réponse lente 60 ms plus tôt. La mise en cache, la conception de la charge utile, les requêtes N+1 et la réutilisation des connexions dominent les performances réelles des API, et vous devriez épuiser ces options avant de penser au transport. Un test de performance d'API structuré produira généralement des gains 10 fois plus importants qu'une mise à niveau de protocole.
HTTP/3 brille dans des conditions spécifiques :
- Des liens à haute latence, où économiser des allers-retours représente un gain en pourcentage fixe
- Des réseaux avec des pertes, où l'élimination du blocage HOL s'accumule
- Des clients mobiles qui changent de réseau en cours de session
- Beaucoup de connexions courtes plutôt que peu de longues
Pour une API JSON typique consommée par des serveurs dans la même région sur des réseaux fiables, la différence est mesurable dans les benchmarks et invisible pour les utilisateurs. Deux autres remarques pratiques : le port UDP 443 est bloqué dans certains réseaux d'entreprise (les clients reviennent automatiquement à HTTP/2, donc rien ne se casse), et le chiffrement en espace utilisateur de QUIC coûte actuellement plus de CPU serveur par connexion que le TCP kernel optimisé.
Support actuel : qui utilise HTTP/3 aujourd'hui ?
L'adoption est plus avancée que la plupart des développeurs backend ne le supposent :
- Navigateurs : Chrome, Edge, Firefox et Safari prennent tous en charge HTTP/3 activé par défaut.
- CDN et points d'accès : Cloudflare, Fastly, Akamai et CloudFront le supportent ; sur Cloudflare, c'est un simple interrupteur. Pour la plupart des équipes, c'est la voie pratique : terminer HTTP/3 à la périphérie, et conserver HTTP/1.1 ou HTTP/2 de la périphérie à l'origine.
- Serveurs : Nginx a ajouté HTTP/3 expérimental dans la version 1.25 avec
listen 443 quic;. Caddy l'active par défaut. LiteSpeed et HAProxy le supportent. Apache httpd ne le fait pas. - Environnements d'exécution : Node.js n'a pas de support serveur HTTP/3 stable intégré, ce qui est une autre raison pour laquelle la terminaison à la périphérie est le déploiement courant.
- curl : le supporte avec l'option
--http3lorsqu'il est compilé avec une pile TLS compatible HTTP/3 ; consultez la documentation HTTP/3 de curl pour savoir quelles versions l'incluent.
Comment vérifier si votre API sert HTTP/3
La découverte fonctionne via l'en-tête de réponse Alt-Svc. Un serveur annonçant HTTP/3 répond à votre première requête (HTTP/2) avec quelque chose comme :
alt-svc: h3=":443"; ma=86400
Cela indique au client : ce même service est disponible via HTTP/3 sur le port UDP 443 pour les prochaines 24 heures. Vérifiez-le avec curl :
curl -sI https://www.cloudflare.com | grep -i alt-svc
# alt-svc: h3=":443"; ma=86400
Pour effectuer la requête directement via HTTP/3 (nécessite une version de curl compatible HTTP/3) :
curl --http3 -I https://cloudflare-quic.com
# HTTP/3 200
La ligne de statut indique HTTP/3 au lieu de HTTP/2. Dans les outils de développement de Chrome, ouvrez l'onglet Réseau, cliquez avec le bouton droit sur l'en-tête de colonne, activez la colonne Protocole, et recherchez h3 à côté de vos appels d'API. En production, ajoutez le protocole négocié à vos journaux d'accès ; la répartition entre le trafic h2 et h3 vous indique combien de vos clients bénéficient de cet avantage.
Pendant que vous vérifiez le transport, vérifiez également le comportement. Dirigez Apidog vers les mêmes points de terminaison et vérifiez les codes de statut, les schémas de réponse et les budgets de latence. Les gains au niveau du transport sont inutiles si le contrat de l'API sous-jacent est rompu, et les vérifications de contrat sont précisément la couche où un changement de protocole ne peut pas vous sauver. Téléchargez Apidog gratuitement et exécutez la même suite de tests avant et après avoir activé HTTP/3 à votre périphérie ; la différence de temps de réponse sur les réseaux mobiles est votre réponse concrète, pas les gros titres des benchmarks.
FAQ
HTTP/3 est-il plus rapide que HTTP/2 ?
Sur des réseaux propres et à faible latence : à peine. Sur des réseaux avec des pertes ou à haute latence : oui, souvent de manière significative, car HTTP/3 économise un aller-retour de poignée de main et un seul paquet perdu ne bloque plus chaque requête multiplexée. Mesurez avec votre propre profil de trafic avant de revendiquer la victoire. Et rappelez-vous que HTTP/2 reste excellent ; si vous rencontrez des erreurs de connexion là-bas, il s'agit généralement de problèmes de couche TLS comme le problème SSLV3_ALERT_HANDSHAKE_FAILURE plutôt que de limites protocolaires.
HTTP/3 utilise-t-il TCP ?
Non. HTTP/3 fonctionne sur QUIC, qui lui-même fonctionne sur UDP, généralement le port 443. QUIC réimplémente la fiabilité, l'ordonnancement et le contrôle de congestion que TCP fournissait, mais par flux et dans l'espace utilisateur. Si UDP 443 est bloqué sur un réseau, les clients reviennent automatiquement à HTTP/2 sur TCP.
Dois-je modifier le code de mon API pour HTTP/3 ?
Presque jamais. La sémantique HTTP est inchangée : mêmes méthodes, en-têtes, codes de statut et corps. Le travail se situe au niveau de l'infrastructure (activation au niveau de votre CDN, équilibreur de charge ou serveur) plus une vérification de conception : assurez-vous que les données anticipées 0-RTT sont limitées aux requêtes idempotentes.
Puis-je utiliser gRPC sur HTTP/3 ?
Majoritairement non, pour l'instant. Le format de données de gRPC est lié à HTTP/2, et les bibliothèques gRPC grand public ne proposent pas de transports HTTP/3. .NET a un support expérimental. Maintenez les services gRPC sur HTTP/2 et adoptez HTTP/3 là où cela est le plus avantageux : points de terminaison REST publics, orientés navigateur et mobiles.