Vous êtes ici : WEBDESIGNMOTEUR » Road-blog » Ce que change le protocole serveur HTTP/2 ? Debrief & retour d’expérience

Ce que change le protocole serveur HTTP/2 ? Debrief & retour d’expérience


J’avais anticiper et commencer le chantier Build Go Team DM en aout quand j’ai vu que les serveurs HTTP/2 sont une solution pour le protocole HTTPS tout en gardant les principes de la Web Perf’. Alors, regardons sous le capot moteur du serveur HTTP2.

L’arrivée du https …devient la norme.

Mais pensons +loin que de passer au protocole https qui permet de sécuriser.

Cela signifie que tout change entre le client (navigateur web) et le serveur (site web).

Les pages web d’aujourd’hui peuvent générer plus d’une centaine de requêtes : images, feuilles de style CSS, vidéos, publicités externes, etc. Cela ralentit considérablement l’affichage de la page car le serveur d’hébergement supporte une charge importante et que le HTTP 1.1 ne peut supporter qu’une seule requête par connexion…

Le HTTP v1 est très sensible aux connexions ayant de haut temps de latence. Cela pose un problème majeur lorsqu’il s’agit de naviguer sur le web à partir d’un smartphone ou d’une tablette, même lorsque la connexion en elle-même dispose du haut débit.

Pour revenir à la base, HTTP c’est le protocole d’Internet qui permet à un serveur hébergeant un site de communiquer avec un navigateur, comme Firefox ou Chrome, pour afficher un site. C’est donc un pont de type autoroute. Mais voilà, l’autoroute que nous utilisons tous les jours est ancienne puisque le protocole actuel, HTTP/1.1, a été standardisé dans les années fin 90.

Or, ce protocole limite les échanges entre un serveur et un navigateur puisque, pour afficher une partie du site, le navigateur doit attendre que les parties précédentes soient chargées. Donc, si une ressource composant une page web est lourde, toutes les ressources qui suivent seront bloquées.

HTTPS (Hypertext Transfer Protocol Secure) est une combinaison de deux protocoles. A savoir l’utilisation de l’HTTP sur SSL ou TLS. Cela rend une communication HTTP non-sécurisée plus sûre car elle est effectuée sur une couche cryptée. TLS (Transport Layer Security ) est une versions améliorée de SSL (Secure Sockets Layer).

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 qui permet de décrire le format des données renvoyées. Ainsi, on peux dire que le résultat que mon serveur renverra sera du HTML (text/html), du Javascipt (.js), un fichier pdf (.pdf), ou encore des images (.png, ou .jpg), bref… Tous les formats de fichier qu’un navigateur peut comprendre.

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 20 images pour 20 icônes, on en fait un seul grand fichier : donc une seule requête HTTP pour 20 éléments. Il y a aussi la concaténation des feuilles de styles (CSS) et des fichiers JS. C’est à dire, on réunis chaque CSS et chaque JS …à la suite les uns des autres …dans un seul gros fichier, l’un CSS et l’autre JS).

Mais bon est-ce pas trop !?
Depuis, je suis d’avis de faire de la Responsive Web Performance.

D’autres trucs plus fun, on pense à charger des trucs quand c’est utile.

On fait de la Web Perf’ au même titre qu’ajouter un entrée d’air en admission du moteur, ou ajouter un carburateur, ou encore préparer et optimiser la cartographie moteur. Objectif faire que le site chargé, télécharge vite.

Genre – de 1 seconde, c’est top.


Web performance - page web - screen

Web performance – page web – screen


HTTP ?

L’HyperText Transfer Protocol, plus connu sous l’abréviation HTTP — littéralement « protocole de transfert hypertexte » — est un protocole de communication client-serveur développé pour le World Wide Web. HTTPS (avec S pour secured, soit « sécurisé ») est la variante du HTTP sécurisée.

HTTP/2 ?

HTTP/2 a été développé par un groupe de travail appelé httpbis issu de l’organisation ‘Internet Engineering Task Force’. 😎

HTTP/2 est la version la plus récente du protocole HTTP depuis la publication de HTTP 1.1 en 1997 … oO

La spécification HTTP/2 fut publiée en mai 2015.

Le groupe de travail httpbis a évoqué plusieurs objectifs et points d’attention :

  • Mécanisme de négociation entre le client et le serveur pour choisir quel protocole utiliser entre HTTP/1.1, HTTP/2 ou tout autre protocole autre qu’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
  • -le nouveau mécanisme de pipelining des requêtes,
  • -Résolution de problèmes propres à HTTP 1.x
  • -Multiplexage de plusieurs requêtes au travers d’une seule connexion TCP
  • -Support 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

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 sollicites, é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 webs concernés.

Les efforts pour supporter le protocole furent entrepris par les navigateurs web Chrome, Opera, Firefox, Edge, Safari. Ce faisant, la majorité des navigateurs supportaient HTTP/2 dès la fin de l’année 2015.

HTTP/2 est désormais un protocole binaire. Avant, tout était du texte.

Le problème avec ça, c’est qu’il existe pleins de manière de dire la même chose avec du texte en fonction des espaces, des accents et autres caracteres.

Le binaire est simple. Il n’existe qu’une seule manière de dire quelque chose : 0 ou 1, en nombre d’octet.

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 utiles et enfin l’image en elle même.

HTTP/2 passe de 8 connexions simultanées maximum à une seule et unique.

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, …pas cool).

HTTP/2 n’a plus besoin d’attendre que le HTML soit chargé pour commencer à charger le CSS et le JS.

Sur un serveur HTTP 1, lorsque le client reçoit la réponse HTML du serveur, ce client doit encore le parser (l’analyser et le comprendre) et après 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.

En fait, le server push ça permet surtout de te faire télécharger des ressources nécessaires au navigateur pour l’affichage d’une page avant même de savoir si l’utilisateur en as besoin. C’est le principe du ‘preftech’.

Une commande ‘prefetch’ va déclencher le pré-chargement du fichier mentionné par le lien (attribut href), afin de le placer en memoire cache.

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 changements, c’est bien celui du protocole multiplex. Ce dernier résout une problématique du web moderne pour laquelle les développeurs se prennent la tête depuis bon nombre d’années.

Enfin, cette mise à jour du protocole est rétro-compatible ! De fait, HTTP/2 emploi une des en-tête, « Upgrade » afin de bypasser HTTP1.1 en l’aiguillant vers le nouveau protocole http/2.

Welcome next-gen Web Server.


Outils et ressources :

Test du navigateur
https://http2.golang.org/

Journey to HTTP/2
http://kamranahmed.info/blog/2016/08/13/http-in-depth/

High Performance Browser Networking
https://hpbn.co/http2/

Dossier : Le protocole HTTP/2 expliqué façon easy-biscuit
http://blogdummi.fr/actualites/dossier-le-protocole-http2-explique-facon-easy-biscuit/


A la découverte du moteur du serveur web HTTP/2 #WebPerformance #SPDY #SSL #TLS #SEO



Laisser un commentaire

Votre email ne sera pas publié.

*