HTTP2

octobre 05, 2014  |   Actualités,Blog   |     |   0 commentaire

Historique

Afin de resituer un peu le contexte du HTTP, attardons nous sur les différentes versions de celui ci.

Tout d’abord, l’histoire commence en 1990 avec la version 0.9 (numérotation créée lors de l’apparition de la version 1.0). Cette version extrêmement simplifiée de HTTP permettait des échanges simples.

Le client ouvrait une connection vers le serveur, faisait une requête que le serveur lui retournait avant de fermer la connexion pour signaler que le transfert était fini.

Ce fonctionnement dura quelques années avant la publication du HTTP 1.0 en Mai 1996 avec la RFC 1945).Nokia 3310

C’est cette version qui apporta les bases des mécanismes que nous utilisons régulierement aujourd’hui tels que : Referer, User-Agent, If-Modified-Since, …

Elle ne supporte toutefois pas complétement les connexions persistantes obligeant les clients à ouvrir une session TCP par ressource à charger.

Finalement remplacée par la version 1.1 de HTTP par la RFC2616 publiée en Janvier 1997 puis modifiée en Juin 1999, c’est cette nouvelle version qui est majoritairement utilisée de nos jours. Elle apporte, entre autes, les connexions persistantes et le pipelining (possibilité d’enchainer plusieurs requêtes dans une session TCP ouverte sans attendre d’obtenir une réponse) et l’entête “Host” afin d’héberger plusieurs sites web sur le même serveur.

La RFC 2616 étant peu claire, elle a été clairifiée en 2014 par 8 documents (RFCs 7230 à 7237) qui ne modifient pas les spécification du protocole.

 

Introduction

Comme on peut le voir dans la première partie de cet article, le protocole que nous utilisons tous les jours date de 1997. C’est à dire, environ le moment ou le Nokia 3310 est apparu alors qu’environ 1% de la population française était connectée à Internet avec un accès RTC 56k pour charger des pages Web statiques et dénuée de média.

 

Page Google en 1998

Page Google en 1998 : Affichage statique

Page Google en 2014

Page Google en 2014 : Affichage dynamique avec notification

Aujourd’hui, plus de 80% de la population française accède à Internet et utilise le protocole HTTP/1.1 afin d’accèder et charger du contenu aussi divers que varié :

  • Page Web statique (recette de cuisine, article de presse, …)
  • Page Web dynamique (Réseaux sociaux, jeux flash, javascript, …)
  • Mail (Webmail)
  • Vidéo (lecture de video en HTML5 par exemple)
  • Musique (site/client de lecture audio : Spotify, Deezer, Podcast, webradios, …)

De plus, ce contenu est chargé depuis des terminaux de différents types comme des ordinateurs, tablette, smartphone, … Autant de nouveautés qui n’existait pas et n’ont donc pas été prévues dans le protocole dans sa conception.

C’est alors en 2012 (soit 15 après la création de HTTP 1.1) que les travaux ont commencé pour mettre en place une nouvelle version plus en phase avec son monde.

HTTP 2.0

Plutôt que HTTP 2.0, le groupe de travail sur le sujet a préféré nommer le remplaçant du HTTP 1.1 le HTTP bis. Celui ci devra prendre en compte qu’une partie non négligeable du trafic sur Internet est effectuée par des terminaux mobiles et que ceux-ci utilisent la plupart du temps un support réseau d’une qualité médiocre. Il devra alors limiter les effets liées aux retransmissions et de faciliter le traitement des requêtes afin de préserver les batteries.

Aujourd’hui, une requête HTTP est difficile à décoder à cause d’un nombre important d’entête non délimitées et dont le nombre n’est pas défini. Pour résoudre ce problème, la première proposition de HTTP bis est d’utiliser des entêtes binaires dont la taille est annoncée. Cette mesure facilite le travail des navigateurs tout en limitant l’impact d’un DoS grâce au préformatage imposé des requêtes (requête mal formée plus facile à détecter).

Un autre point d’évolution est le regroupement des requêtes ayant des entêtes communes.

