Pourquoi HTTP/3 est largement pris en charge mais presque pas utilisé en pratique

• HTTP/3 est en développement depuis 2016, et son protocole sous-jacent, QUIC, a été introduit pour la première fois par Google en 2013
• Il est désormais standardisé et bénéficie d’une large prise en charge :
  • Pris en charge par 95 % des navigateurs
  • 32 % des requêtes HTTP de Cloudflare utilisent HTTP/3
  • 35 % des sites web affichent une prise en charge de HTTP/3 (via alt-svc ou le DNS)
• Cependant, les bibliothèques standard des principaux langages manquent encore de prise en charge de QUIC et HTTP/3
  • Non inclus dans les bibliothèques standard de Node.js, Go, Rust, Python, Ruby, etc.
  • Curl a récemment ajouté la prise en charge de HTTP/3, mais elle reste expérimentale et désactivée par défaut
  • Le serveur populaire Nginx en est encore à une prise en charge expérimentale, désactivée par défaut
  • Apache n’a aucun projet de prise en charge de HTTP/3
  • Ingress-Nginx de Kubernetes a abandonné son projet de prise en charge de HTTP/3

Pourquoi il fallait aller au-delà de HTTP/1.1

• HTTP/3 est utile pour les navigateurs web et le trafic CDN à forte latence
• Principaux avantages apportés par HTTP/2 et HTTP/3 :
  • Le multiplexage réduit le temps d’attente des réponses
  • La compression des en-têtes HTTP réduit le trafic (avec HPACK et QPACK)
  • Le streaming bidirectionnel permet l’échange de données en temps réel entre client et serveur
  • La priorisation permet de traiter d’abord les requêtes importantes
• Avantages supplémentaires de HTTP/3 :
  • Le traitement indépendant des flux fait qu’une perte de paquets n’affecte pas les autres flux
  • Le handshake TLS en 0-RTT améliore la vitesse d’initialisation de la connexion
  • La migration de connexion permet de maintenir la connexion lors d’un changement d’adresse IP
  • Une meilleure gestion de la congestion améliore les performances et la stabilité

Les gains de performance de HTTP/3

• Résultats des benchmarks de RequestMetric :
  • HTTP/3 offre des temps de réponse plus rapides que HTTP/1.1 et HTTP/2
• Cas concret chez Fastly :
  • Le temps jusqu’au premier octet a été réduit de 18 % avec HTTP/3

Le problème du manque de prise en charge de HTTP/3

• HTTP/3 est largement pris en charge par les navigateurs et les CDN, mais reste difficile à utiliser pour les développeurs ordinaires
• Il existe aujourd’hui deux types de trafic web :
  • Le web hyperscale : fondé sur les grands navigateurs et de gros serveurs (Google, Meta, Amazon, etc.)
  • Le web de longue traîne : fondé sur des serveurs et clients petits ou moyens (API backend, applications mobiles, IoT, etc.)
• Différences principales :
  • Le trafic de longue traîne représente 67 % du trafic total
  • L’hyperscale peut développer et déployer rapidement, tandis que la longue traîne manque de ressources et privilégie la stabilité
  • Sa dépendance aux outils open source est élevée

OpenSSL et le problème de QUIC

• OpenSSL est à la base de la plupart des outils réseau open source
• BoringSSL a lancé une API compatible QUIC en 2018, mais OpenSSL a introduit sa propre API QUIC
• Principaux problèmes :
  • Elle n’est pas compatible avec les implémentations existantes basées sur BoringSSL
  • Curl et les principaux langages ont du mal à changer leur dépendance à OpenSSL
  • Node.js a envisagé d’utiliser BoringSSL à la place d’OpenSSL, mais cela n’a pas abouti

Perspectives

• À mesure que le web hyperscale adopte HTTP/3, un écart de performance risque de se creuser avec le web de longue traîne
• Le manque de prise en charge de HTTP/3 pourrait entraîner les problèmes suivants :
  • Renforcement de l’avantage des sites hyperscale en vitesse et en stabilité
  • Si les frameworks fondés sur HTTP/3 se généralisent, le web de longue traîne pourrait avoir du mal à y accéder
  • L’absence de prise en charge de HTTP/3 pourrait être utilisée comme critère de blocage des clients
• Pistes de solution :
  • Il faut résoudre les problèmes liés à l’API QUIC d’OpenSSL
  • Il faut développer des outils et des adaptateurs améliorant la compatibilité avec les implémentations existantes de QUIC et HTTP/3
  • Il faut élargir les efforts de prise en charge de HTTP/3 dans les outils open source

Conclusion

• HTTP/3 apporte clairement des avantages en performances et en stabilité, mais aujourd’hui seules les entreprises hyperscale peuvent l’utiliser facilement
• Des améliorations des outils et des standards sont nécessaires pour rendre HTTP/3 facilement utilisable aussi sur le web de longue traîne

[GN⁺]

Avis Hacker News

• Certains estiment qu’il est difficile de trouver des outils open source populaires prenant entièrement en charge HTTP/3

  • Les administrateurs IT et les ingénieurs DevOps terminent généralement les connexions HTTP/3 au niveau du load balancer, terminent ensuite le SSL, puis transmettent du HTTP 1.1 aux services backend
  • HTTP/3 et IPv6 sont des technologies davantage orientées mobile, plus utiles sur des connexions temporaires et instables que dans les data centers

• Les bibliothèques standard des principaux langages n’incluent ni QUIC ni HTTP/3

  • .NET offre une prise en charge correcte de HTTP/3
  • La plupart des équipes de développement ne construisent pas de produits centrés sur le réseau, donc HTTP/3 reste une faible priorité

• Le principal problème d’un déploiement à grande échelle de HTTP/3 est l’augmentation de la surface de code potentiellement vulnérable

  • Il serait préférable que le système d’exploitation fournisse une couche de sockets sûre et des bibliothèques SSL liées dynamiquement
  • Dans la plupart des applications clientes, quelques millisecondes de latence sur les requêtes ne constituent pas un problème majeur

• L’adoption lente de QUIC s’explique par le fait qu’OpenSSL ne fournissait pas les briques de base nécessaires aux implémentations QUIC existantes

  • Récemment, OpenSSL 3.5 a commencé à fournir une API pour les stacks QUIC tierces

• HTTP/2 et HTTP/3 ne sont plus perçus comme des protocoles de couche applicative, mais plutôt comme relevant du niveau TCP et TLS

  • Les développeurs vivent encore dans un monde de « HTTP 1.1 en clair »

• nginx ne propose toujours pas de prise en charge de HTTP/3 prête pour la production

• Certains utilisent niquests en Python, qui prend en charge HTTP/3

  • L’écosystème Python est resté attaché au paquet requests par inertie

• Node.js a publié une mise à jour sur l’état de QUIC et rencontre des difficultés à cause du support tardif des API par OpenSSL

• Lorsqu’on utilise les load balancers des fournisseurs de cloud public, HTTP/3 est utilisé par défaut

  • Les sites qui utilisent leurs propres serveurs ne profitent pas vraiment des avantages de HTTP/3

• Tous les projets reposent dans une certaine mesure sur l’open source et sont pilotés par la communauté

  • Ils ne ressentent pas le besoin de prendre rapidement en charge HTTP/3