HTTP/2

HTTP/2 (initialement nommé HTTP/2.0 ) est une révision majeure du protocole réseau HTTP utilisé par le World Wide Web . Il est dérivé du protocole expérimental SPDY , développé à l'origine par Google . HTTP/2 a été développé par le groupe de travail HTTP (également appelé httpbis, où « bis » signifie « deux fois ») de l' Internet Engineering Task Force (IETF). HTTP/2 est la première nouvelle version de HTTP depuis HTTP/1.1, qui a été normalisé dans la RFC 2068 en 1997. Le groupe de travail a présenté HTTP/2 à l' Internet Engineering Steering Group (IESG) pour examen en tant que norme proposée en décembre 2014, et l'IESG a approuvé sa publication en tant que norme proposée le 17 février 2015 (et a été mis à jour en février 2020 en ce qui concerne TLS 1.3 et à nouveau en juin 2022). La spécification HTTP/2 initiale a été publiée le 14 mai 2015.

L'effort de normalisation a été soutenu par les navigateurs Chrome , Opera, Firefox, Internet Explorer 11, Safari, Amazon Silk et Edge. La plupart des principaux navigateurs avaient ajouté la prise en charge de HTTP/2 à la fin de 2015. Environ 97 % des navigateurs Web utilisés ont cette capacité (et 100 % des navigateurs Web de bureau « suivis »). En juillet 2023 , 36 % (après avoir plafonné à un peu plus de 50 %) des 10 millions de sites Web les plus importants prennent en charge HTTP/2.

Son successeur est HTTP/3 , une révision majeure qui s'appuie sur les concepts établis par HTTP/2.

La charte du groupe de travail mentionne plusieurs objectifs et sujets de préoccupation :

• Créez un mécanisme de négociation qui permet aux clients et aux serveurs de choisir d’utiliser HTTP/1.1, 2.0 ou potentiellement d’autres protocoles non HTTP.
• Maintenir une compatibilité de haut niveau avec HTTP/1.1 (par exemple avec les méthodes , les codes d'état , les URI et la plupart des champs d'en-tête ).
• Réduisez la latence pour améliorer la vitesse de chargement des pages dans les navigateurs Web en prenant en compte :
  • compression des données des en-têtes HTTP
  • Serveur HTTP/2 Push
  • priorisation des demandes
  • multiplexage de plusieurs requêtes sur une seule connexion TCP (résolution du problème de blocage de tête de ligne au niveau des transactions HTTP dans HTTP 1.x)
• Prend en charge les cas d'utilisation courants existants de HTTP, tels que les navigateurs Web de bureau, les navigateurs Web mobiles, les API Web, les serveurs Web à différentes échelles, les serveurs proxy , les serveurs proxy inverses , les pare-feu et les réseaux de diffusion de contenu .

Les modifications proposées ne nécessitent aucune modification du fonctionnement des applications Web existantes, mais les nouvelles applications peuvent tirer parti de nouvelles fonctionnalités pour une vitesse accrue. HTTP/2 conserve toute la sémantique de haut niveau de HTTP/1.1, comme les méthodes , les codes d'état , les champs d'en-tête et les URI . Ce qui est nouveau, c'est la façon dont les données sont encadrées et transportées entre le client et le serveur.

Les sites Web efficaces réduisent le nombre de requêtes nécessaires pour afficher une page entière en minimisant (en réduisant la quantité de code et en regroupant les plus petits morceaux de code dans des paquets, sans réduire leur capacité de fonctionnement) les ressources telles que les images et les scripts. Cependant, la minimisation n'est pas nécessairement pratique ni efficace et peut toujours nécessiter des connexions HTTP distinctes pour obtenir la page et les ressources minimisées. HTTP/2 permet au serveur de « pousser » du contenu, c'est-à-dire de répondre avec des données pour plus de requêtes que ce que le client a demandé. Cela permet au serveur de fournir des données dont il sait qu'un navigateur Web aura besoin pour afficher une page Web, sans attendre que le navigateur examine la première réponse et sans la surcharge d'un cycle de requête supplémentaire.

Les améliorations de performances supplémentaires dans la première version de HTTP/2 (qui était une copie de SPDY) proviennent du multiplexage des requêtes et des réponses pour éviter certains problèmes de blocage de tête de ligne dans HTTP 1 (même lorsque le pipeline HTTP est utilisé), de la compression d'en-tête et de la priorisation des requêtes. Cependant, comme HTTP/2 s'exécute sur une seule connexion TCP, il existe toujours un risque de blocage de tête de ligne si les paquets TCP sont perdus ou retardés dans la transmission. d'encodage de transfert fragmenté de HTTP/1.1 , car il fournit ses propres mécanismes plus efficaces pour le streaming de données.

