Heeeeello jeune MMI ! Aujourd’hui, je te parle de HTTP/2, la fameuse mise à jour du protocole HTTP employé depuis une quinzaine d’années maintenant. Accroche-toi bien, décollage imminent, 3.. 2..

Attends attends, c’est quoi « HTTP » ?

Raaah, faux départ !

HTTP (Hyper Text Transfer Protocol) est, comme son nom l’indique, un protocole de transfert entre client et serveur, et représente les fondements du web d’aujourd’hui (et ce depuis 1990). Depuis sa version 1.0, ce fameux protocole nous permet de décrire le contenu des messages que l’on veut faire transiter entre client et serveur via des en-têtes. Une des plus employées est celle du Content-Type (également appelé MIME type) qui permet de décrire le format des données renvoyées. Ainsi, je peux dire que le résultat que mon serveur renverra sera du HTML (text/html), du json (json), un fichier pdf (pdf), bref.. Tous les formats de fichier quoi ! Mais ce Content-Type permet d’avoir un meilleur contrôle sur le retour serveur.

Un client, ça peut être toi, et plus précisément ton navigateur (qui envoie une demande à un serveur). Un serveur peut être un site web (comme le Blog du MMI) ! Ci-dessous, un schéma qui te permettra de comprendre très simplement une transaction HTTP telle qu’on les connaît aujourd’hui.

Les requêtes HTTP, easy-biscuit !

 

Les méthodes du protocole HTTP

Si je tiens tellement à parler des méthodes associées à une requête HTTP, c’est que ces dernières ont une importance particulière aujourd’hui. Avant tout, les méthodes, ça représente le type d’action à effectuer. Le client envoie une requête au serveur, mais que veut-il ?
Petit exemple : Je veux afficher le site du Blog du MMI, je demande à recevoir une ressource. J’ajoute un article au Blog du MMI, j’envoie une ressource. Je corrige un article du Blog du MMI, j’édite une ressource. En fait, pour chaque action « classique » (ou aussi appelées des CRUD, pour « Create, Read, Update, Delete« ), il existe une méthode plus adaptée. C’est le principe des API de type REST et RESTful comme décrites par Roy Fielding, mais je garde ça pour un autre article, sinon on n’en finira jamais ! Ces dernières sont les plus courantes de nos jours, donc si tu es développeur et que tu veux chopper le bon pli dès maintenant, c’est de ce côté là qu’il faut creuser. Voici une petite liste des méthodes principales employées pour les CRUD usuels :

  • GET : Je veux recevoir une ressource !
  • POST : Je veux envoyer une ressource !
  • PUT : Je veux modifier l’intégralité des champs décrivant une ressource !
  • PATCH : Je veux modifier partiellement les champs décrivant une ressource !
  • DELETE : Je veux supprimer une ressource !

Il en existe bien d’autres, mais celles citées juste au-dessus sont essentielles ! Tu suis toujours ? Allez, on passe à la suite ! :)

 

Pourquoi la version actuelle du protocole HTTP n’est-elle plus suffisante ?

La version actuelle du protocole, HTTP 1.1, a été finalisée en 2014 par l’IETF (Internet Engineering Task Force, oui ça sonne un peu comme le SWAT de l’internet). Autant dire que c’est plutôt récent, non ?

Faux. Et c’est là que réside une des plus grandes problématiques du web d’aujourd’hui : il évolue à une vitesse phénoménale. Les modes et tendances associées au web (autant pour le design que pour le développement) sont constamment en mouvement, la preuve : on est passé du skeuomorphisme au flat design en l’espace de quelques mois. Depuis le début du web, avec ses magnifiques pages blanches à typo « Times News Roman », jusqu’à nos jours, le nombre de requêtes HTTP (un fichier = une requête, donc une image, un fichier html, css, js, n’importe quel fichier de ton site) est désormais, en moyenne, d’une centaine pour afficher UNE seule page. Cent requêtes, tu te rends compte du bordel que ça représente ? Une centaine d’aller-retours entre le client, toi, et le serveur, avant de pouvoir enfin visualiser le contenu d’un site ?

Le HTTP n’a pas été conçu pour autant de requêtes à la base. De fait, un gros problème a vu le jour : le « head-of-line blocking« . Un concept assez complexe comme ça, mais explicable avec une métaphore toute simple :

Quand tu es au supermarché et que tu vas en caisse pour payer, tu ne sais pas si le client devant toi va être ce gros lourdingue qui tchatche la caissière (ou le caissier), ou si c’est une personne qui sera rapide à finir sa transaction.

Avec HTTP c’est pareil ! La ligne de requêtes ne prend pas en compte la disparité des différentes requêtes. Ainsi, en tête de ligne, tu peux avoir un fichier super lourd à télécharger comme une image en 4K, et qui va bloquer l’intégralité des autres requêtes avant d’être terminée.

