Comme nous sommes toujours \u00e0 la pointe des nouvelles technologies, nous nous sommes assur\u00e9s que l’ensemble du site et de l’administration de Kinsta fonctionne sur HTTP\/2 et que notre nouvelle infrastructure Google Cloud supporte<\/a> HTTP\/2 pour tous nos clients. Cette vaste source d’information explique HTTP\/2 aux utilisateurs finaux, aux d\u00e9veloppeurs et aux entreprises en qu\u00eate d’innovation. Des informations de base aux sujets plus avanc\u00e9s, vous apprendrez tout ce que vous devez savoir sur HTTP\/2.<\/p>\n HTTP<\/a> a \u00e9t\u00e9 propos\u00e9 \u00e0 l’origine par Tim Berners-Lee<\/a>, le pionnier du World Wide Web qui a con\u00e7u le protocole d’application avec la simplicit\u00e9 \u00e0 l’esprit pour ex\u00e9cuter des fonctions de communication de donn\u00e9es de haut niveau entre serveurs Web et clients.<\/p>\n La premi\u00e8re version document\u00e9e de HTTP a \u00e9t\u00e9 publi\u00e9e en 1991 en tant que HTTP0.9, ce qui a conduit plus tard \u00e0 l’introduction officielle et \u00e0 la reconnaissance de HTTP1.0 en 1996. HTTP1.1 a suivi en 1997 et a depuis re\u00e7u peu d’am\u00e9liorations it\u00e9ratives.<\/p>\n En f\u00e9vrier 2015, le groupe de travail HTTP de l’Internet Engineering Task Force (IETF<\/a>) a r\u00e9vis\u00e9 HTTP et d\u00e9velopp\u00e9 la deuxi\u00e8me version majeure du protocole d’application sous la forme du HTTP\/2. En mai 2015, la sp\u00e9cification d’impl\u00e9mentation HTTP\/2 a \u00e9t\u00e9 officiellement normalis\u00e9e en r\u00e9ponse au protocole SPDY<\/a> compatible HTTP de Google. L’argument HTTP\/2 vs SPDY se poursuit tout au long du guide.<\/p>\n Le d\u00e9bat HTTP\/2 vs HTTP1 doit \u00eatre pr\u00e9c\u00e9d\u00e9 d’une br\u00e8ve introduction au terme Protocole fr\u00e9quemment utilis\u00e9 dans cette ressource. Un protocole est un ensemble de r\u00e8gles qui r\u00e9gissent les m\u00e9canismes de communication de donn\u00e9es entre les clients (par exemple les navigateurs Web utilis\u00e9s par les internautes pour demander des informations) et les serveurs (les machines contenant les informations demand\u00e9es).<\/p>\n Les protocoles se composent g\u00e9n\u00e9ralement de trois parties principales : l’en-t\u00eate, la charge utile et le pied de page. L’en-t\u00eate plac\u00e9 avant la charge utile contient des informations telles que les adresses source et destination ainsi que d’autres d\u00e9tails (tels que la taille et le type) concernant la charge utile. La charge utile est l’information r\u00e9elle transmise \u00e0 l’aide du protocole. Le pied de page suit la charge utile et sert de champ de contr\u00f4le pour acheminer les demandes client-serveur aux destinataires pr\u00e9vus avec l’en-t\u00eate afin de s’assurer que les donn\u00e9es utiles sont transmises sans erreur.<\/p>\n Le syst\u00e8me est similaire \u00e0 celui du service postal. La lettre (charge utile) est ins\u00e9r\u00e9e dans une enveloppe (en-t\u00eate) portant l’adresse de destination et scell\u00e9e avec de la colle et un timbre-poste (pied de page) avant son exp\u00e9dition. Sauf que la transmission de l’information num\u00e9rique sous forme de 0 et de 1 n’est pas aussi simple et n\u00e9cessite une innovation de nouvelle dimension en r\u00e9ponse aux progr\u00e8s technologiques de plus en plus importants qui \u00e9mergent avec la croissance explosive de l’utilisation d’Internet.<\/p>\n Le protocole HTTP compos\u00e9 \u00e0 l’origine de commandes de base : GET, pour r\u00e9cup\u00e9rer les informations du serveur et POST, pour fournir les informations demand\u00e9es au client. Cet ensemble simple et apparemment ennuyeux de quelques commandes pour obtenir des donn\u00e9es GET et POST une r\u00e9ponse a essentiellement form\u00e9 la base pour construire d’autres protocoles r\u00e9seau \u00e9galement. Le protocole est une nouvelle \u00e9tape dans l’am\u00e9lioration de l’exp\u00e9rience et de l’efficacit\u00e9 des utilisateurs d’Internet, ce qui n\u00e9cessite l’impl\u00e9mentation de HTTP\/2 pour am\u00e9liorer la pr\u00e9sence en ligne.<\/p>\n Depuis sa cr\u00e9ation au d\u00e9but des ann\u00e9es 1990, HTTP n’a connu que quelques r\u00e9visions majeures. La version la plus r\u00e9cente, HTTP1.1, a servi le cybermonde pendant plus de 15 ans. \u00c0 l’\u00e8re actuelle de la mise \u00e0 jour dynamique de l’information, des formats de contenu multim\u00e9dia gourmands en ressources et de la tendance excessive \u00e0 la performance sur le Web, les anciennes technologies de protocole font maintenant partie de l’histoire ancienne. Ces tendances n\u00e9cessitent d’importants changements HTTP\/2 pour am\u00e9liorer l’exp\u00e9rience Internet.<\/p>\n L’objectif principal de la recherche et du d\u00e9veloppement d’une nouvelle version de HTTP s’articule autour de trois qualit\u00e9s rarement associ\u00e9es \u00e0 un seul protocole r\u00e9seau sans n\u00e9cessiter de technologies r\u00e9seau suppl\u00e9mentaires – simplicit\u00e9, haute performance et robustesse. Ces objectifs sont atteints gr\u00e2ce \u00e0 l’introduction de capacit\u00e9s qui r\u00e9duisent la latence dans le traitement des requ\u00eates du navigateur gr\u00e2ce \u00e0 des techniques telles que le multiplexage, la compression, la hi\u00e9rarchisation des requ\u00eates et la pouss\u00e9e du serveur.<\/p>\n Des m\u00e9canismes tels que le contr\u00f4le du flux, la mise \u00e0 niveau et le traitement des erreurs fonctionnent en tant qu’am\u00e9liorations du protocole HTTP pour les d\u00e9veloppeurs afin d’assurer la haute performance et la r\u00e9silience des applications Web.<\/p>\n Le syst\u00e8me collectif permet aux serveurs de r\u00e9pondre efficacement avec plus de contenu qu’initialement demand\u00e9 par les clients, \u00e9liminant l’intervention de l’utilisateur pour demander continuellement des informations jusqu’\u00e0 ce que le site soit enti\u00e8rement charg\u00e9 sur le navigateur. Par exemple, la fonction Server Push avec HTTP\/2 permet aux serveurs de r\u00e9pondre avec le contenu complet d’une page autre que les informations d\u00e9j\u00e0 disponibles dans le cache du navigateur. La compression efficace des fichiers d’en-t\u00eate HTTP minimise le protocole pour am\u00e9liorer les performances \u00e0 chaque requ\u00eate de navigateur et r\u00e9ponse du serveur.<\/p>\n Les modifications HTTP\/2 sont con\u00e7ues pour maintenir l’interop\u00e9rabilit\u00e9 et la compatibilit\u00e9 avec HTTP1.1. On s’attend \u00e0 ce que les avantages de HTTP\/2 augmentent avec le temps gr\u00e2ce \u00e0 des exp\u00e9riences en situation r\u00e9elle, et sa capacit\u00e9 \u00e0 r\u00e9soudre les probl\u00e8mes de performance en comparaison avec HTTP1.1 dans le monde r\u00e9el aura un impact consid\u00e9rable sur son \u00e9volution sur le long terme.<\/p>\n \u00ab\u00a0…nous ne rempla\u00e7ons pas tout HTTP – les m\u00e9thodes, les codes d’\u00e9tat et la plupart des en-t\u00eates que vous utilisez aujourd’hui seront les m\u00eames. Au lieu de cela, nous red\u00e9finissons la fa\u00e7on dont il est utilis\u00e9 \u00ab\u00a0sur le fil\u00a0\u00bb pour qu’il soit plus efficace, et pour qu’il soit plus doux pour l’Internet lui-m\u00eame….\u00a0\u00bb Mark Nottingham<\/a>, pr\u00e9sident du groupe de travail HTTP de l’IETF et membre du TAG du W3C. Source<\/a><\/p><\/blockquote>\n Il est important de noter que la nouvelle version de HTTP est une extension de son pr\u00e9d\u00e9cesseur et ne devrait pas remplacer HTTP1.1 de sit\u00f4t. L’impl\u00e9mentation de HTTP\/2 n’activera pas la prise en charge automatique de tous les types de cryptage disponibles avec HTTP1.1, mais ouvrira certainement la porte \u00e0 de meilleures alternatives ou \u00e0 des mises \u00e0 jour suppl\u00e9mentaires de compatibilit\u00e9 de cryptage dans un avenir proche. Cependant, les comparaisons de fonctionnalit\u00e9s telles que HTTP\/2 vs HTTP1 et SPDY vs HTTP\/2 pr\u00e9sentent le dernier protocole d’application comme gagnant en termes de performances, de s\u00e9curit\u00e9 et de fiabilit\u00e9.<\/p>\n HTTP1.1 se limitait au traitement d’une seule requ\u00eate en suspens par connexion TCP, for\u00e7ant les navigateurs \u00e0 utiliser plusieurs connexions TCP pour traiter plusieurs requ\u00eates simultan\u00e9ment.<\/p>\n Cependant, l’utilisation d’un trop grand nombre de connexions TCP en parall\u00e8le entra\u00eene une congestion TCP qui entra\u00eene une monopolisation injuste des ressources r\u00e9seau. Les navigateurs Web qui utilisent plusieurs connexions pour traiter des requ\u00eates suppl\u00e9mentaires occupent une plus grande part des ressources r\u00e9seau disponibles, ce qui r\u00e9duit les performances du r\u00e9seau pour les autres utilisateurs.<\/p>\n L’\u00e9mission de demandes multiples \u00e0 partir du navigateur entra\u00eene \u00e9galement la duplication des donn\u00e9es sur les fils de transmission de donn\u00e9es, ce qui n\u00e9cessite \u00e0 son tour des protocoles suppl\u00e9mentaires pour extraire les informations souhait\u00e9es sans erreurs au niveau des n\u0153uds finaux.<\/p>\n L’industrie de l’Internet a naturellement \u00e9t\u00e9 forc\u00e9e de hacker ces contraintes avec des pratiques telles que le domain sharding, la concat\u00e9nation, l’encha\u00eenement de donn\u00e9es et le sprinting, parmi d’autres. L’utilisation inefficace des connexions TCP sous-jacentes avec HTTP1.1 conduit \u00e9galement \u00e0 une mauvaise priorisation des ressources, entra\u00eenant une d\u00e9gradation exponentielle des performances \u00e0 mesure que la complexit\u00e9, la fonctionnalit\u00e9 et la port\u00e9e des applications Web augmentent.<\/p>\n Le Web a \u00e9volu\u00e9 bien au-del\u00e0 de la capacit\u00e9 des anciennes technologies de r\u00e9seautage HTTP. Les qualit\u00e9s fondamentales de HTTP1.1 d\u00e9velopp\u00e9es il y a plus d’une d\u00e9cennie ont ouvert la porte \u00e0 plusieurs failles embarrassantes de s\u00e9curit\u00e9 et de performance.<\/p>\n Le Cookie Hack, par exemple, permet aux cybercriminels de r\u00e9utiliser une session de travail pr\u00e9c\u00e9dente pour compromettre les mots de passe des comptes car HTTP1.1 ne permet pas d’identifier les points de terminaison de session. Tandis que les m\u00eames pr\u00e9occupations de s\u00e9curit\u00e9 continueront d\u2019obs\u00e9der HTTP\/2, le nouveau protocole d’application est con\u00e7u avec de meilleures capacit\u00e9s de s\u00e9curit\u00e9 telles que l’impl\u00e9mentation am\u00e9lior\u00e9e de nouvelles fonctionnalit\u00e9s TLS<\/a>.<\/p>\n Les s\u00e9quences bidirectionnelles de trames de format texte envoy\u00e9es via le protocole HTTP\/2 \u00e9chang\u00e9es entre le serveur et le client sont appel\u00e9es \u00ab\u00a0flux\u00a0\u00bb. Les it\u00e9rations pr\u00e9c\u00e9dentes du protocole HTTP ne permettaient de transmettre qu’un seul flux \u00e0 la fois avec un certain d\u00e9lai entre chaque transmission de flux.<\/p>\n Recevoir des tonnes de contenu multim\u00e9dia via des flux individuels envoy\u00e9s un par un est \u00e0 la fois inefficace et consommateur de ressources. Les changements HTTP\/2 ont permis d’\u00e9tablir une nouvelle couche de trames binaires pour r\u00e9pondre \u00e0 ces pr\u00e9occupations.<\/p>\n Cette couche permet au client et au serveur de d\u00e9sagr\u00e9ger la charge utile HTTP en petites s\u00e9quences de trames entrelac\u00e9es ind\u00e9pendantes et g\u00e9rables. Ces informations sont ensuite rassembl\u00e9es \u00e0 l’autre extr\u00e9mit\u00e9.<\/p>\n Les formats de trames binaires permettent l’\u00e9change de plusieurs s\u00e9quences bidirectionnelles ind\u00e9pendantes, ouvertes simultan\u00e9ment, sans latence entre les flux successifs. Cette approche pr\u00e9sente une s\u00e9rie d’avantages de HTTP\/2 expliqu\u00e9s ci-dessous :<\/p>\n Avec cette capacit\u00e9, les paquets de donn\u00e9es provenant de plusieurs flux sont essentiellement m\u00e9lang\u00e9s et transmis via une seule connexion TCP. Ces paquets sont ensuite divis\u00e9s \u00e0 l’extr\u00e9mit\u00e9 r\u00e9ceptrice et pr\u00e9sent\u00e9s sous forme de flux de donn\u00e9es individuels. La transmission simultan\u00e9e de plusieurs requ\u00eates parall\u00e8les \u00e0 l’aide de la version HTTP 1.1 ou d’une version ant\u00e9rieure n\u00e9cessitait plusieurs connexions TCP, ce qui, par nature, entrave les performances globales du r\u00e9seau malgr\u00e9 la transmission de flux de donn\u00e9es plus importants \u00e0 des vitesses plus \u00e9lev\u00e9es.<\/p>\n\n Cette capacit\u00e9 permet au serveur d’envoyer au client des informations suppl\u00e9mentaires pouvant \u00eatre mises en cache qui ne sont pas demand\u00e9es mais qui sont pr\u00e9vues dans les demandes futures. Par exemple, si le client demande la ressource X et qu’il est entendu que la ressource Y est r\u00e9f\u00e9renc\u00e9e avec le fichier demand\u00e9, le serveur peut choisir de pousser Y avec X au lieu d’attendre une requ\u00eate client appropri\u00e9e.<\/p>\n Le client place la ressource Y pouss\u00e9e dans son cache pour une utilisation ult\u00e9rieure. Ce m\u00e9canisme permet d’\u00e9viter un aller-retour entre la requ\u00eate et la r\u00e9ponse et r\u00e9duit la latence du r\u00e9seau. Server Push a \u00e9t\u00e9 initialement introduit dans le protocole SPDY de Google. Les identificateurs de flux contenant des pseudo-en-t\u00eates tels que :path permettent au serveur d’initier le Push pour des informations qui doivent \u00eatre cachables. Le client doit explicitement autoriser le serveur \u00e0 mettre en cache les ressources avec HTTP\/2 ou \u00e0 terminer les flux pouss\u00e9s avec un identifiant de flux sp\u00e9cifique.<\/p>\n D’autres changements HTTP\/2 tels que Server Push mettent \u00e0 jour ou invalident de mani\u00e8re proactive le cache du client et est \u00e9galement connu comme \u00ab\u00a0Cache Push\u00a0\u00bb. Les cons\u00e9quences \u00e0 long terme sont centr\u00e9es sur la capacit\u00e9 des serveurs \u00e0 identifier les ressources que le client ne veut pas r\u00e9ellement.<\/p>\n L’impl\u00e9mentation HTTP\/2 pr\u00e9sente des performances significatives pour des ressources pouss\u00e9es, avec d’autres avantages de HTTP\/2 expliqu\u00e9s ci-dessous :<\/p>\n Des capacit\u00e9s de Push similaires sont d\u00e9j\u00e0 disponibles avec des techniques sous-optimales telles que Inlining to Push server responses, tandis que Server Push pr\u00e9sente une solution au niveau du protocole pour \u00e9viter les complexit\u00e9s avec des hacks d’optimisation secondaires aux capacit\u00e9s de base du protocole de l’application elle-m\u00eame.<\/p>\n Le HTTP\/2 multiplexe et priorise le flux de donn\u00e9es pouss\u00e9 pour assurer de meilleures performances de transmission comme c’est le cas avec d’autres flux de donn\u00e9es en r\u00e9ponse \u00e0 une requ\u00eate. En tant que m\u00e9canisme de s\u00e9curit\u00e9 int\u00e9gr\u00e9, le serveur doit \u00eatre autoris\u00e9 \u00e0 pousser les ressources au pr\u00e9alable.<\/p>\n La derni\u00e8re version HTTP a consid\u00e9rablement \u00e9volu\u00e9 en termes de capacit\u00e9s et d’attributs, comme le passage d’un protocole texte \u00e0 un protocole binaire. HTTP1.x est utilis\u00e9 pour traiter les commandes texte afin de compl\u00e9ter les cycles requ\u00eate-r\u00e9ponse. HTTP\/2 utilisera des commandes binaires (en 1s et 0s) pour ex\u00e9cuter les m\u00eames t\u00e2ches. Cet attribut facilite les complications li\u00e9es au framing et simplifie la mise en \u0153uvre des commandes qui ont \u00e9t\u00e9 m\u00e9lang\u00e9es de fa\u00e7on confuse en raison de commandes contenant du texte et des espaces facultatifs.<\/p>\n Bien qu’il faille probablement plus d’efforts pour lire les commandes binaires que les commandes texte compar\u00e9es, il est plus facile pour le r\u00e9seau de g\u00e9n\u00e9rer et d’analyser les trames disponibles en binaire. La s\u00e9mantique reste inchang\u00e9e.<\/p>\n Les navigateurs utilisant l’impl\u00e9mentation HTTP\/2 convertiront les m\u00eames commandes texte en binaire avant de les transmettre sur le r\u00e9seau. La couche de framing binaire n’est pas r\u00e9trocompatible avec les clients et serveurs HTTP1.x et constitue un facteur cl\u00e9 de performance par rapport \u00e0 SPDY et HTTP1.x. L’utilisation de commandes binaires permet aux entreprises Internet et aux entreprises en ligne de b\u00e9n\u00e9ficier d’avantages commerciaux cl\u00e9s, comme expliqu\u00e9 plus bas avec les avantages HTTP\/2 :<\/p>\n L’impl\u00e9mentation HTTP\/2 permet au client de donner la pr\u00e9f\u00e9rence \u00e0 des flux de donn\u00e9es particuliers. Bien que le serveur ne soit pas tenu de suivre ces instructions du client, le m\u00e9canisme permet au serveur d’optimiser l’allocation des ressources r\u00e9seau en fonction des besoins de l’utilisateur final.<\/p>\n La priorisation des flux fonctionne en fonction des d\u00e9pendances et du poids attribu\u00e9 \u00e0 chaque flux. Bien que tous les flux soient intrins\u00e8quement d\u00e9pendants les uns des autres, \u00e0 l’exception des flux d\u00e9pendants, on leur attribue \u00e9galement une pond\u00e9ration entre 1 et 256. Les d\u00e9tails des m\u00e9canismes de priorisation des flux font encore l’objet de d\u00e9bats.<\/p>\n Dans le monde r\u00e9el cependant, le serveur a rarement le contr\u00f4le sur les ressources telles que le CPU et les connexions de base de donn\u00e9es. La complexit\u00e9 de la mise en \u0153uvre elle-m\u00eame emp\u00eache les serveurs de r\u00e9pondre aux requ\u00eates de priorit\u00e9 de flux. La recherche et le d\u00e9veloppement dans ce domaine sont particuli\u00e8rement importants pour le succ\u00e8s \u00e0 long terme de HTTP\/2 car le protocole est capable de traiter plusieurs flux de donn\u00e9es avec une seule connexion TCP.<\/p>\n Cette capacit\u00e9 peut conduire \u00e0 l’arriv\u00e9e simultan\u00e9e de requ\u00eates serveur qui diff\u00e8rent en fait en termes de priorit\u00e9 du point de vue de l’utilisateur final. Le fait de retarder les requ\u00eates de traitement de flux de donn\u00e9es sur une base al\u00e9atoire nuit \u00e0 l’efficacit\u00e9 et \u00e0 l’exp\u00e9rience de l’utilisateur final promises par les changements HTTP\/2. En m\u00eame temps, un m\u00e9canisme intelligent et largement adopt\u00e9 de priorisation des flux pr\u00e9sente les avantages de HTTP\/2 expliqu\u00e9s comme suit :<\/p>\n Offrir une exp\u00e9rience utilisateur haut de gamme exige des sites riches en contenu et en graphismes. Le protocole d’application HTTP est sans \u00e9tat, ce qui signifie que chaque requ\u00eate client doit inclure autant d’informations dont le serveur a besoin pour effectuer l’op\u00e9ration souhait\u00e9e. Ce m\u00e9canisme fait en sorte que les flux de donn\u00e9es transportent de multiples trames r\u00e9p\u00e9titives d’information de sorte que le serveur lui-m\u00eame n’a pas \u00e0 stocker l’information provenant des demandes pr\u00e9c\u00e9dentes des clients.<\/p>\n Dans le cas de sites proposant du contenu riche en m\u00e9dias, les clients poussent de multiples en-t\u00eates d’images presque identiques, ce qui entra\u00eene une latence et une consommation inutile de ressources r\u00e9seau limit\u00e9es. Une combinaison prioris\u00e9e de flux de donn\u00e9es ne peut atteindre les normes de performance souhait\u00e9es en mati\u00e8re de parall\u00e9lisme sans optimiser ce m\u00e9canisme.<\/p>\n L’impl\u00e9mentation de HTTP\/2 r\u00e9pond \u00e0 ces pr\u00e9occupations avec la possibilit\u00e9 de compresser un grand nombre de trames d’en-t\u00eate redondantes. Il utilise la sp\u00e9cification HPACK comme une approche simple et s\u00e9curis\u00e9e de la compression d’en-t\u00eate. Le client et le serveur maintiennent une liste des en-t\u00eates utilis\u00e9s dans les requ\u00eates client-serveur pr\u00e9c\u00e9dentes.<\/p>\n HPACK compresse la valeur individuelle de chaque en-t\u00eate avant qu’elle ne soit transf\u00e9r\u00e9e au serveur, qui recherche ensuite les informations cod\u00e9es dans la liste des valeurs d’en-t\u00eate pr\u00e9c\u00e9demment transf\u00e9r\u00e9es pour reconstruire les informations compl\u00e8tes de l’en-t\u00eate. La compression d’en-t\u00eate HPACK pour l’impl\u00e9mentation HTTP\/2 pr\u00e9sente d’immenses avantages en termes de performances, y compris certains avantages de HTTP\/2 expliqu\u00e9s ci-dessous :<\/p>\n La s\u00e9mantique sous-jacente des applications HTTP, y compris les codes d’\u00e9tat HTTP, les URI, les m\u00e9thodologies et les fichiers d’en-t\u00eate restent les m\u00eames dans la derni\u00e8re it\u00e9ration du HTTP\/2. HTTP\/2 est bas\u00e9 sur SPDY, l’alternative de Google \u00e0 HTTP1.x. Les vraies diff\u00e9rences r\u00e9sident dans les m\u00e9canismes utilis\u00e9s pour traiter les requ\u00eates client-serveur. Le tableau suivant identifie quelques points communs et am\u00e9liorations entre HTTP1.x, SPDY et HTTP\/2 :<\/p>\nCe guide met l’accent sur les aspects cl\u00e9s suivants de HTTP\/2 :<\/h3>\n
\n
<\/a>Qu’est-ce que le HTTP\/2 ?<\/h2>\n
![\"Chronologie](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http-timeline.png\")
Qu’est-ce qu’un protocole ?<\/h3>\n
![\"Mail](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/mail-http2.png\")
<\/a>Objectif de la cr\u00e9ation du HTTP\/2<\/h2>\n
![\"Exp\u00e9rience](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/website-basic.png\" "\\"Internet")
![\"Chiffrement](\"https:\/\/kinsta.com\/wp-content\/themes\/kinsta\/images\/learn\/what-is-http2\/encryption.png\" "\\"HTTP\/2")
<\/a>Qu’est-ce qui n’allait pas avec HTTP1.1 ?<\/h2>\n
![\"Requ\u00eates](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http-requests.png\")
![\"HTTP\/2](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http2-domain-sharding.png\" "\\"HTTP\/2")
<\/a>Mises \u00e0 jour des fonctionnalit\u00e9s HTTP\/2<\/h2>\n
Flux multiplex\u00e9s<\/h3>\n
![\"Flux](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http2-streams.png\")
\n
Serveur Push HTTP\/2<\/h3>\n
![\"Push](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http2-push.png\")
\n
![\"HTTP\/2](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http2-authorized.png\")
Protocoles binaires<\/h3>\n
![\"Protocoles](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/binary-protocols-2.png\")
\n
Hi\u00e9rarchisation des flux<\/h3>\n
![\"Poids](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http2-weight.png\")
\n
![\"Chargement](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http2-page-load.png\")
Compression d’en-t\u00eate \u00e0 \u00e9tats<\/h3>\n
![\"Compression](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http2-hpack-compression.png\")
\n
<\/a>Similitudes avec HTTP1.x et SPDY<\/h2>\n
![\"HTTP\/2](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http2-https.png\")
![\"Chiffrement](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http2-encryption.png\")
![\"Vitesse](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/internet-speed.jpg\")
![\"Am\u00e9liorations](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http2-performance-improvements.jpg\")
![\"HTTP\/2](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http2_mobile.png\")
![\"Baisse](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/internet-price-drop.png\")
![\"Carte](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/bandwidth-map.png\")
![\"Le](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/mobile-first.png\")
![\"S\u00e9curit\u00e9](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http2-security.png\")
![\"Avantages](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http2-seo-advantages.png\")
![\"Graphique](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http2-comparison.png\")
![\"Prise](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http2-browser-support.png\")
![\"Support](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http2-nginx-apache-support.png\")
![\"Ajouter](\"https:\/\/kinsta.com\/wp-content\/uploads\/2015\/04\/add-lets-encrypt-certificate.png\" "\\"Add")