En ce moment, il se passe de nouvelles et grandes choses concernant les serveurs Web. Cette évolution majeur est porté par l’arrivée du protocole Internet de nouvelle génération, dénommé HTTP/2.

Imagine, le matériel qui fait tourner Internet n’a pas connu une telle avancée depuis la mise en place des serveurs de première génération. Oui ça remonte aux années 90, à la douce musique du modem 56k, avec le protocole HTTP v1. Mais le Web, lui a beaucoup beaucoup beaucoup évolué et rapidement !

Il faut rappeler qu’à l’époque Internet était complètement différent d’aujourd’hui.

Vous vous souvenez que le petit Amazon ne vendait que des livres ?

Google devait encore se faire connaitre parmi des concurrents comme AltaVista et Yahoo.

Les réseaux sociaux voire même des sites dédié vidéo tel que YouTube n’existaient encore que dans l’imagination de quelques rares pionniers.

En 10 ans on est passé de simple page basique contenant du texte et des images, à tout autre chose composé toujours de texte et d’images en quantité et en qualité. Aussi les sites permettent des interactions possibles pour l’utilisateur et entre les visiteurs.

Prenons un instant pour découvrir puis comprendre simplement ce qui se passe sous le capot moteur de ces serveurs next-gen à travers la disponibilité du nouveau protocole HTTP/2.

HTTP ?

L’existant et la problématique

Les pages web d’aujourd’hui peuvent générer facilement plus d’une centaine de requêtes avec tout un tas de fichiers utiles comme les images, des feuilles de style et des codes ‘iframe’ embarquant des vidéos via YouTube, des Tweets, des photos via Instagram, etc.

Tout cela est vraiment utile pour constituer le contenu et le protocole HTTP fait le travail.

protocole HTTP ?

HyperText Transfer Protocol, connu par l’abréviation HTTP, est un protocole de communication client-serveur développé pour le World Wide Web, fonctionnant sur Internet.

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.

HTTP, ce protocole de transfert entre client et serveur, 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 en-têtes 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 le 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.

Évolutions & problématiques du HTTP v1

La problématique du HTTP v1 est de ne supporter qu’une seule requête par connexion… Mais c’est la conception même du protocole qui a été créé à l’époque pour des pages web basiques composé uniquement de texte et d’images. Alors aujourd’hui, avec nos sites qui propose des quantité d’images en haute définition, de nombreux articles de blog ou encore permet des interactions entre internautes sur le site… ça commence à devenir compliqué…

HTTP 1.0

HTTP 1.0 ne réutilise pas la connexion TCP ouverte pour chaque demande. Le protocole v1 ré-ouvre donc une session pour chaque requête, et on le sait, cela passe par la ‘TCP Handshake’ poignée de mains. C’est la procédure d’établissement d’une communication entre deux matériels ou logiciels, ici TCP (Transmission Control Protocol) donc Server & Client.

Difficile donc d’imaginer ce genre de comportement à grande échelle sur Internet aujourd’hui ! L’attente utilisateur est donc sensiblement augmentée par l’effet de la latence et les nombreux échanges applicatifs.

HTTP 1.1

HTTP 1.1 ajoute la compression : ‘deflate’ & ‘gzip.’ Il faut se dire qu’en 1996, le modem pour la connexion Internet était la norme. Loin avant l’arrivée de l’ADSL (Asymmetric Digital Subscriber Line) popularisé après 2010.

HTTP 1.1 date …donc de 1999 est depuis le principal protocole d’échange sur internet.

Ouai toujours en 2016 si on peut dire.

Et, on l’a bien remarqué : des sites so 90′ aux sites d’aujourd’hui, bien des changements sont apparus. L’image prend de plus en plus de place, sans parler de la vidéo.

Même amélioré depuis HTTP 1.0, la latence de HTTP 1.1 est un des premiers facteurs de ralentissement de chargement de la page.

Face à cette évolution, il devient de plus en plus difficile de proposer des sites toujours plus rapides et performants, d’autant qu’HTTP 1.1 n’exploite pas forcément au mieux la connexion TCP… Mais le Web (Client) a évolué nettement plus vite que le Matériel & Logiciel (Serveur).

