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 [6],[7] et l’IESG l’a approuvé le [8],[9]. La spécification HTTP/2 a été publiée en à travers la RFC 7540[1].
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,
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 , 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 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 , 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].
Chiffrement
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].
Critiques
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.
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.
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.
↑Chris Bentzel et Bence Béky, « Hello HTTP/2, Goodbye SPDY », Chromium Blog, : « Update: To better align with Chrome's release cycle, SPDY and NPN support will be removed with the release of Chrome 51. »
