AI tools

Hypertext Transfer Protocol/2

version 2 du protocole HTTP De Wikipédia, l'encyclopédie libre

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].

Faits en bref Fonction, Sigle ...
Hypertext Transfer Protocol/2
Informations
Fonction Transmission d'hypertexte
Sigle HTTP/2
Date de création 2014
Port 80
RFC 2015 : RFC 7540[1]

modifier

Fermer

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].

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 8,4 % des dix 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 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.

Différences avec HTTP 1.1

Résumé
Contexte

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].

Genèse puis divergence avec SPDY

Résumé
Contexte
Article détaillé : 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],[27].

Critiques

Résumé
Contexte

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.

Étapes du développement de HTTP/2

Davantage d’informations Statut, Date ...
StatutDateÉtape[4]
Validé[37],[38]Première proposition de révision de HTTP 1.1
Validé[39]Première proposition de propriétés de sécurité pour HTTP
ValidéDébut 2012[40]Appel à propositions pour HTTP/2
Validé – [41],[42]Dernier appel pour une révision de HTTP 1.1
Validé[43],[44]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é[45],[46]Proposition de la révision HTTP 1.1 à l’IESG pour publication comme standard
Validé[47]IESG approuve la révision de HTTP 1.1 et la publie comme standard
Validé[37],[48]Soumission de la révision de HTTP 1.1 comme RFC 7230, 7231, 7232, 7233, 7234, 7235
Validé – [7],[49]Dernier appel du groupe de travail pour HTTP/2
Validé[6]Soumission de HTTP/2 à l’IESG pour publication comme standard
Validé – [50]Dernier appel de l’IETF pour HTTP/2
Validé[51]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é[52]Publication de HTTP/2 comme RFC 7540
Fermer

Logiciels et services avec gestion du protocole HTTP/2

Résumé
Contexte

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 :

Voir aussi

Liens externes

Références

Loading related searches...

Wikiwand - on

Seamless Wikipedia browsing. On steroids.