HTTP/2 est une mise à jour du protocole HTTP qui vise à l’adapter au web moderne. En effet, ce protocole n’avait plus beaucoup bougé depuis 1999 et sa version 1.1, contrairement au web qui lui a énormément évolué. Pour répondre aux besoins d’internautes toujours plus exigeants, les pages sont de plus en plus lourdes et complexes. En 2016, une page effectuait en moyenne 100 requêtes (contre 80 en 2011) et pesait environ 2,1 Mo (800 Ko en 2011). A la base le protocole n’avait pas été conçu pour supporter des contenus aussi volumineux et complexes. Il était donc temps de faire quelque chose pour conserver des performances acceptables. Un peu plus de 2 ans après sa publication officielle, HTTP/2 tient-il vraiment ses promesses ?
HTTP/2 vs HTTP 1.1
Le principal problème de HTTP 1.1 résidait dans sa gestion des connexions et des requêtes. Une connexion = Une requête = Une ressource. On doit ouvrir une connexion à chaque nouvelle requête, et faire une nouvelle requête pour chaque ressource. Ce fonctionnement a tendance à rallonger les temps de chargement puisque chaque requête doit attendre que la requête précédente soit complétée. Pour éviter les blocages, les navigateurs ouvrent plusieurs connexions concurrentes (généralement 6). Bien que ce soit une amélioration notable, on est encore très loin des 100 requêtes moyennes de nos sites récents. De plus, il ne s’agit pas non plus d’augmenter infiniment le nombre de connexion concurrentes puisque cela pourrait provoquer de la congestion TCP et pénaliser les autres applications. Ce fonctionnement a poussé les développeurs à utiliser de nombreux contournements pour réduire au maximum le nombre de requêtes. Certes plutôt efficaces, ils allaient bien souvent à l’encontre des bonnes pratiques des langages de programmation du web. Même Google admet volontiers que c’est le prix à payer pour obtenir la note maximale sur son outil de test de performance PageSpeed. La concaténation qui consiste à regrouper toutes les ressources du même type entre elles en est un bon exemple.
HTTP/2 apporta alors son lot d’amélioration, parmi lesquelles :
- Connexion unique : Une connexion persistante est ouverte entre le client et le serveur. Le nombre de connexions TCP à établir est ainsi considérablement réduit. Nous sommes passés d’une connexion par ressource à une connexion par hôte.
- Multiplexage : Peut-être l’amélioration la plus emblématique de cette version, on peut faire plusieurs requêtes en même temps en utilisant la connexion persistante. Les réponses arrivent au fur et à mesure que le serveur traite les requêtes ce qui supprime le risque de blocage. Cette animation réalisée par Akamai est un exemple flagrant des améliorations apportées.
- Priorisation : Maintenant que les requêtes ne sont plus envoyées les unes à la suite des autres, il faut définir l’ordre dans lequel elles seront traitées. C’est précisément l’objectif de la priorisation. Les ressources peuvent désormais être accompagnées d’un poids allant de 1 à 256 qui aident le serveur à savoir ce qu’il doit traiter en premier.
- Server Push : Le server push consiste à utiliser le fait que la connexion entre le client et le serveur soit persistante pour envoyer les ressources avant même qu’elles aient été demandées. Fini le schéma classique dans lequel c’est le client qui initie l’échange et le serveur qui lui répond !
- Compression de l’en-tête : Les en-têtes HTTP 1.1 sont verbeuses, souvent redondantes d’une requête à l’autre et ne peuvent pas être compressées. Entre les cookies et les descriptions de navigateur on se retrouve parfois dans des cas où l’en-tête est plus volumineuse que le contenu en lui même ! HTTP/2 utilise HPACK pour compresser les en-têtes ce qui réduit leur taille et améliore donc les temps de chargement.
Risk vs Reward
« HTTP/2 n’est pas une sorte de poussière de fée magique pour la performance web » déclarait Mark Nottingham, l’un des auteurs de HTTP/2, lors de la publication de cette version. Aujourd’hui les faits le contredise un peu puisqu’on estime qu’une amélioration de 5 à 15% est observable sur les performances rien qu’en activant HTTP/2 ! On peut donc aller bien au delà avec une bonne configuration de vos applications et de vos serveurs. La réticence des responsables techniques peut se comprendre tant le standard HTTP 1.1 était installé depuis longtemps. Même si les gains potentiels sont réels, quels sont les risques ? Pour faire court, il n’y a absolument aucun risque à passer vos applications en HTTP/2. Tout d’abord, HTTP/2 est complètement rétrocompatible, même si vos utilisateurs n’ont pas les navigateurs adaptés ils pourront tout de même utiliser vos services. Au sujet des navigateurs justement, la majorité d’entre eux supportent HTTP/2 : environ 80% selon caniuse. C’est aussi le cas des logiciels de serveurs tel qu’Apache ou Nginx et des fournisseurs de CDN comme Akamai. Et la sécurité dans tout ça ? On entend souvent dire à tort que c’est le gros point faible de cette version du protocole. Certes officiellement HTTP/2 est activable aussi bien en mode sécurisé qu’en mode non-sécurisé, dans les faits, tous les navigateurs ont choisi de ne supporter HTTP/2 que via encryption TLS.
Quadran vous recommande donc de passer en HTTP/2 au plus vite, n’hésitez pas à nous contacter si vous souhaitez être accompagné dans cette démarche.
Sources