Hypertext Transfer Protocol/2

HTTP/2 (nommé initialement HTTP/2.0) est une version majeure du protocole réseau HTTP utilisé sur le World Wide Web. Il est issu du protocole expérimental SPDY développé par Google^[2].

HTTP/2^[3] a été développé par un groupe de travail appelé httpbis issu de l’IETF^[4]. HTTP/2 est la version la plus récente du protocole HTTP depuis la publication de HTTP 1.1 en 1997 (RFC 2068^[5]). Le groupe de travail a soumis HTTP/2 à l’IESG comme proposition de standard en décembre 2014^[6],[7] et l’IESG l’a approuvé le 17 février 2015^[8],[9]. La spécification HTTP/2 a été publiée en mai 2015 à travers la RFC 7540^[1].

L'adoption du protocole a été entamée par les navigateurs Web Chrome, Opera, Firefox, Internet Explorer 11, Safari, Amazon Silk et Edge. Ce faisant, la majorité des navigateurs prenaient en charge HTTP/2 dès la fin de l’année 2015.

Selon le site W3Techs, en juin 2016 8,4 % des dix millions de sites web les plus visités prennent en charge HTTP/2^[10].

Le groupe de travail httpbis a évoqué plusieurs objectifs et points d’attention^[4] :

• mécanisme de négociation entre le client et le serveur pour choisir quel protocole utiliser entre HTTP/1.1, HTTP/2 ou tout protocole autre que HTTP ;
• conservation d’une compatibilité avec HTTP 1.1, par exemple sur les méthodes, les codes, les URI ou les headers existants ;
• réduction de la latence pour améliorer les temps de chargement des navigateurs web notamment par :
  • la compression de données des en-têtes HTTP,
  • le nouveau mécanisme de push de HTTP/2 permettant au serveur d’envoyer au client des données nécessaires mais qu’il n’a pourtant pas encore sollicitées,
  • la résolution de problèmes propres à HTTP 1.x (voir HTTP pipelining ou head-of-line blocking (en)),
  • le multiplexage de plusieurs requêtes au travers d’une seule connexion TCP ;
• prise en charge des usages courants du protocole HTTP tels que les navigateurs web des ordinateurs, les navigateurs web des tablettes et GSM, les interfaces de programmation ou API, les serveurs web, les Proxy et proxys inversés, les firewalls et les Content delivery network.

HTTP/2 ne demande pas de modification des applications web existantes, un effort ayant été apporté sur la rétrocompatibilité avec HTTP 1.1. Les applications web existantes ou futures peuvent être développées pour bénéficier des nouveautés proposées notamment pour les gains de vitesse de transmission^[11].

HTTP/2 conserve l'intégralité de la syntaxe de HTTP 1.1, comme les méthodes, les codes, les URI ou les headers. Un élément a été modifié : la manière dont la donnée est segmentée et transportée entre le client et les serveurs^[11].

En HTTP 1.1, les sites web efficaces réduisent le nombre de requêtes pour afficher une page en minifiant les ressources (javascript, images, etc.). De telles pratiques ne seront plus nécessaires avec HTTP/2 et le système de push permettant au serveur d’envoyer au client les ressources nécessaires avant même qu’il ne les sollicite, économisant connexions HTTP et charge des en-têtes. Ces pratiques de minifications nécessitant parfois des connexions HTTP séparées, pourraient alors devenir contre-productives et réduire la vitesse de chargement des sites web concernés^[12].

D’autres améliorations de performances, issues du protocole SPDY dont HTTP/2 est issu, viennent du multiplexage des requêtes et des réponses, évitant le problème head-of-line blocking (en) de HTTP 1, la compression de données des en-têtes HTTP et la priorisation des requêtes^[13].

SPDY (à prononcer comme le mot anglais speedy) était un projet de protocole de remplacement de HTTP précédent lancé par Google^[14]. SPDY se focalisait sur la réduction des latences. SPDY utilisait le même fonctionnement TCP mais utilisait différents protocoles pour parvenir à cette réduction. Les changements apportés à HTTP 1.1 par SPDY comprenaient : un véritable pipelining des requêtes sans restrictions FIFO, segmentation des messages pour simplifier le développement des clients et des serveurs, compression obligatoire (y compris des en-têtes), planification des priorités et communication bi-directionnelle ^[15].

