HTTP/2, l’avenir du web est déjà là !

L’IETF a approuvé le standard HTTP/2. Toutes personnes équipées d’une version à jour de Firefox ou Chrome, ou exécutant IE sur une version initiale de Windows 10, utilisent HTTP/2.


En 2012, un appel à propositions sur une nouvelle version du protocole HTTP a été lancé. L’initiative avait une importance capitale en raison de l’influence de ce dernier sur notre quotidien. À vrai dire, sans le protocole HTTP, il y a tout lieu de penser que notre vie quotidienne serait bien plus compliquée. Cet appel à propositions, annonciateur d’une ère nouvelle pour la communauté Internet, allait donc transformer et perfectionner ce précieux protocole.


Revenons sur la cause de cette transformation. En 1999, année de la publication de la spécification HTTP/1.1, les sites web se composaient de texte, de quelques images, voire d’une bannière publicitaire. Internet était simple, et les connexions rythmées par le son inimitable du modem 56k. Seize ans plus tard – une éternité à l’heure d’Internet – tout a changé, en particulier nos attentes. Si une page ne s’affiche pas instantanément, l’accès est forcément trop lent. Sans compter que le site doit être réactif, offrir un rendu irréprochable sur tous les terminaux et se démarquer par la qualité de l’expérience proposée. Tous ces critères doivent être réunis pour nous permettre de travailler via une connexion sans fil sur des smartphones et tablettes, partout dans le monde. De bien trop grandes exigences pour un protocole élaboré il y a près de vingt ans.


Les objectifs de la version HTTP/2 étaient simples : améliorer les performances du protocole HTTP à l’aune de notre usage actuel. En d’autres termes, trouver le moyen de charger des sites web encore plus rapidement.


Après trois ans de travail acharné, l’IETF a approuvé le standard HTTP/2, qui est pris en charge par les principaux navigateurs. Toutes personnes équipées d’une version à jour de Firefox ou de Chrome, ou exécutant Internet Explorer sur une version initiale de Windows 10, utilisent sans doute HTTP/2 depuis quelques mois sans le savoir.


Le protocole HTTP/2 comprend une multitude de fonctionnalités permettant de prendre en compte les habitudes d’utilisation du web. Les principales sont les suivantes : Multiplexage, Compression des en-têtes, Dépendances et priorisation, « Push serveur »

Multiplexage 

Le multiplexage, appliqué au protocole HTTP, permet de demander et de recevoir plusieurs éléments web simultanément. Il répond au problème de limitation de requêtes inhérent au protocole HTTP/1.1.


A chaque nouvelle requête, le client doit attendre que le serveur réponde à sa précédente demande, ce qui peut s’avérer fastidieux sachant qu’une page web inclut une centaine d’objets en moyenne. D’autant plus que ces requêtes peuvent être ralenties pour plusieurs raisons, et ainsi retarder encore le téléchargement de la page complète. Un navigateur HTTP/1.1 multiplie donc les connexions au serveur pour parvenir à un semblant de parallélisme mais, en raison de problèmes qui lui sont propres, est incapable de résoudre totalement ce blocage.

HTTP/2 est un protocole binaire. Concrètement, les requêtes et réponses sont fragmentées  en trames possédant des méta-informations qui identifient à quelle requête ou réponse ils sont associés. Les requêtes et réponses correspondant à plusieurs objets peuvent ainsi emprunter la même connexion sans risque de confusion, et être réceptionnées dans n’importe quel ordre, selon les disponibilités du serveur. Le traitement de la première requête, par exemple, peut prendre du temps, mais ne bloquera pas la transmission des objets suivants. Résultat : le chargement des pages et les délais sont accélérés. 


Compression des en-têtes 

Les en-têtes  – ces méta-informations que le navigateur joint à sa requête afin de mieux informer le serveur des éléments qu’il recherche et qu’il est en mesure d’accepter – ont été ajoutés à HTTP/1.1 et étaient, au départ, peu volumineux. Un navigateur se servira, par exemple, d’un en-tête pour indiquer à un serveur qu’il prend en charge la compression gzip ou une image WebP. C’est également par ce biais que sont communiqués les cookies dont la taille a tendance à se décupler, du fait d’une utilisation intensive et de plus en plus complexe. L’une des caractéristiques des en-têtes est qu’ils ne changent pas beaucoup entre les requêtes. Parce que HTTP/1 est un protocole sans état, le navigateur doit spécifier qu’il prend en charge un langage ou un format de fichier donné à chaque requête, ce qui crée de nombreux octets redondants.