Pour remédier à ce problème lié aux performances web, bon nombre de solutions ont été trouvées, comme par exemple l’emploi des sprites (au lieu d’avoir 30 images pour 30 icônes, on en fait un seul grand fichier, donc une seule requête HTTP pour 30 éléments), ou la concaténation de ton CSS et de ton JS (mettre tous les fichiers à la suite les uns des autres dans un seul gros fichier). Pour résumer, la solution actuelle c’est de prendre un grand nombre de fichiers et de se débrouiller pour les faire rentrer dans une seule grosse boîte, afin d’avoir moins de requêtes à effectuer au final.

Ça fonctionne, certes. M’enfin c’est quand même un peu lourd de devoir inventer de telles solutions pour pallier aux problèmes du produit, c’est un peu comme si lorsque tu achètes une voiture, le concessionnaire te sors « Ah bah le moteur faudra le monter toi-même. Bon courage, bisous« .  C’est un peu brouillon, et ça porte ce sentiment de « fait à l’arrache », tu ne trouves pas ? C’est ce que notre fameuse IETF s’est dit également, et c’est pour cette raison que le projet du HTTP/2 est né.

 

HTTP/2, comment ça marche ?

Avant tout, cette fameuse mise à jour du protocole se base sur SPDY, un protocole développé par notre cher ami Google afin de corriger les problèmes cités plus haut. Cependant, le but de Google n’était pas de remplacer le protocole HTTP, mais bien de venir y greffer un composant afin de le rendre plus performant. A long terme, je ne suis pas persuadé que ça soit une solution viable : au final on risquerait de finir avec un protocole HTTP greffé de partout et qui ressemble un peu à Frankenstein. Et le résultat final serait le même : Il faudrait ré-écrire le protocole entièrement.

BREF. On arrive enfin aux changements clés et au « Pourquoi HTTP/2 est-il un protocole qui va révolutionner le web moderne ? »

  • HTTP/2 est désormais un protocole binaireAvant, 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.

On constate qu’à chaque étape, HTTP/2 fait un pas de plus vers la performance, et ce, majoritairement en faisant une analyse intelligente du contenu de chaque requête. S’il faut retenir un de ces 5 changements, c’est bien celui du protocole multiplex. Ce dernier résout une problématique du web moderne pour laquelle les développeurs se cassent la tête depuis bon nombre d’années. Ah, et j’oubliais : cette mise à jour du protocole n’aurait pas de sens si elle n’était pas rétro-compatible ! Dans un univers aussi vaste que le web, il est irréaliste de demander à des millions de sites web de changer leur manière de faire et d’espérer qu’ils s’y plient tous sans exception. De fait, HTTP/2 emploi une des en-tête, « Upgrade » afin de court-circuiter HTTP1.1 en l’aiguillant vers le nouveau protocole. Non, ça ne fait pas perdre de temps, et même si ça en faisait perdre, ça serait très peu significatif comparé aux gains de HTTP/2 !

Fiou, ça en fait des infos, pas vrai ? Une petite note cool pour la fin ? Allez !

 

Firefox 36 intègre HTTP/2 !

A peine finalisé, HTTP/2 est déjà inclus dans la toute dernière version de Firefox en date, soit Firefox 36 (release du 25 février 2015). Je te conseille d’aller y jeter un œil car le gain en vitesse est assez significatif

Pour ne pas parler que de Firefox, il faut aussi noter que la nouvelle version de Chrome intègre HTTP/2, mais uniquement sur des transactions client/serveur chiffrées, soit en TLS, à l’heure actuelle.

De plus, et je finirai là dessus, notre très cher Internet Explorer intègre HTTP/2 sur la Technical Preview de Windows 10. Comme quoi, il n’est jamais trop tard pour le progrès !
Ceci dit, à chaque fois que quelqu’un passe sous IE, un chaton meurt dans d’atroces souffrances.

Merci à toi d’avoir pris le temps de lire cet article, et j’espère que tu en sais désormais plus sur la dernière grosse nouveauté du web, si tu as des doutes ou si un point t’échappe, n’hésite pas à en parler dans les commentaires !

Pour aller plus loin, nous te recommandons cet article :

 

Arrivederci !

Conseil drague du jour : N’hésites pas à forcer et rentrer dans le lard, elle finira bien par succomber à tes qualités de boucher ! ;)

 

Le protocole HTTP/2 expliqué façon easy-biscuit
5 (100%) 9 votes

Ce qui pourrait également t'intéresser ...

Une réflexion sur “ Le protocole HTTP/2 expliqué façon easy-biscuit ”

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Je veux Contribuer

C'est parti

Je suis un Professionnel

Voyons voir