De quoi sera fait le futur de HTTP

Naviguer sur des sites Internet … mais plus seulement :

Il y a 22 ans de cela naissait le protocole HTTP.

Ce protocole offrait la possibilité d’afficher du contenu textuel (au format HTML) depuis un serveur (Apache, IIS, …) vers un client (navigateur).

Souvenez-vous, en 1996 : Vous alliez peut-être sur Yahoo! (gardé en mémoire par les archives Web des états-unis) avec Netscape. Et pour consulter les pages jaunes, vous utilisiez le minitel.

Au fil des années, les HTTP est devenu un protocole fourre-tout. On n’y transmet plus seulement du texte, mais aussi des images (des Gif animés !!!), puis des vidéos (Youtube, …), et finalement, le client se retrouve avec un seul logiciel qui sait tout faire : Son navigateur lui permet de chatter, faire ses courses, regarder la télé, téléphoner, jouer, lire ses mails, raconter sa vie sur les réseaux asociaux, …

Un navigateur fourre tout utilisant un protocole qui date de 1999 pour sa dernière révision.

 

Le HTTP de mme Michu, celui de Google et celui de Microsoft :

Aujourd’hui un groupe de travail de l’IETF est chargé de l’avenir de HTTP, il s’appelle HTTPBis. Pendant ce temps nous utilisons tous notre bon vieux HTTP 1.1

Tous ? Non ! Une tribu d’irreductibles a pris de l’avance.

En 2009, Google a implémenté le protocole SPDY dans son navigateur Chrome côté client et sur ses serveurs. Aujourd’hui, Apache (avec le module SPDY) et Firefox sont capables d’utiliser SPDY.

Les principes sont les suivants :

  • Multiplexage des requêtes / réponses
  • Priorité des requêtes
  • Compression des en-têtes

Résultat : Un gain de temps très important dans les requêtes / réponses Web mais une infrastructure plus lourde et plus vulnérable aux attaques DoS.

Microsoft travaille de son côté (pour changer) et propose un protocole aux mêmes principes que SPDY : Speed+mobility.

Ce protocole reprend les propriétés de SPDY en y ajoutant une optimisation des requêtes et des consommations de batteries pour les équipements mobiles.

 

Le groupe IETF httpbis devrait prendre en compte ces suggestions d’améliorations dans sa future version de HTTP.

 

Sur le même sujet :