HTTP/2 permet de résoudre ce problème. Au moyen de tables de correspondance et par le codage de Huffman, il peut réduire à zéro le nombre d’octets adressés dans une requête. Sur la durée d’une session web moyenne, il n’est pas rare d’atteindre des taux de compression supérieurs à 90%. Sur une page web, du côté de la réponse, l’incidence est minime mais côté requête, en revanche, les résultats sont significatifs. Pour une page n’incluant que 75 objets, par exemple, dont l’en-tête a une taille moyenne de l’ordre de 500 octets, il faudrait au navigateur pas moins de 4 « allers-retours » TCP pour adresser des requêtes à tous les objets ! En présence des mêmes paramètres, avec un taux de compression de 90 % propre à HTTP/2, le navigateur peut les adresser toutes en un seul aller-retour.

Dépendances et priorisation
Si le multiplexage et la compression des en-têtes créent une différence considérable, ils entrainent également un nouveau défi à relever. Extrêmement élaborés, les navigateurs s’accompagnent de pré-chargeurs qui sollicitent en priorité les éléments les plus importants. La feuille de style CSS, par exemple, est décisive pour déterminer la mise en page, contrairement à un logo figurant en pied de page. Si, dans le nouveau modèle, le navigateur se contente d’adresser toutes sortes de requêtes simultanément et permet au serveur de transmettre les objets le plus vite possible, la performance des pages sera, paradoxalement, réduite car, même si tout semble globalement s’accélérer, les objets importants pour le rendu de pages ne sont pas nécessairement envoyés en priorité au navigateur. Plutôt que rejeter le problème sur le navigateur, les concepteurs font en sorte de le régler au niveau du protocole. En communiquant au serveur la nature des relations entre objets, et en dressant une liste des priorités, le serveur s’assure que les données critiques sont immédiatement transmises au navigateur.

« Push serveur »

Pour remédier aux temps de latence liés aux allers-retours d’une requête/réponse HTTP, il est possible, pour le serveur, d’adresser un objet au navigateur avant d’y être invité : c’est là tout l’intérêt du « push serveur ». En apparence, l’avantage est évident : les pages sont diffusées instantanément, même dans les pires conditions. Mais, pour que cette distribution sélective des objets puisse se faire sans gaspiller la bande passante, le serveur doit pouvoir anticiper les besoins de l’utilisateur et connaître l’état du cache du navigateur. Problème délicat qui explique que les applications push font aujourd’hui défaut dans les protocoles d’accompagnement tels que SPDY. Si HTTP2 offre aujourd’hui un outil de « push serveur », certaines utilisations innovantes verront le jour dans les années qui viennent.

 

Quelles sont les conséquences pour l’utilisateur au quotidien ?

Personne ne sera contraint de changer de site web ou d’applications pour que ceux-ci continuent à fonctionner correctement. Non seulement le code applicatif et les API HTTP s’exécuteront sans interruption, mais les applications vont également vraisemblablement gagner en performances et consommer moins de ressources tant côté client que côté serveur.


À mesure que le protocole HTTP/2 s’impose, les entreprises soucieuses de bénéficier de ses performances et caractéristiques de sécurité, sont conviées à réfléchir à leur degré d’investissement en la matière afin de tirer pleinement parti de ces nouvelles capacités, à savoir :

 

  • Chiffrement – Les applications s’exécutant sur HTTP/2 sont susceptibles de gagner en performances sur des connexions sécurisées. Il s’agit d’un point important que les entreprises qui envisagent d’évoluer vers TLS doivent prendre en considération.
  • Optimisation de la couche TCP – Les applications seront conçues avec une couche TCP destinée à tenir compte du passage de connexions TCP multiples à une connexion unique plus longue, en particulier lorsqu’il s’agit d’ajuster la fenêtre d’encombrement en réponse à la perte de paquets.
  • Oubli des bonnes pratiques HTTP/1.1 – Beaucoup de bonnes pratiques associées aux applications distribuées via HTTP/1.1 (partage de domaine, spriting d’images, intégration de ressources et concaténation) sont non seulement inutiles pour les diffusions via HTTP/2, mais peuvent parfois même être pires et dégrader les performances.
  • Décider Quoi pousser et Quand – Les applications conçues pour tirer parti des nouvelles capacités de « push serveur » sur HTTP/2 doivent conjuguer performances et utilité.


Il est important de consacrer du temps et d’engager des moyens pour résoudre ces problématiques, notamment en optimisant différemment les connexions HTTP/1.1 et HTTP/2 à mesure que s’opère la transition au niveau des navigateurs et autres clients au cours des prochaines années. Après tout, c’est l’avenir du web qui est en jeu.