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 son évolution, a conçu QUIC sur UDP, avant que l'IETF ne le standardise. HTTP/3 est la version de HTTP conçue pour fonctionner sur ce protocole.
Cette couche de transport influence pourtant la vitesse de connexion, le comportement sur les réseaux mobiles instables et le partage d'une connexion entre requêtes parallèles. Si vous concevez ou exploitez des API, voici ce qui change avec HTTP/3, ce qui reste identique et comment vérifier le protocole utilisé par vos points de terminaison.
Les requêtes, réponses, codes de statut et charges utiles JSON restent identiques avec HTTP/1.1, HTTP/2 et HTTP/3. Des outils comme Apidog testent et déboguent au niveau de l'API : vos validations de contrat restent donc valables quelle que soit la version de transport négociée. Si vous avez déjà lu notre présentation de HTTP/2 et des tests d'API HTTP/2, cet article reprend là où elle s'est arrêtée.
Qu'est-ce que QUIC ?
QUIC est un protocole de transport standardisé par la RFC 9000. Il fonctionne sur UDP et reconstruit dans l'espace utilisateur les fonctions de TCP — fiabilité, ordonnancement et contrôle de congestion — avec un chiffrement intégré dès le premier paquet.
Quatre choix de conception le définissent :
- UDP comme enveloppe. TCP est implémenté dans les noyaux des systèmes et par de nombreuses middleboxes, ce qui rend son évolution très difficile. UDP fournit une couche minimale ; QUIC ajoute sa propre fiabilité et peut évoluer via des bibliothèques, sans mise à niveau du système d'exploitation.
- TLS 1.3 intégré. Avec TCP, la poignée de main TCP est suivie d'une poignée de main TLS. QUIC les fusionne : une nouvelle connexion sécurisée est prête après un seul aller-retour. QUIC n'existe pas en mode non chiffré.
- Des flux indépendants. Une connexion QUIC transporte plusieurs flux, livrés séparément. Un paquet perdu ne bloque que le flux concerné.
- La migration de connexion. TCP associe une connexion à une adresse IP et un port. QUIC utilise un identifiant de connexion : un client peut passer du Wi-Fi à la 5G sans recréer la connexion logique.
HTTP/3, défini par la RFC 9114, transpose la sémantique HTTP sur les flux QUIC : mêmes méthodes, mêmes en-têtes et mêmes codes de statut, mais un format de trames et un transport différents.
HTTP/3 contre HTTP/2 : les changements pratiques
HTTP/2 a introduit le multiplexage : plusieurs requêtes partagent une connexion TCP. Mais TCP garantit la livraison ordonnée d'un flux unique d'octets. Lorsqu'un paquet est perdu, tous les octets suivants sont retenus jusqu'à sa retransmission, y compris ceux de flux HTTP/2 indépendants.
Un seul paquet perdu peut donc bloquer les 20 requêtes multiplexées sur la connexion. C'est le head-of-line blocking (HOL) au niveau du transport.
HTTP/3 supprime ce flux d'octets partagé. Chaque requête utilise son propre flux QUIC :
- un paquet perdu sur le flux 5 ne bloque pas les flux 6 à 24 ;
- les requêtes parallèles restent indépendantes ;
- le multiplexage fonctionne comme prévu, même en présence de pertes.
| Situation | HTTP/2 sur TCP + TLS 1.3 | HTTP/3 sur QUIC |
|---|---|---|
| Nouvelle connexion | 2 allers-retours (TCP + TLS) | 1 aller-retour |
| Reprise de connexion | 1 aller-retour | 0 aller-retour avec 0-RTT |
| Paquet perdu | Bloque tous les flux | Bloque un seul flux |
| Passage du Wi-Fi à la 5G | Reconnexion complète | Migration de la connexion |
| Chiffrement | Couche séparée, théoriquement optionnelle | TLS 1.3 intégré et obligatoire |
Attention au 0-RTT
Lorsqu'un client se reconnecte à un serveur déjà connu, QUIC peut envoyer des données applicatives dans le premier paquet, avant la fin de la poignée de main. Cela réduit la latence, mais ces données peuvent être capturées et rejouées.
Les serveurs ne devraient donc accepter en 0-RTT que des requêtes idempotentes. Un GET rejoué est généralement sans conséquence ; un POST rejoué qui débite une carte bancaire ne l'est pas. Si vous activez le 0-RTT à la périphérie, excluez les appels non idempotents ou vérifiez que votre CDN le fait déjà.
Ce que HTTP/3 change pour vos API
Une mise à niveau de protocole n'est utile que si elle produit un gain mesurable.
Une connexion moins coûteuse à établir
Sur une connexion mobile avec un RTT de 60 ms, TCP + TLS nécessitent environ 120 ms avant l'envoi de la première requête API. HTTP/3 ramène ce délai à environ 60 ms, et presque zéro lors d'une reprise.
Le gain est intéressant pour les applications mobiles qui ouvrent souvent de nouvelles connexions : démarrages à froid, réveils en arrière-plan ou sessions courtes. Pour une intégration serveur à serveur qui conserve un pool de connexions actives, la poignée de main est amortie et l'amélioration sera faible.
Des connexions mobiles qui survivent au changement de réseau
Un utilisateur peut commencer une requête sur le Wi-Fi, entrer dans un ascenseur et basculer sur le réseau cellulaire. Avec TCP, la connexion échoue et la logique de réessai doit effectuer une reconnexion complète.
Avec QUIC, la connexion suit l'appareil vers le nouveau réseau. Vous obtenez moins de timeouts côté client et moins d'écritures interrompues à analyser dans les journaux.
Un multiplexage sans blocage HOL
Le gain est surtout visible lorsqu'un client envoie de nombreuses requêtes en parallèle : tableau de bord chargeant 15 widgets ou moteur de synchronisation envoyant un lot de mises à jour.
Sur un réseau stable, HTTP/2 et HTTP/3 se comportent de manière similaire. Avec 1 à 2 % de perte de paquets — Wi-Fi de conférence saturé ou réseau cellulaire dans le métro — HTTP/3 laisse les requêtes parallèles progresser indépendamment, tandis que HTTP/2 les bloque en cascade.
gRPC reste principalement sur HTTP/2
gRPC est conçu autour d'HTTP/2 : son contrat dépend notamment du cadrage et des trailers HTTP/2. L'écosystème gRPC n'a pas standardisé de mappage HTTP/3, et les implémentations courantes en Go, Java, Python et Node.js ne le proposent pas.
Kestrel pour .NET peut servir gRPC sur HTTP/3 à titre expérimental, mais cela reste une exception. Si vos performances internes reposent sur gRPC et HTTP/2, une migration vers HTTP/3 n'est généralement pas prioritaire.
Streaming et temps réel
Les Server-Sent Events fonctionnent sur HTTP/3 sans modification : SSE est une réponse HTTP longue durée.
Les WebSockets sont plus délicats. Leur mise à niveau a été conçue pour TCP ; l'équivalent HTTP/3, défini par la RFC 9220, ainsi que l'API WebTransport émergente, bénéficient encore d'un support incomplet. Le support de HTTP/3 ne devrait donc pas, à lui seul, déterminer le choix entre WebSockets et HTTP.
Quand HTTP/3 n'aidera pas
La plupart des problèmes de latence d'une API ne viennent pas du transport. Si un point de terminaison prend 400 ms à cause d'une requête SQL non indexée, HTTP/3 livrera cette réponse environ 60 ms plus tôt, mais elle restera lente.
La mise en cache, la conception des charges utiles, les requêtes N+1 et la réutilisation des connexions ont généralement plus d'impact. Un test de performance d'API structuré produira souvent des gains bien supérieurs à une mise à niveau du protocole.
HTTP/3 est particulièrement intéressant pour :
- les liens à forte latence, où chaque aller-retour économisé compte ;
- les réseaux avec pertes, grâce à la suppression du blocage HOL ;
- les clients mobiles qui changent de réseau en cours de session ;
- les applications qui ouvrent beaucoup de connexions courtes.
Pour une API JSON consommée par des serveurs de la même région sur un réseau fiable, la différence peut être visible dans les benchmarks mais imperceptible pour les utilisateurs.
Deux contraintes restent à prévoir :
- certains réseaux d'entreprise bloquent UDP 443 ; les clients reviennent alors automatiquement à HTTP/2 ;
- le chiffrement QUIC en espace utilisateur consomme actuellement plus de CPU par connexion qu'une pile TCP optimisée dans le noyau.
Support actuel : qui utilise HTTP/3 ?
L'adoption est déjà bien avancée :
- Navigateurs : Chrome, Edge, Firefox et Safari prennent tous en charge HTTP/3 par défaut.
- CDN et points d'accès : Cloudflare, Fastly, Akamai et CloudFront le supportent. Sur Cloudflare, l'activation se fait via un simple interrupteur. Le déploiement courant consiste à terminer HTTP/3 à la périphérie et à conserver HTTP/1.1 ou HTTP/2 entre la périphérie et l'origine.
-
Serveurs : Nginx propose un support expérimental depuis la version 1.25 avec
listen 443 quic;. Caddy l'active par défaut ; LiteSpeed et HAProxy le supportent. Apache httpd ne le supporte pas encore. - Environnements d'exécution : Node.js ne fournit pas de support serveur HTTP/3 stable intégré, ce qui renforce l'intérêt d'une terminaison au niveau du CDN.
-
curl : HTTP/3 est disponible avec
--http3si curl a été compilé avec une pile TLS compatible. Consultez la documentation HTTP/3 de curl pour connaître les versions concernées.
Vérifier si votre API sert HTTP/3
La découverte passe par l'en-tête de réponse Alt-Svc. Un serveur qui annonce HTTP/3 peut répondre à une première requête HTTP/2 avec :
alt-svc: h3=":443"; ma=86400
Cela indique au client que le service est également disponible via HTTP/3 sur UDP 443 pendant les prochaines 24 heures.
Vérifiez l'annonce avec curl :
curl -sI https://www.cloudflare.com | grep -i alt-svc
# alt-svc: h3=":443"; ma=86400
Pour forcer directement une requête HTTP/3, utilisez une version compatible :
curl --http3 -I https://cloudflare-quic.com
# HTTP/3 200
La ligne de statut doit indiquer HTTP/3 au lieu de HTTP/2.
Dans les outils de développement de Chrome :
- ouvrez l'onglet Réseau ;
- faites un clic droit sur l'en-tête d'une colonne ;
- activez la colonne Protocole ;
- 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 trafic h2 et h3 vous indiquera combien de clients bénéficient de HTTP/3.
Enfin, vérifiez aussi le comportement de l'API. Dirigez Apidog vers les mêmes points de terminaison et comparez les codes de statut, les schémas de réponse et les budgets de latence. Téléchargez Apidog gratuitement, exécutez la même suite de tests avant et après l'activation de HTTP/3 à la périphérie, puis mesurez les temps de réponse sur les réseaux mobiles.
FAQ
HTTP/3 est-il plus rapide que HTTP/2 ?
Sur un réseau propre et peu lent, à peine. Sur un réseau à forte latence ou avec des pertes, souvent oui : HTTP/3 économise un aller-retour de poignée de main et un paquet perdu ne bloque plus toutes les requêtes multiplexées.
Mesurez avec votre propre trafic avant de conclure. HTTP/2 reste une excellente option. Les erreurs de connexion sont généralement liées à la couche TLS, par exemple le problème SSLV3_ALERT_HANDSHAKE_FAILURE, plutôt qu'à une limite de HTTP/2.
HTTP/3 utilise-t-il TCP ?
Non. HTTP/3 fonctionne sur QUIC, lui-même basé sur UDP, généralement sur le port 443. QUIC réimplémente la fiabilité, l'ordonnancement et le contrôle de congestion de TCP, mais par flux et dans l'espace utilisateur.
Si UDP 443 est bloqué, le client revient automatiquement à HTTP/2 sur TCP.
Dois-je modifier le code de mon API ?
Presque jamais. Les méthodes, en-têtes, codes de statut et corps HTTP restent ident majoritairement non. Le format de données de gRPC est lié à HTTP/2 et les bibliothèques gRPC courantes ne proposent pas de transport HTTP/3 stable. .NET dispose d'un support expérimental.
Conservez vos services gRPC sur HTTP/2 et adoptez HTTP/3 là où le gain est le plus probable : points de terminaison REST publics, applications mobiles et clients orientés navigateur.
Top comments (0)