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].
Fonction | Transmission d'hypertexte |
---|---|
Sigle | HTTP/2 |
Date de création | 2014 |
Port | 80 |
RFC | 2015 : RFC 7540[1] |
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’approuva le [8],[9]. La spécification HTTP/2 fut publiée en via la RFC 7540[1].
Les efforts pour prendre en charge le protocole furent entrepris 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 8,4 % des 10 millions de sites web les plus visités prennent en charge HTTP/2[10].
Objectifs
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 via :
- 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 ;
- résolution de problèmes propres à HTTP 1.x (voir HTTP pipelining ou head-of-line blocking (en)) ;
- 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.
Différences avec HTTP 1.1
HTTP/2 ne demande pas de modification des applications web existantes, un effort ayant été apporté sur la rétro-compatibilité avec HTTP 1.1. Mais 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 la majorité 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] ce qui n’a pas d’impact sur les applications existantes.
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. Pire, 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].
Genèse puis divergence avec SPDY
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].
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[27]. Kamp a aussi critiqué le protocole en lui-même, le qualifiant d'incohérent et présentant une complexité inutile et accablante[27]. Il a également affirmé que le protocole violait le modèle OSI[27], 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[28]. Poul-Henning Kamp a accusé l’IETF de suivre des considérations politiques avec le calendrier de travail de HTTP/2[27],[29],[30]. 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[31].
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. Il[Qui ?] a été reproché à HTTP/2 de violer des recommandations de l’IETF Pervasive Monitoring Is an Attack qui a pourtant le statut de bonne pratique 188[32]. 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[33],[34],[35], parmi lesquelles le draft-ietf-httpbis-http2-encryption-01 est un élément de travail officiel du groupe.
Étapes du développement de HTTP/2
Statut | Date | Étape[4] |
---|---|---|
Validé | [36],[37] | Première proposition de révision de HTTP 1.1 |
Validé | [38] | Première proposition de propriétés de sécurité pour HTTP |
Validé | Début 2012[39] | Appel à propositions pour HTTP/2 |
Validé | – [40],[41] | Dernier appel pour une révision de HTTP 1.1 |
Validé | [42],[43] | Première ébauche de HTTP/2 par le groupe de travail, basé sur draft-mbelshe-httpbis-spdy-00 |
Stoppé/arrêté | Dernier appel pour les propriétés de sécurité pour HTTP | |
Validé | [44],[45] | Proposition de la révision HTTP 1.1 à l’IESG pour publication comme standard |
Validé | [46] | IESG approuve la révision de HTTP 1.1 et la publie comme standard |
Validé | [36],[47] | Soumission de la révision de HTTP 1.1 comme RFC 7230, 7231, 7232, 7233, 7234, 7235 |
Validé | – [7],[48] | Dernier appel du groupe de travail pour HTTP/2 |
Validé | [6] | Soumission de HTTP/2 à l’IESG pour publication comme standard |
Validé | – [49] | Dernier appel de l’IETF pour HTTP/2 |
Validé | [50] | Téléconférence de l’IESG pour étudier la proposition de standard HTTP/2 |
Validé | [8] | L’IESG approuve HTTP/2 et la publie comme standard |
Validé | [51] | Publication de HTTP/2 comme RFC 7540 |
Logiciels et services avec gestion du protocole HTTP/2
- Apache 2.4.12 prend en charge HTTP/2 via le module mod_h2[52],
- Apache Tomcat prend en charge HTTP/2 avec les versions 8.5 et supérieures avec un changement à réaliser dans la configuration[53].
- Apache Traffic Server prend en charge HTTP/2[54].
- Caddy prend en charge HTTP/2[55].
- Citrix NetScaler 11.x prend en charge HTTP/2[56].
- Sucuri prend en charge HTTP/2[57].
- F5 BIG-IP Local Traffic Manager 11.6 prend en charge HTTP/2[58].
- gRPC, framework RPC open source initialement développé par Google.
- h2o a été créé pour prendre en charge HTTP/2[59].
- Jetty 9.3 prend en charge HTTP/2[60].
- 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[61].
- Microsoft IIS prend en charge HTTP/2 depuis Windows 10[62] et Windows Server 2016.
- Netty 4.1 prend en charge HTTP/2[63].
- nginx 1.9.5 prend en charge HTTP/2[64].
- node.js 5.0 prend en charge HTTP/2[65].
- OpenLiteSpeed 1.3.11 et 1.4.8 prennent en charge HTTP/2[66].
- Proxygen prend en charge HTTP/2.
- Radware Alteon NG prend en charge HTTP/2[67].
- ShimmerCat a été créé pour prendre en charge HTTP/2[68].
- 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.
- Akamai prend en charge HTTP/2[69].
- 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[70].
- AWS CloudFront prend en charge HTTP/2 [71]
- Fastly prend en charge HTTP/2[72].
- Imperva Incapsula CDN prend en charge HTTP/2[73]. 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
Voir aussi
Liens externes
- Site officiel
- RFC 7540[1] – Hypertext Transfer Protocol version 2 (HTTP/2)
- RFC 7541[74] – 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)
Références
- (en) « Hypertext Transfer Protocol Version 2 (HTTP/2) », Request for comments no 7540, .
- Bright, Peter, « HTTP/2 finished, coming to browsers within weeks », Ars Technica,
- M. (ed. ), Belshe M. and R. Peon Thomson, « Hypertext Transfer Protocol version 2 - draft-ietf-httpbis-http2-16 », sur ietf.org, HTTPbis Working Group (consulté le )
- (en) « Hypertext Transfer Protocol Bis (httpbis) - Charter », Internet Engineering Task Force,
- (en) « Hypertext Transfer Protocol -- HTTP/1.1 », Request for comments no 2068, .
- « History for draft-ietf-httpbis-http2-16 », IETF (consulté le ) : « "2014-12-16 IESG state changed to Publication Requested" »
- Raymor, Brian, « Wait for it – HTTP/2 begins Working Group Last Call! », Microsoft Open Technologies, (consulté le )
- The IESG, « Protocol Action: 'Hypertext Transfer Protocol version 2' to Proposed Standard (draft-ietf-httpbis-http2-17.txt) », (consulté le )
- Mark Nottingham, « HTTP/2 Approved », sur www.ietf.org, Internet Engineering Task Force, (consulté le )
- « Usage of HTTP/2 for websites », W3Techs,
- Ilya Grigorik, « High Performance Browser Networking »(Archive.org • Wikiwix • Archive.is • Google • Que faire ?), O'Reilly Media, Inc.
- Michael Pratt, « Apiux », sur apiux.com (consulté le )
- Dio Synodinos, « HTTP 2.0 First Draft Published », sur InfoQ.com, C4Media Inc.,
- Sebastian Anthony, « S&M vs. SPDY: Microsoft and Google battle over the future of HTTP 2.0 », ExtremeTech,
- Ilya Grigorik, « Life beyond HTTP 1.1: Google's SPDY »
- Willy Tarreau, Amos Jeffries, Adrien de Croy et Poul-Henning Kamp, « Proposal for a Network-Friendly HTTP Upgrade », Network Working Group, Internet Engineering Task Force,
- Doug Beaver, « HTTP2 Expression of Interest », W3C,
- Dio Synodinos, « HTTP/2 First Draft Published », InfoQ,
- « SPDY: An experimental protocol for a faster web », The Chromium Projects
- 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. »
- « API Deprecations and Removals in Chrome 51 » : « TL;DR: Support for HTTP/2 is widespread enough that SPDY/3.1 support can be dropped. »
- (en) « Supporting HTTP/2 for Google Chrome Users / NGINX », sur NGINX, (consulté le ).
- M. Belshe, R. Peon et M. Thomson, « Hypertext Transfer Protocol Version 2, Use of TLS Features » (consulté le )
- « HTTP/2 Frequently Asked Questions », IETF HTTP Working Group (consulté le )
- « Networking/http2 », MozillaWiki (consulté le )
- « mnot’s blog: HTTP/2 Implementation Status »
- Poul-Henning Kamp, « HTTP/2.0 – The IETF is Phoning It In (Bad protocol, bad politics) », ACM Queue, (consulté le )
- Ilya Grigorik, « Is TLS Fast Yet? »(Archive.org • Wikiwix • Archive.is • Google • Que faire ?) (consulté le )
- P. H. Kamp, « Http/2.0 », (DOI 10.1145/2717515), p. 40
- Poul-Henning Kamp, « Re: Last Call: <draft-ietf-httpbis-http2-16.txt> (Hypertext Transfer Protocol version 2) to Proposed Standard », (consulté le )
- Eliot Lear, « Mandatory encryption *is* theater », (consulté le )
- Constantine A. Murenin, « Re: Last Call: <draft-ietf-httpbis-http2-16.txt> (Hypertext Transfer Protocol version 2) to Proposed Standard », (consulté le )
- Paul Hoffman, « draft-hoffman-httpbis-minimal-unauth-enc-01 - Minimal Unauthenticated Encryption (MUE) for HTTP-2 », Internet Engineering Task Force
- Mark Nottingham et Martin Thomson, « draft-nottingham-http2-encryption-03 - Opportunistic Encryption for HTTP URIs », Internet Engineering Task Force
- Mark Nottingham et Martin Thomson, « draft-ietf-httpbis-http2-encryption-01 - Opportunistic Security for HTTP », Internet Engineering Task Force
- Nottingham, Mark, « RFC2616 is Dead », (consulté le )
- (en) « HTTP/1.1, part 1: URIs, Connections, and Message Parsing - draft-ietf-httpbis-p1-messaging-00 », (consulté le )
- « Security Requirements for HTTP - draft-ietf-httpbis-security-properties-00.txt », (consulté le )
- Nottingham, Mark, « Rechartering HTTPbis », (consulté le )
- Nottingham, Mark, « Working Group Last Call for HTTP/1.1 p1 and p2 », (consulté le )
- Nottingham, Mark, « Second Working Group Last Call for HTTP/1.1 p4 to p7 », (consulté le )
- « SPDY Protocol - draft-ietf-httpbis-http2-00 », HTTPbis Working Group, (consulté le )
- Nottingham, Mark, « First draft of HTTP/2 », (consulté le )
- « Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing » [archive du ] (consulté le )
- « Last Call: <draft-ietf-httpbis-p1-messaging-24.txt> (Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing) to Proposed Standard », The IESG, (consulté le )
- The IESG, « Protocol Action: 'Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing' to Proposed Standard (draft-ietf-httpbis-p1-messaging-26.txt) », (consulté le )
- The RFC Editor Team, « RFC 7230 on Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing », (consulté le )
- Nottingham, Mark, « Working Group Last Call: draft-ietf-httpbis-http2-14 and draft-ietf-httpbis-header-compression-09 », HTTP Working Group, (consulté le )
- « Last Call: <draft-ietf-httpbis-http2-16.txt> (Hypertext Transfer Protocol version 2) to Proposed Standard from The IESG on 2014-12-31 », Internet Engineering Task Force, (consulté le )
- « IESG Agenda: 2015-01-22 » [archive du ], IETF (consulté le )
- The RFC Editor Team, « RFC7540 on Hypertext Transfer Protocol Version 2 (HTTP/2) »,
- (en) « http/2 module for apache httpd » (consulté le )
- (en) « Apache Tomcat Migration » (consulté le )
- (en) « Apache Traffic Server Downloads », sur trafficserver.apache.org,
- (en) « caddyserver.com »,
- (en) « 3 Simple Steps to Bring HTTP/2 Performance to Legacy Web Applications »,
- (en) « Sucuri += HTTP/2 — Announcing HTTP/2 Support », sur Sucuri (consulté le )
- (en) Robert Haynes, « Goodbye SPDY, Hello HTTP/2 », F5 Networks (consulté le )
- (en) « H2O »
- (en) « Jetty change log »(Archive.org • Wikiwix • Archive.is • Google • Que faire ?), Eclipse Foundation., (consulté le )
- (en) « LSWS 5.0 Is Out – Support for HTTP/2, ESI, LiteMage Cache »,
- (en) Rob Trace et David Walp, « HTTP/2: The Long-Awaited Sequel », MSDN IEBlog, Microsoft Corporation,
- (en) « Netty.news: Netty 4.1.0.Final released », sur netty.io (consulté le )
- (en) « nginx changelog », sur www.nginx.com,
- (en) « Node http2 », sur www.github.com,
- (en) « OpenLiteSpeed 1.4.5 change log », LiteSpeed Technologies, Inc., (consulté le )
- (en) « Radware Combines an Integrated HTTP/2 Gateway with its Leading Fastview Technology to Provide Web Server Platforms Increased Acceleration »,
- (en) « www.shimmercat.com »,
- http2.akamai.com
- (en) « HTTP/2 is here! Goodbye SPDY? Not quite yet », sur CloudFlare (consulté le )
- (en) « Amazon CloudFront now supports HTTP/2 », sur Amazon Web Services, Inc. (consulté le )
- (en) « Announcing Limited Availability for HTTP/2 »
- (en) « HTTP/2 is here: What You Need to Know » (consulté le )
- (en) « HPACK: Header Compression for HTTP/2 », Request for comments no 7541, .
- Portail des réseaux informatiques
- Portail de l’informatique
- Portail des télécommunications
- Portail d’Internet