SPDY (prononcé comme « speedy ») était un ancien protocole de remplacement de HTTP développé par un projet de recherche dirigé par Google . Principalement axé sur la réduction de la latence, SPDY utilise le même canal TCP mais des protocoles différents pour réaliser cette réduction. Les modifications de base apportées à HTTP/1.1 pour créer SPDY comprenaient « un véritable pipeline de requêtes sans restrictions FIFO, un mécanisme de cadrage des messages pour simplifier le développement client et serveur, une compression obligatoire (y compris les en-têtes), une planification des priorités et même une communication bidirectionnelle ».

Le groupe de travail HTTP a étudié le protocole SPDY de Google, la proposition HTTP Speed+Mobility de Microsoft (basée sur SPDY) et la mise à niveau HTTP compatible avec le réseau . En juillet 2012, Facebook a fourni des commentaires sur chacune des propositions et a recommandé que HTTP/2 soit basé sur SPDY . Le projet initial de HTTP/2 a été publié en novembre 2012 et était basé sur une copie pure et simple de SPDY

La plus grande différence entre HTTP/1.1 et SPDY est que chaque action utilisateur dans SPDY reçoit un « identifiant de flux », ce qui signifie qu'il existe un seul canal TCP reliant l'utilisateur au serveur. SPDY divise les requêtes en contrôle ou en données, en utilisant un « protocole binaire simple à analyser avec deux types de trames ». SPDY a montré une amélioration évidente par rapport à HTTP, avec une nouvelle accélération du chargement des pages allant de 11 % à 47 %.

Le développement de HTTP/2 a utilisé SPDY comme point de départ. Parmi les nombreuses différences détaillées entre les protocoles, la plus notable est que HTTP/2 utilise un algorithme de compression d'en-tête fixe basé sur le code Huffman , au lieu de la compression dynamique basée sur le flux de SPDY. Cela permet de réduire le risque d' attaques par oracle de compression sur le protocole, telles que l' attaque CRIME .

Le 9 février 2015, Google a annoncé son intention de supprimer la prise en charge de SPDY dans Chrome au profit de la prise en charge de HTTP/2. Cette décision a pris effet à partir de Chrome 51.

HTTP/2 est défini à la fois pour les URI HTTP (c'est-à-dire sans cryptage TLS , une configuration qui est abrégée en h2c ) et pour les URI HTTPS (sur TLS en utilisant l'extension ALPN où TLS 1.2 ou plus récent est requis, une configuration qui est abrégée en h2 ).

Bien que la norme elle-même ne nécessite pas l'utilisation du cryptage, toutes les principales implémentations client (Firefox, Chrome, Safari, Opera, IE, Edge) ont déclaré qu'elles ne prendraient en charge que HTTP/2 sur TLS, ce qui rend le cryptage de facto obligatoire.

Poul-Henning Kamp, développeur de FreeBSD et de Varnish, affirme que la norme a été préparée dans un délai irréaliste, ce qui a exclu toute base pour le nouveau HTTP/2 autre que le protocole SPDY et a entraîné d'autres opportunités manquées d'amélioration. Kamp critique le protocole lui-même pour son incohérence et sa complexité inutile et écrasante. Il déclare également que le protocole viole le principe de superposition de protocoles , par exemple en dupliquant le contrôle de flux qui appartient à la couche transport (TCP). Il a également suggéré que le nouveau protocole aurait dû supprimer les cookies HTTP , introduisant un changement radical.

Au début, certains membres du groupe de travail ont tenté d'introduire une exigence de chiffrement dans le protocole. Cette proposition a suscité des critiques.

Les critiques ont déclaré que le chiffrement a des coûts informatiques non négligeables et que de nombreuses applications HTTP n'ont en fait pas besoin de chiffrement et que leurs fournisseurs n'ont aucune envie de dépenser des ressources supplémentaires pour cela. Les partisans du chiffrement ont déclaré que cette surcharge de chiffrement est négligeable dans la pratique. Poul-Henning Kamp a critiqué l'IETF pour avoir normalisé à la hâte le prototype SPDY de Google en HTTP/2 en raison de considérations politiques. La critique du programme de chiffrement obligatoire dans le cadre de certificat existant n'est pas nouvelle, ni unique aux membres de la communauté open source - un employé de Cisco a déclaré en 2013 que le modèle de certificat actuel n'est pas compatible avec les petits appareils comme les routeurs, car le modèle actuel nécessite non seulement une inscription annuelle et la remise de frais non négligeables pour chaque certificat, mais doit être continuellement répété sur une base annuelle. Au final, le groupe de travail n'est pas parvenu à un consensus sur le chiffrement obligatoire, bien que la plupart des implémentations client l'exigent, ce qui fait du chiffrement une exigence de facto .