Le groupe de travail httpbis s’est appuyé sur les travaux menés par SPDY ainsi qu’une proposition de Microsoft appelée HTTP Speed+Mobility, elle aussi basée sur SPDY^[14], and Network-Friendly HTTP Upgrade^[16]. En juillet 2012, Facebook remonta des commentaires sur chaque proposition du groupe de travail et recommanda que HTTP/2 soit basé sur SPDY^[17]. Le premier brouillon de HTTP/2 fut publié en novembre 2012 et se basait sur une simple copie de SPDY^[18].

La plus grande différence entre HTTP 1.1 et SPDY était que chaque action de l’utilisateur dans SPDY se voyait attribuer un stream ID, impliquant une seule connexion TCP entre le client et le serveur. SPDY divisait les requêtes entre contrôle et données^[15]. SPDY a démontré une amélioration par rapport à HTTP, avec un temps de chargement de page passé de 11,81 % à 47,7 %^[19], mélangeant alors couche applicative et couche transport du modèle OSI

Le développement de HTTP/2 a utilisé SPDY comme point de départ. Des divergences sont rapidement apparues. Parmi ces différences, la plus remarquable est que HTTP/2 utilise un codage de Huffman pour la compression des en-têtes, là où SPDY utilisait une compression à la volée. Ceci réduit les risques d’attaques comme CRIME (en) illustré par Oracle attack (en)

Le 9 février 2015, Google annonça le retrait futur de SPDY de Chrome en faveur de HTTP/2^[20]. Cette annonce fut appliquée à partir de Chrome 51^[21],[22].

HTTP/2 prend en charge les URI HTTP (i.e. sans chiffrement) et les URIs HTTPS (avec chiffrement TLS, dont la version 1.2 ou plus récente est exigée)^[23].

Le standard en lui-même n’impose pas l’usage du chiffrement^[24], mais la plupart des implémentations (Firefox^[25], Chrome, Safari, Opera, IE, Edge) imposent l’usage de TLS pour HTTP/2 rendant de facto obligatoire l’usage du chiffrement^[26],[27].

Le protocole HTTP/2 et son processus de développement ont soulevé des critiques.

Poul-Henning Kamp, développeur FreeBSD et Varnish, prétendit que la rédaction du standard était basée sur un calendrier de réalisation irréaliste car trop court, ce qui aurait eu pour conséquence d’ignorer toute autre base que SPDY et empêché la prise en considération d’autres possibilités^[28]. Kamp a aussi critiqué le protocole en lui-même, le qualifiant d'incohérent et présentant une complexité inutile et accablante^[28]. Il a également affirmé que le protocole violait le modèle OSI^[28], par exemple en dupliquant le contrôle de flux qui appartient à la couche de transport (TCP).

Cependant, la plupart des préoccupations étaient liées au chiffrement.

Initialement, des membres^[Qui ?] du groupe de travail tentèrent d’imposer le chiffrement dans le protocole. Cette volonté rencontra une opposition.

Les critiques soulignaient que le chiffrement imposait des coûts importants en termes de temps de calcul des processeurs et que de nombreuses applications HTTP ne nécessitent aucun chiffrement et que leurs fournisseurs ne souhaitent pas dépenser des ressources supplémentaires pour ces applications. Les partisans du chiffrement rétorquèrent que le surcoût réel du chiffrement est négligeable dans la pratique^[29]. Poul-Henning Kamp a accusé l’IETF de suivre des considérations politiques avec le calendrier de travail de HTTP/2^{[28],[30],[31]}. La critique du calendrier imposant le chiffrement avec le système de certification actuel n’est pas nouvelle ni cantonnée aux partisans du logiciel libre. Un salarié de Cisco affirma en 2013 que le fonctionnement actuel de la certification n’était pas compatible avec les petits matériels comme les routeurs car il impose une redevance annuelle non-anecdotique pour la souscription ou le renouvellement de chaque certificat^[32].

Finalement, le consensus sur le chiffrement ne fut pas atteint et l’obligation de chiffrement retirée du standard^[24], cependant la plupart des implémentations du standard l’imposent, le rendant obligatoire de facto.