En effet, quand nous allons visiter le site web http://www.toto.fr, il nous faut, par exemple, charger la page index.php, favicon.ico, style.css, logo.png, …

Pour chacune de ces reqêtes, en HTTP 1.1, nous envoyons les entêtes Host, Referer, User-Agent, Cookie, …

Avec HTTPbis, il sera alors possible d’établir une session HTTP avec le serveur en lui précisant une liste d’entêtes fixes. Ainsi il suffira pour chaque requête de préciser, si il y a lieu, des entêtes non communes en économisant l’envoi multiple de celle qui sont communes.

De plus, la troisième évolution du protocole permet d’envoyer les requêtes tout en recevant des réponses en parallèle afin d’optimiser la bande passante disponible. Le protocole est alors en mesure de re-séquencer les réponses suivant leur ordre d’arrivée.

Enfin, la dernière evolution est d’ordre architecturale. Celle ci a été revue en couches afin de facilité l’accès aux informations par équipements intermédiaires tels que les proxies, load balancer ou accélérateur web. Ceux ci pourront alors accéder directement à la couche HTTP qui les interesse afin de traiter les requêtes plus efficacement.

Enfin, la dernière évolution n’apporte pas à proprement parler de nouvelles fonctionnalités. En effet, le protocole a été revu en couche afin que les différents équipements intermédiaires tels que les proxies, load balancer ou accélérateur web accèdent plus facilement aux informations dont ils ont besoin (URI, Cookies, Cache, …) pour servir efficacement les clients.

Au final, la mise en place d’une connection HTTPbis donne naissance à une trame avec 5 types de messages possibles :

  1. Type Transport : Permet de définir les entêtes communes
  2. Type Common : Permet de définir les entêtes non communes
  3. Type Message : Contient une requête ou une réponse sans le corps
  4. Type Entity : Contient le corps du message
  5. Type Control  : Prévu pour les données de controle (Ping, Pause, Abort, …)

Trame HTTPbis

Comme la mise en place ne peut pas se faire du jour au lendemain, il est prévu que les navigateur compatible puisse effectuer une requête avec une entête du type  “Upgrade: HTTP 2.0”. De cette façon, si tous les équipements intermédiaires entre le client et le serveur sont compatibles, les échanges basculeront vers HTTP bis. Le cas échéant, le Header sera tout simplement ignoré.

Les concurrents

En 15 ans, HTTPbis n’est pas la seule solution qui a été envisagée. Toutefois, toutes ces solutions sont relativement marginales et peu utilisées/développées.

Parmi celle ci, nous pouvons citer :

  • SPDY : Développé par Google, est compatible avec la plupart des navigateurs du marché. Cette solution à pour contrainte de chiffrer l’integralité des échanges avec TLS, complexifiant grandement le travail des équipements intermédiaires. Quelques sites ont activé le support SPDY tels que Twitter ou Facebook
  • Speed+Mobility : Développé par Microsoft en utilisant la base de SPDY, ce protocole réduit encore les latences comparé à SPDY en utilisant la compression, le multiplexing et la priorisation.

Conclusion

Au final, le remplacement du HTTP 1.1 ne se fera pas du jour au lendemain et l’enjeu est de taille. Si les spécifications sont définies aujourd’hui, il faut toutefois imaginer, penser et designer le protocole pour tenir aussi longtemps que possible en étant évolutif. Il est tout à fait probable qu’une fois publié, le successeur du HTTP 2.0 n’arrive pas avant une autre quinzaine d’années. Il faut donc créer un protocole assez intéressant pour que nous l’adoptions de nos jours mais aussi évolutif pour qu’il soit toujours utilisable avec les flux que nous auront inventé dans 10 ans.

Bibliographie

http://fr.wikipedia.org/wiki/Internet_en_France

http://fr.wikipedia.org/wiki/SPDY

http://fr.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Versions

http://linuxfr.org/news/en-route-pour-http-2-0

https://tools.ietf.org/html/draft-tarreau-httpbis-network-friendly-00