Le protocole HTTP/2 a également été critiqué pour ne pas prendre en charge le chiffrement opportuniste , une mesure contre la surveillance passive similaire au mécanisme STARTTLS qui est disponible depuis longtemps dans d'autres protocoles Internet comme SMTP . Les critiques ont déclaré que la proposition HTTP/2 viole la RFC 7258 de l'IETF « Pervasive Monitoring Is an Attack », qui a également le statut de Best Current Practice 188. La RFC7258/BCP188 exige que la surveillance passive soit considérée comme une attaque, et les protocoles conçus par l'IETF doivent prendre des mesures pour se protéger contre la surveillance passive (par exemple, par l'utilisation d'un chiffrement opportuniste). Un certain nombre de spécifications pour le chiffrement opportuniste de HTTP/2 ont été fournies, dont draft-nottingham-http2-encryption a été adopté comme élément de travail officiel du groupe de travail, conduisant à la publication de la RFC 8164 en mai 2017.

Bien que la conception de HTTP/2 résolve efficacement le problème du blocage de tête de ligne au niveau des transactions HTTP en autorisant plusieurs transactions HTTP simultanées, toutes ces transactions sont multiplexées sur une seule connexion TCP, ce qui signifie que tout blocage de tête de ligne au niveau des paquets du flux TCP bloque simultanément toutes les transactions accessibles via cette connexion. Ce blocage de tête de ligne dans HTTP/2 est désormais largement considéré comme un défaut de conception, et une grande partie des efforts derrière QUIC et HTTP/3 a été consacrée à réduire les problèmes de blocage de tête de ligne.

Les serveurs Web suivants prennent en charge HTTP/2 :

• Apache httpd 2.4.12 prend en charge HTTP/2 via le module mod_h2, bien que des correctifs appropriés doivent être appliqués au code source du serveur pour qu'il prenne en charge ce module. Depuis Apache 2.4.17, tous les correctifs sont inclus dans l'arborescence principale des sources d'Apache, bien que le module lui-même ait été renommé mod_http2. Les anciennes versions de SPDY étaient prises en charge via le module mod_spdy, cependant le développement du module mod_spdy a été arrêté.
• Apache Tomcat 8.5 (nécessite une modification de configuration)
• Serveur de trafic Apache
• Caddie
• Charles Proxy depuis la version Charles 4.
• Citrix NetScaler 11.x
• Sucreries
• Gestionnaire de trafic local F5 BIG-IP 11.6
• Pare-feu d'application Web (WAF) de Barracuda Networks
• h2o (construit dès le départ pour la prise en charge HTTP/2)
• HAProxy 1.8
• Jetée 9.3
• lighttpd 1.4.56
• Serveur Web LiteSpeed ​​5.0
• Microsoft IIS (dans Windows 10, Windows Server 2016 et Windows Server 2019 )
• Netty 4.1
• nghttpd (implémente exclusivement HTTP/2)
• nginx 1.9.5 est sorti le 22 septembre 2015, utilisant le module ngx_http_v2_module et HTTP/2 Server Push depuis la version 1.13.9 le 20 février 2018.
• Node.js 8.13.0 (Un module séparé est disponible pour Node.js 5.0 et Node 8.4 a introduit un support intégré expérimental pour HTTP/2. )
• Le serveur Web Kestrel pour ASP.NET Core prend en charge HTTP/2 depuis .NET Core 2.2.0-preview 1.
• OpenLiteSpeed ​​1.3.11 et 1.4.8
• Proxygène
• Gestionnaire de trafic virtuel sécurisé Pulse 10.2
• Radware Alteon NG
• Chat Shimmer
• Vert.x 3.3
• Warp ( serveur Web Haskell , utilisé par défaut dans Yesod )
• Mouche sauvage 9
• Envoyé mandataire

• Akamai a été le premier CDN majeur à prendre en charge HTTP/2 et HTTP/2 Server Push .
• Microsoft Azure prend en charge HTTP/2.
• PageCDN prend en charge HTTP/2 dès la sortie de la boîte et fournit une interface utilisateur pour configurer HTTP/2 Server Push dans le tableau de bord CDN.
• CDN77 prend en charge HTTP/2 en utilisant nginx (20 août 2015) .
• Cloudflare prend en charge HTTP/2 en utilisant nginx avec SPDY comme solution de secours pour les navigateurs sans prise en charge, tout en conservant tous les services de sécurité et de performances. Cloudflare a été le premier CDN majeur à prendre en charge HTTP/2 Server Push .
• AWS CloudFront prend en charge HTTP/2 depuis le 7 septembre 2016.
• Prend en charge rapidement HTTP/2, y compris Server Push.
• Imperva Incapsula CDN prend en charge HTTP/2. L'implémentation inclut également la prise en charge des fonctionnalités d'atténuation WAF et DDoS.
• KeyCDN prend en charge HTTP/2 avec nginx (6 octobre 2015). HTTP/2 Test est une page de test pour vérifier si votre serveur prend en charge HTTP/2.
• BrandSSL prend en charge HTTP/2.
• Voxility prend en charge HTTP/2 à l'aide de nginx depuis juillet 2016. L'implémentation prend en charge les services d'atténuation des attaques DDoS dans le Cloud.
• StackPath prend en charge HTTP/2.

• D'autres implémentations sont collectées sur le wiki GitHub HTTP/2.