Le protocole HTTP/2 a aussi été critiqué car il ne prend pas en charge le chiffrement opportuniste, une mesure contre l’écoute du trafic (passive monitoring (en)) similaire à StartTLS qui est disponible de longue date dans d’autres protocoles tel que SMTP. Certains opérateurs de sites web et hackers ont reproché à HTTP/2 de violer les recommandations de l’IETF Pervasive Monitoring Is an Attack, qui a pourtant le statut de bonne pratique 188^[33].

La rfc7258/BCP188 affirme que l’écoute du trafic est considérée comme une attaque et que les protocoles publiés par l’IETF doivent prendre des mesures de protection contre cette pratique (en utilisant, par exemple, le chiffrement opportuniste). Des spécifications concernant le chiffrement opportuniste ont été soumises^{[34],[35],[36]}, parmi lesquelles le draft-ietf-httpbis-http2-encryption-01 est un élément de travail officiel du groupe.

Serveur HTTP :

• Apache 2.4.12 prend en charge HTTP/2 via le module mod_h2^[53],
• Apache Tomcat prend en charge HTTP/2 avec les versions 8.5 et supérieures avec un changement à réaliser dans la configuration^[54].
• Apache Traffic Server prend en charge HTTP/2^[55].
• Caddy prend en charge HTTP/2^[56].
• Citrix NetScaler 11.x prend en charge HTTP/2^[57].
• Sucuri prend en charge HTTP/2^[58].
• F5 BIG-IP Local Traffic Manager 11.6 prend en charge HTTP/2^[59].
• gRPC, framework RPC open source initialement développé par Google.
• h2o a été créé pour prendre en charge HTTP/2^[60].
• Jetty 9.3 prend en charge HTTP/2^[61].
• lighttpd n’a pas de support pour SPDY et HTTP/2 a été intégré à la version 1.5^{[réf. souhaitée]}.
• LiteSpeed Web Server 5.0 prend en charge HTTP/2^[62].
• Microsoft IIS prend en charge HTTP/2 depuis Windows 10^[63] et Windows Server 2016.
• Netty 4.1 prend en charge HTTP/2^[64].
• nginx 1.9.5 prend en charge HTTP/2^[65].
• node.js 5.0 prend en charge HTTP/2^[66].
• OpenLiteSpeed 1.3.11 et 1.4.8 prennent en charge HTTP/2^[67].
• Proxygen prend en charge HTTP/2.
• Radware Alteon NG prend en charge HTTP/2^[68].
• ShimmerCat a été créé pour prendre en charge HTTP/2^[69].
• Vert.x 3.3 prend en charge HTTP/2
• Warp lié à Haskell, utilisé dans Yesod (web framework) (en), prend en charge HTTP/2.
• Wildfly 9 prend en charge HTTP/2.

Content delivery networks :

• Akamai prend en charge HTTP/2^[70].
• CDN77 prend en charge HTTP/2 via nginx (August 20, 2015). http2demo.io is a demonstration of CDN77's HTTP/2 implementation.
• CloudFlare prend en charge HTTP/2 via nginx^[71].
• AWS CloudFront prend en charge HTTP/2 ^[72]
• Fastly prend en charge HTTP/2^[73].
• Imperva Incapsula CDN prend en charge HTTP/2^[74]. http2.incapsula.com showcases Incapsula's HTTP/2 implementation. The implementation includes support for WAF and DDoS mitigation features as well.
• KeyCDN supports HTTP/2 using nginx (October 6, 2015). HTTP/2 Test is a test page to verify if your server supports HTTP/2.
• Baleen prend en charge HTTP/2 via nginx

Mise en Å“uvre :

• La page GitHub HTTP/2 wiki collecte les informations de mise en Å“uvre

• Hypertext Transfer Protocol
• SPDY
• Comparaison des navigateurs web#Support des protocoles

• Site officiel
• RFC 7540^[1] – Hypertext Transfer Protocol version 2 (HTTP/2)
• RFC 7541^[75] – HPACK: Header Compression for HTTP/2
• SPDY Protocol (draft-mbelshe-httpbis-spdy-00)
• HTTP Speed+Mobility (draft-montenegro-httpbis-speed-mobility-01)
• Proposal for a Network-Friendly HTTP Upgrade (draft-tarreau-httpbis-network-friendly-00)

• Portail des réseaux informatiques
• Portail de l’informatique
• Portail des télécommunications
• Portail d’Internet