HTTP/2 ~ Validation du protocole alliant performance et sécurité

C’est maintenant chose faite, l’IESG (Internet Engineering Steering Group) vient de valider les spécifications du protocole HTTP/2. L’IETF (Internet Engineering Task Force) travaillait depuis plus de 2 ans sur cette version, sensée remplacer le maintenant vieillissant HTTP/1.1 sorti en 1999. Cette version a pour principaux buts d’apporter des gains de performances significatifs et de favoriser la sécurité.

Ce que va apporter le protocole HTTP/2

  • Gains de performance, via les principales fonctionnalités annoncées : le multiplexage des requêtes, la compression des headers, et le push server.
    1. Le multiplexage des requêtes : les requêtes ne seront plus traitées une par une par le serveur, mais par lot, ce qui favorisera la parallélisation des traitements.
    2. La compression des headers : ceux ci seront donc plus léger et transiterons plus rapidement sur les réseaux.
    3. Le push server : pour une requête envoyée, plusieurs ressources pourront être transférées, évitant ainsi une requête pour chacune d’entre elle.
  • Sécurité, via le support du chiffrement TLS 1.2. Alors que celui ci ne sera finalement pas obligatoire dans cette version, la fondation Mozilla à déjà annoncé qu’ils obligeraient l’utilisation de celui ci pour utiliser le HTTP/2 dans Firefox.

Pour mieux comprendre ce qui va changer, voici un comparatif entre les deux versions pour une simple page web avec 3 fichiers css, 3 fichiers javascripts et 10 images :

  • HTTP/1.1 : le navigateur va envoyer une requête pour récupérer le contenu de la page et commencer à analyser celle ci. Dans le header, elle va trouver les 3 ressources CSS et interroger le serveur pour chacune d’entre elle, celui ci fournissant une ressource dès que la précédente sera terminée. Le navigateur continue son analyse et charge les 10 images de la même manière. En fin de page, il trouve les appels javascripts, récupère ceux ci l’un après l’autre et active les fonctions js. Chaque ressource aura donc nécessité une requête, et ne sera lancée que lorsque l’analyse de la page en arrivera au chargement de celle ci.
  • HTTP/2 : le navigateur va également envoyé une requête pour récupérer le contenu de la page, mais recevra directement les 3 ressources css en plus de celle ci. Les headers seront compressés par le serveur, donc plus léger et rapide à transférer. Il chargera ensuite la première image, et recevra les 5 images les plus importantes, qui seront donc affichées dès que l’analyseur html du navigateur arrivera à celles ci. Il arrivera ensuite à une image secondaire, et la requête pour celle ci renverra automatiquement les 5 images restantes. De la même manière les 3 fichiers javascripts seront ainsi récupérés. On réduit donc drastiquement le nombre de requêtes envoyées au serveur (4 au lieu de 11), on priorise celles ci pour optimiser le rendu de la page et le serveur, et toutes les requêtes pourront être traitées en parallèle.

Quid du SPDY de Google ?

Google avait déjà optimisé la version 1.1 du protocole dès 2009 pour embarquer la plupart de ces fonctionnalités dans son protocole SPDY. Le géant du web a annoncé quelques jours avant l’annonce officielle de l’IETF qu’il allait abandonner SPDY au profit du HTTP/2, celui restant néanmoins supporté jusqu’en 2016. L’IETF s’est d’ailleurs basé sur celui ci pour construire les spécifications du HTTP/2. Pour rappel, l’utilisation de SPDY pouvait amener jusqu’à 50% de gain de performance.

Prochaines étapes

Maintenant que cette nouvelle version a été annoncée, la publication de celle ci en tant que RFC ne devrait plus tarder. Gageons que les principaux serveurs web, tels qu’Apache, IIS ou Nginx travaillent déjà sur l’implémentation de ce nouveau protocole afin de permettre son utilisation au plus vite.

HTTP/2 ~ Performance et sécurité : détails des spécifications : Validation du protocole HTTP/2, description et exemples des fonctionnalités de performance et de sécurité incluses dans cette nouvelle version. was modified:

Articles en relation :

Leave a comment

name*

email* (not published)

website