nicofrand

HTTP est mort, vive HTTP !

nicofrand -

Derrière ce titre un peu facile se cache en fait un possible futur du web, voire d'internet. En effet, HTTP date de 1990 (1997 pour la version 1.1) et est utilisé par tous, à grande ampleur. Cependant, d'autres protocoles voient le jour, promettant rapidité, nouvelles fonctionnalités, et stabilité. C'est le cas par exemple de SPDY, que je présente ici sommairement.

Tout d'abord, je dois avouer que le titre, choisi car il est quelque peu racoleur, est en réalité faux. SPDY(prononcez « SPeeDY ») est en fait plus une extension de HTTP qu'un remplaçant de ce dernier puisqu'il utilise toujours HTTP pour certaines tâches et se situe même entre HTTP et SSL au niveau des couches :

Qu'est-ce que SPDY ?

SPDY est un protocole développé par Google, basé également sur TCP pour la couche transport (ne nécessite donc pas de nouvelle infrastructure réseau) et qui ne requiert aucun changement sur les sites mais uniquement sur les clients web (navigateurs) et les applications de serveur. SPDY a pour but d'améliorer tous ces points :

  • réduire de 50% le temps de chargement d'une page (oui, rien que ça)
  • pouvoir exécuter plusieurs requêtes HTTP concurrentes sur une même session TCP. Aujourd'hui on utilise des pipelines et les navigateurs créent désormais jusqu'à 6 connexions afin de contourner ce problème, mais cela reste une solution limitée.
  • compresser les entêtes HTTP et enlever celles qui sont inutiles ou redondantes (notamment les entêtes User-Agent, Host et Accept* qui sont statiques et ne nécessitent pas d'être renvoyées à chaque requête.
  • réduire la complexité d’implémentation de HTTP en définissant des messages plus faciles à parser
  • permettre au serveur d'envoyer des données au client lorsque c'est possible, sans que le client ait besoin de le demander. Il y a pour ça de entêtes disponibles ; X-Associated-Content et X-Subresources. Le premier envoie la ressource directement tandis que le second informe le client qu'il aura probablement besoin de la ressource suivante (ex: lors du premier chargement d'un site, plusieurs ressources seront nécessaires).
  • rendre obligatoire la compression des données (exemple: la compression gzip n'est pas appliquée partout et n'est même parfois pas disponible chez certains hébergeurs)
  • permettre une priorisation des requêtes : dans le cas où certaines se retrouvent bloquées (bande passante restreinte, etc.), il peut être intéressant pour le client de donner une priorité à certaines des requêtes
  • moins de perte de paquets

En pratique, cela donne quoi ?

Google affirme, après avoir téléchargé (avec une connexion basique) 10 fois 25 sites du TOP 100 et calculé le temps moyen pour chacun avoir ressenti une accélération de entre 27 et 60% pour ce qui est du temps de chargement d'une page et sans SSL et 39 à 55% avec SSL. Pour les plus curieux, un tableau détaillé est disponible sur le livre blanc du projet.

D'autres ont essayé

En effet, d'autres protocoles existent déjà tels que :

  • SCTP[^1], un remplaçant de TCP assurant fiabilité et priorisation
  • SST[^2], un protocole similaire à TCP asurant une certaine légéreté
  • MUX and SMUX[^3], proposant aussi plusieurs flux sur une même connexion.

Cependant ces protocoles ne répondent pas à tous les besoins (priorisation, compression, plusieurs flux par connexion, etc.).

Et maintenant ?

Actuellement, le seul client gérant SPDY est une version modifiée de Chrome, disponible (il vous faudra cependant la compiler) ici : http://src.chromium.org/viewvc/chrome/trunk/src/net/spdy/. Pour tester il vous faudra installer le module mod_spdy pour Apache ou attendre que Google propose en open-source leur logiciel serveur (ce qui ne saurait tarder).

En savoir plus