Selon Dareboost, entreprise proposant des outils pratiques d’audit de site web, voilà :

Ce sur-nombre de requêtes client-serveur peut ralentir considérablement l’affichage de la page, car le serveur d’hébergement supporte alors une charge importante à un instant donné… et envoie fichier par fichier au navigateur qui reçoit, puis interprète (!) ensuite affiche le contenu.

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 éléments précédents soient chargées. Donc, si une ressource composant une page web est lourde, toutes les ressources qui suivent seront dans l’attente. Et l’Utilisateur n’apprécie pas trop d’attendre des secondes à chaque clic, page après page…

Donc à moins de procéder à un optimisation des ressources et du chargement, c’est lent. Une solution est appliquer les principes de la Web Performance.

Pour remédier à ce problème lié aux nombreux chargement d’éléments web, bon nombre de solutions ont été trouvées :

sprites

L’une apprécié des graphiste est comme par exemple l’emploi des images ‘sprites’ (au lieu d’avoir 20 images pour 20 icônes, on en fait un seul grand fichier, on a donc une seule requête HTTP qui regroupe 20 éléments image.

domaine sharding

L’autre apprécié des développeur web est le domaine sharding ! On va héberger les images sur un serveur dédié à cela. Le site (l’hébergeur) quant à lui va gérer uniquement l’afflux des visiteurs, charger les script divers. Puis, le navigateur va faire le taf d’afficher le contenu texte pioché dans la base de données que le serveur lui envoie une parcelle demandé (table de donnée). Ainsi, le chargement de tout les éléments texte +script +images se fait dans la joie et très vite. Le serveur qui héberge le site est soulager des requêtes lié aux images souvent en nombre sur un blog par exemple.

Pourquoi on peut faire cela ? Par ce qu’on sait qu’à chaque chargement, le navigateur échange avec le serveur, et que les navigateurs gèrent un petit nombre (2 à 8) connexions simultanées sur un même domaine où est hébergé le site (accessible grâce à l’URL ou adresse de type http://example .com).

Host Server Web <—> Uniform Resource Locator <—> Web Browser

La solution consiste donc à multiplier les domaines afin d’avoir plusieurs de canaux de chargement. Cela outrepasse le problème de connexions simultanées limitées par requêtes client-serveur.

Attention, il faut savoir que la « résolution d’un nom de domaine » prend du temps. En résumé, c’est le mécanisme consistant à trouver l’adresse physique de la machine correspondant au nom d’un domaine enregistré. Donc trop de noms de domaine pour n fichiers, ça ne serait donc pas top.

Eh, quand on parle de ça « prend du temps », cela reste humainement non perceptible et extrêmement rapide. Mais, si ça dépasse la seconde alors ça devient rapidement gênant.

On est d’accord que cette solution d’infrastructure serveur est à mettre en place selon des besoins et situations précises. Exemple, si l’audience est telle que et si on veut alléger la charge serveur, ou si on veut avoir un serveur dédié au stockage d’image. Alors on met en place deux serveur web, l’un est le site (front server) et l’autre avec les dossiers d’images (storage server) et il y a le serveur de base de donnée (database server) qui est présent.

front server <—> storage server <—> database server

concaténation

Un truc de web designer, c’est aussi la concaténation des feuilles de styles (CSS) et des fichiers JS. C’est à dire, on réunis chaque CSS du site et chaque JS nécessaire …à la suite les uns des autres …dans un seul gros fichier respectivement, l’un CSS et l’autre JS). Au final, comme ça on peut passer par exemple de 30 requêtes composé d’éléments CSS, JS et 20 images à 2 fichiers organisés en fichier CSS, un fichier JS et un fichier images qui afficher chaque image différente au bon endroit.

Voilà techniquement en résumé, ce que l’on peut faire pour améliorer significativement le chargement d’un site web existant. La difficulté est de respecter l’ordre de chargement de chaque script et chaque feuille de style puis de chaque image à leurs emplacements.

Faire de la Web Perf’ est au même titre qu’ajouter une entrée d’air en admission du moteur automobile, ou ajouter un carburateur, ou encore préparer et optimiser la cartographie moteur. L’objectif est faire que le site appelé affiche vite le contenu demandé.

C’est un challenge pour faire de la Web Perf’ car cela nécessite une réflexion sur le meilleur moment pour charger les fichiers Javascript. Certains scripts, issus de librairie utiles tel que Jquery, ont besoin d’être appelé en début de page, or il est pourtant conseillé de charger les scripts en pied de page… après que les CSS soit chargé pour pas bloquer l’affichage de la page web par interprétation du script qu est souvent dépendant de la librairie !

D’autant qu’un autre problème s’ajoute à chaque expiration du cache, à chaque modification du fichier, le client doit récupérer la totalité du fichier.

Mais les principes traditionnels des bonnes pratiques de la Web Performance repose sur des concept qui ne sont plus trop adapté aux besoins actuels sur le Web.

Web Performance 2.0 ?

Ce que l’on fait depuis des années afin de propose des sites web qui charge vite… mais qui arrive à trouver certaine limitation… telle que le déploiement massif d’un protocole hautement plus strict. coucou HTTPS ! :p

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

nouvelle problématique du HTTPS

Le HTTPS est déjà intégré sur un certain nombre de sites internet, essentiellement les sites e-commerce et bancaires. Le HTTPS, ce n’est donc pas une nouveauté en soi. Mais la petite histoire SSL vs TLS explique de grande conséquence sur le marché des navigateurs… et des hébergeurs.

Secure Sockets Layer vs Transport Layer Security

Initialement, seul SSL composait le S de HTTPS. Mais de nos jours, on parle souvent de SSL/TLS voire de TLS tout court. TLS est simplement une évolution de SSL normalisée par l’IETF (Internet Engineering Task Force) qui élabore les standards Internet.

Transport Layer Security (TLS), et son prédécesseur Secure Sockets Layer (SSL), sont des protocoles de sécurisation des échanges sur Internet. Le protocole SSL a été développé à l’origine par Netscape (début 1990 jusqu’en 1996). L’IETF, en a poursuivi le développement en le rebaptisant Transport Layer Security (TLS). On parle parfois de SSL/TLS pour désigner indifféremment SSL ou TLS.

TLS (ou SSL) fonctionne suivant un mode client-serveur. Il permet de satisfaire aux objectifs de sécurité suivants :

-l’authentification du serveur ;
-la confidentialité des données échangées (ou session chiffrée) ;
-l’intégrité des données échangées ;
-de manière optionnelle, l’authentification du client (mais dans la réalité celle-ci est souvent assurée par le serveur).

Novembre 1996 : SSL 3.0, la dernière version de SSL, qui inspirera son successeur TLS. Ses spécifications sont rééditées en août 2008. Le protocole est banni en 2014, à la suite de la publication de la faille POODLE, ce bannissement est définitivement ratifié en juin 2015

Le protocole TLS n’est pas structurellement différent de la version 3 de SSL, mais des modifications dans l’utilisation des fonctions de hachage font que les deux protocoles ne sont pas directement interopérables.

Cependant TLS, comme SSLv3, intègre un mécanisme de compatibilité ascendante avec les versions précédentes, c’est-à-dire qu’au début de la phase de négociation, le client et le serveur négocient la « meilleure » version du protocole disponible par tous deux.

Pour des raisons de sécurité, en 2011, la compatibilité de TLS avec la version 2 de SSL est abandonnée

Ainsi, de 1996 à 2014, SSLv3 a été très largement utilisé. Le nouveau protocole TLS 1.0, lui a grandi dans l’ombre de son encombrant prédécesseur.

Le retour de l’ecommerce

En avril 2015, l’organisation PCI SSC (Payment Card Industry Security Standards Council, c’est-à-dire VISA, MasterCard et les autres réseaux de cartes bancaires) a décidé d’interdire prochainement l’usage de TLS 1.0 pour mieux protéger les informations bancaires.

Les Petits sites e-commerce externalisent en général cette partie en la confiant à un ‘Payment Solution Provider’ qui se doit d’être conforme PCI DSS.

Les Gros se font certifier directement afin de pouvoir enregistrer les infos bancaires.

Des start-up proposent des solutions innovantes afin de permettre au Petits de mettre en place une solution de ‘Payment Solution Provider’ facile à mettre en oeuvre, tant que le site est hébergé ssur du HTTPS avec TLS 1.2 (qui a abandonné la compatibilité avec SSLv2 au passage) voire TLS 1.3 (Abandon de toute compatibilité avec SSLv2 et SSLv3).

Bye bye SSL.

Les navigateurs supportant par défaut la dernière version TLS 1.1 et TLS 1.2 sont :

  • Google Chrome 50+ & Android 5+
  • Microsoft Internet Explorer 11+ & Edge
  • Apple Safari 7+ & iOS 9.0+
  • Mozilla Firefox 36+
  • Opera 17+

Hello TLS

Lorsqu’un utilisateur se connecte à un site web qui utilise TLS, les étapes suivantes ont lieu :

  1. le navigateur du client envoie au serveur une demande de mise en place de connexion sécurisée par TLS.
  2. Le serveur envoie au client son certificat : celui-ci contient sa clé publique, ses informations (nom de la société, adresse postale, pays, e-mail de contact…) ainsi qu’une signature numérique sous forme de texte chiffré.
  3. Le navigateur du client tente de déchiffrer la signature numérique du certificat du serveur en utilisant les clés publiques contenues dans les certificats des Autorités de certifications (AC) intégrés par défaut dans le navigateur.
    1. Si l’une d’entre elles fonctionne, le navigateur web en déduit le nom de l’autorité de certification qui a signé le certificat envoyé par le serveur. Il vérifie que celui-ci n’est pas expiré puis envoie une demande OCSP (Online Certificate Status Protocol) à cette autorité pour vérifier que le certificat du serveur n’a pas été révoqué.
    2. Si aucune d’entre elles ne fonctionne, le navigateur web tente de déchiffrer la signature numérique du certificat du serveur à l’aide de la clé publique contenue dans celui-ci.
      1. En cas de réussite, cela signifie que le serveur web a lui-même signé son certificat. Un message d’avertissement s’affiche alors sur le navigateur web, prévenant l’utilisateur que l’identité du serveur n’a pas été vérifiée par une autorité de certification et qu’il peut donc s’agir potentiellement d’un site frauduleux.
      2. En cas d’échec, le certificat est invalide, la connexion ne peut pas aboutir.
  4. Le navigateur du client génère une clé de chiffrement symétrique (à la différence des clés privés et publiques utilisés par les certificats qui sont asymétriques), appelée clé de session, qu’il chiffre à l’aide de la clé publique contenue dans le certificat du serveur puis transmet cette clé de session au serveur.
  5. Le serveur déchiffre la clé de session envoyée par le client grâce à sa clé privée.
  6. Le client et le serveur commencent à s’échanger des données en chiffrant celles-ci avec la clé de session qu’ils ont en commun.

    On considère à partir de ce moment que la connexion TLS est alors établie entre le client et le serveur.
  7. Une fois la connexion terminée (déconnexion volontaire de l’utilisateur ou si durée d’inactivité trop élevée), le serveur révoque la clé de session.

HTTPS 2016 trending topic

Depuis 2016, on en parle de plus en plus de HTTPS « sur les Internet ».

Pourquoi ? La raison est que Google a récemment reconnu que le HTTPS était un facteur de référencement ou de Search Engine Optimization (SEO). Google prend maintenant en compte le HTTPS dans sa manière de référencer et de favoriser les sites web.

Disons que le fait qu’un site web ait une adresse en « https » est-il un petit bonus à l’heure actuelle pour son positionnement et sa visibilité pour (le moteur de recherche) Google.

Google ne s’intéresse même pas à la validité du certificat SSL, à l’autorité de certification ou même au type de certificat mis en place (basic, wildcard, extended validation…). Le moteur de recherche ne fait que vérifier que le protocole utilisé dans les adresse URL est HTTPS.

Mais cela n’est pas un élément déclencheur pour migrer en HTTPS. Enfin surtout maintenant le problème se pose côté des navigateurs Web tel que Mozilla Firefox ou Google Chrome.

Le navigateur récent va, dans quelques mois, afficher une indication ‘Not Secure’ dans sa barre d’adresse lorsqu’on visite un site non sécurisé qui fait transiter sur le réseau des données entrées par l’utilisateur. Donc ça part d’une bonne intention de vouloir sécuriser les données entrées dans un formulaire. Mais là ça devient un élément déclencheur de migrer de HTTP à HTTPS ou de déployer un nouveau site immédiatement en HTTPS.

Sur le web, les navigateurs affichent un pictogramme cadenas à côté de l’adresse du site et affiche https://www.example .com

La récente annonce des principaux constructeur/développeur de navigateur font que le cadenas sera afficher barré sur tout site qui affiche un formulaire hébergé sur un serveur adresse http://www.example .com ! Là ça devient un élément déclencheur essentiel de migrer de HTTP à HTTPS ou de déployer un nouveau site immédiatement en HTTPS.

nouvelle problématique du HTTPS pour la Web Perf’

Le domain sharding devient useless. C’est à dire le fait d’avoir plusieurs serveurs provoque le fait que le contenu n’est plus sur un même domaine sécurisé… mais entre deux serveurs à deux adresse différentes…

Donc c’est utile pour outrepasser le nombre de connexions simultanées des navigateurs sur un même domaine. Mais ce n’est pas la bonne idée si ça prend du temps de « chiffrer-envoyer-déchiffrer » pour chaque requête serveur… et ça alourdit la charge en calcul du serveur encore pour gérer le chiffrement et déchiffrement des paquets envoyés et reçus.

Avec le protocole HTTP, on n’a pas le problématique du « chiffrer-envoyer-déchiffrer » mais avec le HTTPS ça se pose là… et le serveur doit gérer tout ça et faire son taf habituel, gérer l’afflux des visiteurs, charger les script divers et envoyer les images pour que le navigateur rassemble et affiche tout cela en place.

HTTPS permet d’encrypter la communication entre le serveur web et le navigateur de l’internaute. Mais ça signifie naturellement davantage de travail pour les serveurs de l’hébergeur.


Mais encore, le fait de « chiffrer-envoyer-déchiffrer » sur du HTTP v1 fait que ça prend encore plus de temps en HTTPS que basiquement en HTTP… Donc est-ce une bonne idée de migrer en HTTPS si les ressources serveurs ne sont pas adaptés à cette nouvelle charge de calcul supplémentaire du au HTTPS !?


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.

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

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

solution HTTP/2

En HTTP v1, les sites web (appliquant les principes de la Web Perf;) réduisent le nombre de requêtes pour afficher une page en minifiant les ressources (JavaScript, images, etc.). Maintenant, de telles pratiques ne sont plus nécessaires avec HTTP/2. 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.

solution HTTP/2 possible dès maintenant

Les efforts pour supporter le protocole furent entrepris par les moteurs des 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.

Sous le capot moteur HTTP/2

HTTP/2 protocole binaire

HTTP/2 est un protocole binaire. Avant, le protocle HTTP v1, 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 caractères.

Le binaire est simple. Il n’existe qu’une seule manière de dire quelque chose : 0 ou 1, codé en nombre d’octet (cela représente 28 nombres = 256 possibilités), qui permet de coder des valeurs alphanumériques, jusqu’à 256 caractères différents.

On gagne donc en temps de déchiffrage (non plus du texte avec ponctuation et blabla de description) mais des caractère alphanumérique… représenté par deux valeur : 0 ou 1.

Concrètement, contrairement à HTTP/1.1 qui s’appuie sur un format texte dont les champs sont de tailles variables, HTTP/2 utilise un format binaire dont les champs sont de taille fixe.

Conceptuellement, le principal intérêt est de faciliter le travail des analyseurs ‘http-parser’ et ainsi gagner en temps de traitement coté client et coté serveur, tout en limitant le risque d’erreur.

Le multiplexage des requêtes repris du protocole SPDY permet d’utiliser une seule connexion TCP entre le client et le serveur pour traiter en parallèle l’ensemble des requêtes et des réponses. En cas de perte, les trames peuvent donc être retransmises de manière indépendante sans blocage.

Le client initie plusieurs flux bi-directionnels, ayant chacun un identifiant unique et un poids pouvant influencer l’ordre de traitement des trames.

De cette manière, il est possible de récupérer le contenu important en priorité, tel que le document HTML et la feuille de style CSS, en envoyant une requête dans un flux possédant un poids élevé.

HTTP/2 protocole multiplex

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

Et ça change tout !

Le protocole HTTP est construit sur le protocole TCP (Transmission Control Protocol), 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. \o/

server push

Sur un serveur HTTP 1, lorsque le client reçoit la réponse HTML du serveur, ce client doit encore le ‘parser’ (c’est à dire 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 navigateur 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 (j’achète;) c’est grâce au Server Push.

Avec la fonctionnalité server push, un serveur peut anticiper le besoin d’un utilisateur en envoyant le contenu « pré-utile » directement dans le cache de son navigateur. C’est particulièrement cool au début de l’échange où le serveur envoie d’abord le contenu HTML puis attend que le navigateur ‘parse’ ce contenu avant de demander les autres ressources associés (Javascript, CSS, images). Pour éviter cette attente, le serveur peut envoyer en ‘push’ ces ressources directement dans le cache du navigateur sans demande explicite du client.

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 centaines d’images provenant du même serveur, leur liste d’en-têtes vont être pratiquement identiques.

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.

HTTP v2 résout la problématique du web actuel qui se posait depuis bon nombre d’années & inclus tout le mécanisme HTTPS.

Aussi, 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.


HTTP/2 IRL

Bénéficier du HTTP/2 In Real Life qu’en est-il !?

Le nouveau protocole web HTTP/2 est standardisé depuis mai 2015 et propose, avec le protocole de compression d’entête HPACK, son lot d’améliorations et d’optimisations en terme de performances et de sécurité.

Under the hood HPACK

Le groupe de travail HTTP/2 a développé un nouveau protocole pour la gestion des entêtes : HPACK. Ce dernier définit un tableau clé/valeur avec une partie statique et une partie dynamique coté client et coté serveur.

Désormais, tout se fait en binaire et comprimé, pour gagner quelques précieux octets. L’encodage peu efficace des en-têtes de HTTP v1 faisait perdre de l’espace, donc du temps, d’autant plus qu’ils sont répétés à chaque requête. Il fallait donc comprimer.

Mais un algorithme de compression général, comme le DEFLATE qu’utilisait le protocole SPDY, avait des conséquences néfastes en terme de sécurité, lorsqu’il était combiné au chiffrement. D’où l’idée d’un algorithme spécifique à HTTP et n’ayant pas ces défauts, l’actuel HPACK.

HTTP2 compresse avec HPACK. Avec SPDY/2 qui compresse le header avec gzip, une attaque ‘Compression Ratio Info-leak Made Easy’ permet d’injecter du code, notamment en Javascript, et récupérer des cookies ou des tokens d’authentification même sur du TLS. Cela a été corrigé avec SPDY/3 et HTTP2, en utilisant HPACK.

HPACK se veut être simple et inflexible.

De cette manière, seuls les nouveaux champs ou ceux nécessitant une mise à jour sont compressés avec un codage (de huffman), envoyés, et intégrés dans le tableau. Pour gagner en performances, les champs redondants ne sont pas envoyés et deviennent implicites entre les requêtes

Basé initialement sur le protocole SPDY, HTTP/2 est une amélioration majeure du protocole HTTP/1.1, mais reste entièrement compatible avec son prédécesseur : la sémantique, les codes et méthodes HTTP restent inchangés.

SPDY !??

SPDY (prononcé Speedy) est un protocole réseau — fonctionnant sur la couche application — créé pour transporter du contenu Web. SPDY est une proposition, conçue par Google, visant à augmenter les capacités du protocole HTTP sans toutefois remplacer ce dernier. L’IETF (Internet Engineering Task Force), responsable (entre autres) du développement de HTTP, l’a intégré dans HTTP/2 publié en mai 2015.


schema HTTP vs SPDY - by WEBDESIGNMOTEUR -
schema HTTP vs SPDY – by WEBDESIGNMOTEUR –

Le but premier de SPDY est de réduire la durée de téléchargement des pages Web en classant par ordre de priorité et en multiplexant le transfert de plusieurs fichiers (ceux composant une page web) de façon à ce qu’une seule connexion soit requise.

A ce qu’il paraît, en 2012, une étude indépendante (chez Akamai, American CDN & cloud services provider) montre que, dans la pratique, la durée de téléchargement d’une page au moyen du protocole SPDY est relativement égale à celle de HTTP ou de HTTPS à cause de facteurs extrinsèques. Les tests effectués côté SPDY ont contraint à l’utilisation de TLS mais SPDY ne permettant pas une utilisation simple en direct, et n’ont pas tiré parti de la réduction des nombres de sessions simultanées utilisées.

En 2012, alors que le groupe de travail httpbis s’était initialement interdit de proposer une nouvelle version d’HTTP, concentrant son activité sur la clarification des spécifications d’HTTP 1.1. Considérant l’arrivée de SPDY et son adoption rapide sur le Web, avec notamment des implémentations dans deux des principaux navigateurs Web, Google Chrome et Mozilla Firefox, mais la direction du groupe httpbis, a émis l’opinion qu’il était temps d’envisager HTTP/2 et proposé d’amender la charte d’httpbis en ce sens, initiant de fait le développement du nouveau protocole.

SPDY constituait une option naturelle pour servir de base à HTTP/2.

HTTP Speed+Mobility

Deux autres propositions concurrentes ont été ensuite transmises à l’IETF : le protocole ‘HTTP Speed+Mobility’ par Microsoft et une proposition de mise à jour d’HTTP dénommé ‘Network-Friendly HTTP Upgrade.

Grâce à HTTP Speed+Mobility, Microsoft veut aller plus loin et prendre en compte – au-delà du Web avec les navigateurs – les besoins des applications et appareils mobiles. Ce que ne ferait pas SPDY.

HTTP Speed+Mobility est en fait une combinaison de SPDY et de WebSocket.

WebSocket est une technologie, en standardisation par le W3C (World Wide Web Consortium), qui permet une communication bidirectionnelle (full-duplex) entre le Serveur (Web server) et le Client (web browser), qu’il s’agisse d’un navigateur Web ou d’une App mobile.

L’interactivité croissante des applications web, consécutive à l’amélioration des performances des navigateurs, a rapidement rendu nécessaire le développement de techniques de communications bidirectionnelles entre l’application web et les processus serveur.

Des techniques basées sur l’appel par le client de l’objet XMLHttpRequest (objet JavaScript qui a été créé par Microsoft et adopté par Mozilla) et utilisant des requêtes HTTP avec un long ‘Time to Live’ stockées par le serveur pour une réponse ultérieure au client ont permis de pallier ce manque et ont été popularisées par le succès des architectures AJAX (Asynchronous JAvascript and Xml).


En juillet 2012, httpbis a publié un appel à expression d’intérêt afin de recueillir l’avis d’acteurs du Web sur les propositions. Parmi les réponses obtenues figure celle de Facebook qui a signifié sa préférence pour SPDY. En novembre 2012, l’IETF a publié le premier draft d’HTTP/2, qui est une copie directe de SPDY.

Après plus de 2 ans de discussions, la RFC est approuvée en février 2015 par le groupe de pilotage de l’IETF, et est publiée en mai 2015.

Les requests for comments (RFC), littéralement « demande de commentaires », sont une série numérotée de documents officiels décrivant les aspects techniques d’Internet, ou de différents matériels informatiques (routeurs, serveur). Tous les documents publiés par l’IETF sont des RFC.

Apache http2 & Microsoft IIS 10

Le module ‘Apache Module mod_http2’ permettant la prise en charge du protocole HTTP/2 pour ‘Apache HTTP Server’ dans le serveur Web noyau GNU/Linux, est disponible depuis la version 2.4+ selon le document publié sur Apache.org en 2015.

Microsoft IIS 10 prend en charge HTTP/2 avec Windows 10 et avec Windows Server 2016.

HTTP/2 peut fonctionner en mode plain text ou avec TLS, mais il est important de souligner que les navigateurs Chrome, Firefox, Edge gère uniquement HTTP/2 over TLS.

Pour la partie HTTP/2 plain text, le client propose un upgrade vers HTTP/2 en spécifiant certains paramètres comme le nombre maximum de flux concurrents supportés ou la taille maximum des trames.

Si le serveur ne supporte pas HTTP/2, il répond au client avec du HTTP/1.1, sinon il bascule en HTTP/2 en notifiant le client avec un code HTTP 101 Switching Protocols.

HTTP/2 over TLS nécessite une extension TLS appelé ALPN (Application Layer Protocol Negotiation) qui permet de négocier le protocole à utiliser lors des phases « client hello » et « server hello ».

ALPN ?

Application-Layer Protocol Negotiation (ALPN) est une extension du protocole Transport Layer Security (TLS) permettant la négociation du protocole de la couche applicative lors de la ‘TCP Handshake’ poignée de mains.

Cette extension est basé sur le protocole Next Protocol Negotiation (NPN) mis au point par Google dans le cadre du développement du protocole SPDY.

La standardisation de ces travaux par l’IETF a conduit au remplacement de NPN par ALPN en juillet 2014. Cette extension notamment est utilisée par l’ensemble des navigateurs web supportant le protocole HTTP/2.

La négociation est effectuée lors de la poignée de main TLS, qui s’effectue de la manière suivante:

  1. Le client envoie un paquet ‘ClientHello’ indiquant au serveur:
    1. Le support de l’extension ALPN
    2. Les protocoles supportés (http/1.1, h2 par exemple).
  2. Le serveur répond avec un paquet ‘ServerHello’ étendu, indiquant au client:
    1. Le support de l’extension ALPN
    2. Le protocole applicatif sélectionné
    3. Les autres informations nécessaires au chiffrement du canal de communication (certificat) et termine sa communication par l’envoi d’un paquet ‘ServerHelloDone’.
  3. Le client répond par l’envoi de son certificat et termine sa communication par l’envoi d’un paquet ‘Finished’.
  4. Le serveur confirme la sélection demandée par le client et termine sa communication par l’envoi d’un paquet ‘Finished’.

HTTP/2 ready

Au final, 2016 a été une année charnière de l’évolution du moteur du web : HTTP 1.1 en place depuis 1999, a un succésseur dénommé HTTP/2 et le Mobile poursuit sa montée en audience et usages dépassant l’usage Desktop.

En octobre 2016, 51,3% de la navigation sur Internet a été effectuée via un terminal mobile (smartphone ou tablette), contre 48,7% sur un ordinateur (desktop).

Web Performance 2.0 …RWP

Web Performance 2.0 …ou appelons ça de la Responsive Web Performance (RWP)

En terme de création de site, on peut stopper/ralentir les trucs sprite, inlining, et autre domain sharding ! En HTTP2 ce serait contre productif. Mais il faut veiller, à faire de la web Perf’ comme on fait du Responsive Web Design (RWD).

Le ‘loading time’ a longtemps été la valeur de référence.

Maintenant il y a deux métriques essentiel à checker :

‘Start Render’ : le moment où la page blanche affiche les premiers éléments visible de la page web)

‘Speed Index’ : le rythme auquel les éléments s’affichent.

HTTP/2 - Web Performance - Waterfall webpage- screen
HTTP/2 – Web Performance – Waterfall webpage- screen

Dès maintenant, il faut repenser l’application des principes de la Web Performance adapté au protocole HTTP 1.1 pour l’adapter aux nouveautés apporté par HTTP/2. Entre autres on peut établir cela :

concaténation 2.0

HTTP 1.1 : utiliser des techniques de concaténation des fichiers CSS & JS, afin de réduire le nombre de requêtes entre le serveur et le navigateur.

HTTP/2 : le protocole gère le multiplexing et il y a le principe de connexion unique.

domaine sharding 2.0

HTTP 1.1 : répartir des ressources tels que images sur plusieurs domaines afin de paralléliser les requêtes et outrepasser la limite du nombre de connexion simultané du navigateur web avec le serveur.

HTTP/2 : le protocole gère le multiplexing et il y a le principe de connexion unique.


Aussi, on peut appliquer les Principes de la Web Performance en s’inspirant du Responsive Web Design pour s’adapter au HTTP/2, appelons ça Responsive Web Performance.


under the hood http2


Welcome HTTP/2 the next-gen Web Server.


schema HTTP 1.1 vs HTTP/2 - by WEBDESIGNMOTEUR -
schema HTTP 1.1 vs HTTP/2 – by WEBDESIGNMOTEUR –

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/


09/03/2017