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 termes de performances et de sécurité.
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.
Quelles sont les nouveautés de HTTP/2 et que va-t-il changer dans nos habitudes ? Quel est l’impact sur les performances et la sécurité de nos réseaux ?
Analyse…
Une mise à jour nécessaire ?
Rappels sur HTTP/1.1
Le protocole HTTP/1.1 a initialement été prévu pour étendre les possibilités du protocole HTTP/1.0 (support proxy, connexion persistante, meilleure gestion du cache, …), tout en restant simple. Cependant, la taille et la complexité du web se sont considérablement amplifiées depuis la conception du protocole il y a plus de 15 ans.
Pour traiter des volumes de données toujours plus importants, des mécanismes permettent de dépasser la limitation d’une requête par connexion TCP, comme la réutilisation de la connexion Keepalive ou le HTTP pipelining qui permet d’envoyer plusieurs requêtes avec une seule connexion TCP. Cependant, le HTTP pipelining à une contrepartie: le head-of-line blocking qui va bloquer la transmission des paquets suivants lorsqu’un paquet est perdu et va donc fortement impacter les performances. De plus, la plupart des navigateurs actuels initient 6 connexions TCP simultanées pour gagner en efficacité, mais cela conduit à une consommation des ressources non négligeables pour le client et le serveur, mais aussi à une compétition entre les connexions pour l’allocation de la bande passante.
C’est donc en 2009 que Google propose un protocole expérimental pour corriger l’ensemble de ces problèmes : SPDY.
L’expérience SPDY
SPDY a pour but de réduire le temps de chargement des pages en intégrant le multiplexage et la priorisation des requêtes HTTP. SPDY intervient entre la couche TLS et HTTP :
L’idée est donc de gérer l’ensemble des transactions à travers une seule connexion TCP et ainsi d’éliminer le problème de head-of-line-blocking, tout en limitant la quantité d’informations échangées avec la compression d’entête.
La plupart des navigateurs implémentent déjà le protocole SPDY avec les serveurs compatibles :
Il y a donc de fortes chances que vous l’utilisiez sans vous en rendre compte en surfant sur les sites Google, Twitter ou Facebook par exemple.
En 2012, la volonté de standardiser SPDY donnera naissance au premier draft du protocole HTTP/2 qui reprend les principales idées et améliorations de SPDY.
Google annoncera plus tard l’arrêt du développement de SPDY et de son support dans Chrome à partir de 2016 pour se consacrer à l’intégration et au support de HTTP/2 qui apporte son lot d’améliorations.
HTTP/2 : Les nouveautés et leurs impacts
Chiffrement
HTTP/2 peut fonctionner en mode plain text ou avec TLS, mais il est important de souligner que les navigateurs Chrome/Firefox/Internet Explorer 11 (sous Windows 10 uniquement) traitent uniquement HTTP/2 over TLS pour le moment :
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.
D’un autre coté, 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 ».
HTTP/2 over TLS impose donc l’utilisation des dernières versions de TLS, ce qui évite les nombreux problèmes de sécurité liés à des versions plus anciennes. Enfin, la renégociation et les chiffrements faibles ont été supprimés pour garantir un certain niveau de sécurité.
Format des données
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. Le principal intérêt est de faciliter le travail des parseurs et ainsi gagner en temps de traitement coté client et coté serveur, tout en limitant le risque d’erreur.
C’est surtout cette représentation binaire qui nécessite une adaptation des outils réseaux comme Wireshark par exemple, dont seule la version développeur permet aujourd’hui de disséquer du HTTP/2.
Multiplexage et Qualité de Service
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é, comme le HTML et le CSS, en envoyant une requête dans un flux possédant un poids élevé.
Server push
Avec la fonctionnalité server push, un serveur peut anticiper le besoin d’un utilisateur en envoyant le contenu susceptible de l’intéresser directement dans le cache de son navigateur. C’est particulièrement utile 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.
HPACK
Suite à l’attaque CRIME en 2012 (voir http://en.wikipedia.org/wiki/CRIME), 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.
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 :
Conclusion
L’ensemble de ces fonctionnalités font de HTTP/2 un protocole plus fiable et plus rapide que HTTP/1.1. Le protocole sera progressivement implémenté dans tous les navigateurs et les outils réseaux.
HTTP/1.1 ne devrait toutefois pas disparaître du jour au lendemain, tant que le support HTTP/2 ne sera pas totalement opérationnel dans tous les produits (par exemple HTTP/2 reste globalement associé à TLS et les navigateurs ne l’autorisent pas encore pour les connexions non chiffrées). Il sera d’ailleurs très intéressant de voir si les navigateurs implémenteront le protocole sans chiffrement ou s’ils feront le pari de passer à l’internet « full TLS ».
Dans un prochain article nous présenterons un comparatif des performances [HTTP – HTTPS – SPDY – HTTP/2 – HTTP/2 over TLS] obtenues lors des travaux d’intégration de ces protocoles dans Vulture 3, qui fera partie des premières solutions de sécurité à proposer le support de ces nouveaux protocoles (https://www.vultureproject.org/support-de-spdy-et-http2-dans-vulture-3/).
