Bonnes Pratiques Web & Cloud

Pourquoi HTTP/2 est-il un protocole qui va révolutionner le web moderne ? »

• HTTP/2 est désormais un protocole binaire : Avant, tout était du texte, ou de l’ASCII. Le problème avec ça, c’est qu’il existe 50 façons de dire la même chose avec du texte en fonction des espaces, des accents, des trucs et des bidules. Le binaire, lui, ne se prend pas la tête puisqu’il n’existe qu’une seule manière de dire quelque chose. On gagne donc en temps de déchiffrage.
• HTTP/2 est désormais un protocole multiplex : Ce changement est crucial pour l’évolution des performances, puisqu’il permet ainsi de pallier à ce problème de « head-of-line blocking« . Au lieu d’avoir un ordre linéaire, HTTP/2 va ingénieusement former des groupes logiques appelés streams. Chaque requête se verra attribuée d’un stream, qui, lorsque l’association de tous les éléments sera faite, seront chargés de manière discontinue ! Ce qui signifie que le serveur va renvoyer les éléments dans un ordre arbitraire. Exemple, il pourra renvoyer les en-têtes d’une image très lourde, puis le contenu d’un fichier CSS, puis pleins d’autres trucs et enfin l’image en elle même. Pour résumer le concept du multiplex, on peut utiliser l’analogie de moz.com :

« Le multiplexing, c’est comme aller au magasin faire des courses avec votre compagne et faire une vérification de ce qu’il vous faut, avant le multiplex ça marchait comme ça : On a besoin de lait, allons chercher du lait. On a besoin d’oeufs, allons chercher des oeufs. Avec le multiplex : On a besoin de lait et d’oeufs ainsi que de farine et de sucre. Allons chercher tout ça. »

• HTTP/2 passe de 8 connexions simultanées maximum à une seule et unique : Je n’ai pas parlé de ce problème plus haut, mais il est tout aussi important. Le protocole HTTP est construit sur le protocole TCP, qui lui n’a jamais été fait pour permettre autant de connexions simultanées (aller chercher des images sur 50 sources en même temps, c’est pas terrible). En plus, c’est pas très sympa de piquer la bande passante des autres hébergements pour son propre site …
• HTTP/2 n’a plus besoin d’attendre que le HTML soit chargé pour commencer à charger le CSS et le JS : A l’heure actuelle, lorsque le client reçoit la réponse HTML du serveur, ce client doit encore le parser (l’analyser et le traduire) et ENSUITE seulement, quand tout le HTML est chargé, on peut commencer à charger le CSS et le JS. HTTP/2, lui, va permettre de charger le CSS et le JS dans le cache du client et de le faire ressortir une fois le HTML chargé. Mais il permet surtout de charger les 3 en même temps, et ça, c’est grâce au Server Push, et c’est énorme. En fait, le server push ça permet surtout de te faire télécharger des ressources nécessaires pour l’affichage d’une page avant même que tu saches que tu en as besoin.
• HTTP/2 pratique la compression des en-têtes : Chaque requête HTTP comporte un certain nombre d’en-têtes vitales au serveur afin de renvoyer une réponse adéquate. Si on prend l’exemple d’une dizaine d’images provenant du même serveur, leur liste d’en-têtes vont être pratiquement identiques. Et lorsque l’on trouve des redondances, il est évident qu’une compression est nécessaire. C’est pour cette raison que HTTP/2 va, toujours aussi ingénieusement, compresser ces en-têtes quasi-identiques afin d’en former un ensemble qui peut être chargé en une fois au lieu de x fois. Ce qui permet donc d’éviter les aller-retours client/serveur lorsqu’ils sont identiques.

Support for SPDY has been dropped in Edge due to Microsoft implementing support for HTTP/2, the latest version of the HTTP protocol. While other current browsers still maintain support for SPDY, Chrome will remove support in 2016, and other browsers will likely follow. At the time of writing, Edge, Firefox, Chrome and Opera support both SPDY and HTTP/2. Safari, including on iOS, will join that group later this year with the launch of Safari 9.