Voici le compte-rendu de la conférence "Dans la tête de Peter Lubbers" organisée par Zenika mercredi dernier.

Peter Lubbers est directeur de la formation chez Kaazing, une société spécialisée dans le streaming de données en temps réel pour le web ; leur produit phare, le WebSocket Gateway, exploite au maximum les dernières API de communication proposées par HTML5. Peter était donc l'homme de la situation pour nous donner les dernières nouvelles du front, en attendant la sortie de son livre "Pro HTML5 Programming", prévue pour avril.

La conférence s'organisait autour de 5 points : le bilan des technologies actuelles, les WebSockets, les Server-sent Events, l'objet XmlHttpRequest version 2, et le Cross-document messaging.

Le point sur les technologies actuelles

Les besoins de données en temps réel sont de plus en plus répandus : bourse en ligne, jeux multijoueurs, sites communautaires (Twitter...). Si les clients lourds sont parfaitement équipés pour ce genre de tâche, grâce à leur accès direct aux couches réseau de l'OS, il n'en va pas de même des applications web.

Le principal problème vient du fait que le protocole HTTP est à la fois half-duplex (les données ne circulent que dans un sens à la fois), stateless (il est nécessaire d'ouvrir une nouvelle connexion à chaque échange) et orienté requêtes (il faut que le client demande explicitement des données au serveur). On peut donc comparer son fonctionnement à celui d'un talkie-walkie.
Pire encore, le protocole lui-même est horriblement inefficace pour transférer des petits volumes d'information utile, à cause du nombre important d'en-têtes véhiculés par chaque trame.

Il existe actuellement 3 principales techniques pour contourner ces limitations et récupérer des données fraîches dans une application web :

• Le polling : c'est votre gamin qui vous demande toutes les 5 minutes en voiture si on est enfin arrivé à destination.
  Très simple à mettre en place, mais absolument pas efficace car il génère un grand nombre de requêtes inutiles, le serveur n'ayant pas forcément des données neuves à fournir. Il faut donc trouver un compromis acceptable entre la fraîcheur des données (déterminée par la fréquence de polling) et le nombre de requêtes/seconde sur le serveur.
• Le long-polling : ça, c'est plutôt comme la pêche - on lance une ligne, et on attend ; lorsque ça mord, on remonte, on réamorce, et on relance la ligne.
  Concrètement, le client envoie une requête au serveur, mais celui-ci ne répond que lorsqu'il a effectivement des données disponibles. Cette technique limite donc le nombre de connexions, mais nécessite de maintenir un grand nombre de sockets ouvertes.
• Le streaming : cette fois la liaison est maintenue ouverte le plus longtemps possible. C'est évidemment le plus efficace en termes de nombre de cycles requête/réponse, mais il faut garder à l'esprit que la connexion ouverte n'est qu'une connexion HTTP ; cela peut poser des problèmes au niveau des équipements réseau - par exemple, un proxy qui bufferiserait les données... De plus, on est toujours limité par le nombre de connexions simultanées ouvrables par le brower (généralement 2) ou sur le serveur.

Notez que, si la technique du polling est loin d'être optimale, elle génère un volume de requêtes prévisible. Sous forte charge, le long-polling pourrait au contraire rapidement saturer le serveur.

Pour illustrer ces techniques, Peter a montré une application typique des services de bourse en ligne : une queue JMS alimentait le serveur en valeurs d'actions, que la page web pollait toutes les secondes. L'outil Firebug permettait de constater que pour transférer quelques octets utiles (le nom de l'action et sa valeur), chaque requête générait presque 900 octets de trafic à cause des entêtes !

Il était donc grand temps de permettre aux applications web d'ouvrir de véritables connexions TCP, afin de pouvoir accéder directement aux services d'entreprise (JMS, XMPP...). C'est précisément le rôle des WebSockets.

WebSockets

Les WebSockets permettent d'établir des connexions TCP full-duplex standard directement depuis le navigateur, sans plugin additionnel. Elles pourront donc traverser les proxies et firewalls de manière transparente, et (enfin !) être établies vers des serveurs autres que le serveur d'origine de la page, à condition bien sûr qu'ils soient compatibles websocket.

La connexion est ouverte via un premier handshake avec un serveur compatible websocket ; sur accord réciproque et une fois les vérifications de sécurité effectuées, la connexion est ensuite promue en connexion TCP standard.
Les frames envoyées sur cette connexion peuvent être de type texte ou binaire, la différenciation se faisant graĉe à un unique octet d'entête. Dans ce dernier cas, la longueur du contenu (payload) est précisée en entête. Au final, l'overhead n'est que de quelques bytes par frame, à comparer avec les 900 vus précédemment.

L'API associée est très simple, avec une simple méthode send(data) pour transmettre des données, et des fonctions handler pour la gestion des événements : onOpen(event), onMessage(event), onClose(event)...

Pour le moment, côté serveur, seul Jetty implémente les websockets ; côté client, il faudra pour l'instant se contenter des nightly builds de Chromium - Webkit devrait bientôt suivre.

Server-sent events

Le système EventSource propose un mécanisme de communication comparable à JMS : les clients s'inscrivent à un bus de messages auprès du serveur, qui peut alors leur transmettre des données de manière asynchrone (broadcast). Comme pour les WebSockets, l'API est principalement constituée de fonctions callback permettant de réagir aux différents événements, comme la réception d'un nouveau message.

Pour le moment, un support partiel est disponible dans Opera 9+, et les équipes de Firefox y travaillent également. Mais selon Peter, EventSource ne fait rien que ne sauraient faire les WebSockets ; les deux API vont-elles cohabiter, ou EventSource va-t-il disparaître à moyen terme ?

XmlHttpRequest v.2

Le vénérable objet XmlHttpRequest, qui constitue la base de toute librairie Ajax, a été un peu amélioré et propose désormais de nouveaux callbacks pour estimer l'avancement des opérations asynchrones (Progress events). On devrait donc pouvoir afficher des barres de progression précises lors des opérations longues, pour une meilleure expérience utilisateur.

La seconde nouveauté est que les requêtes pourront être établies vers n'importe quel serveur. Pour des raisons de sécurité évidentes, les deux extrémités de la connexion devront préalablement signifier leur accord, par le biais d'un échange de headers via une requête de type HTTP OPTIONS.

Cette nouvelle liberté offre des perspectives alléchantes, comme l'assemblage de mashups 100% côté client par exemple.

Cross-document messaging

Encore une toute nouvelle API, mais qui cette fois s'intéresse à la communication entre les différents documents ouverts par le browser (pages ou iframes, onglets, fenêtres...). Nommée PostMsssage, elle fonctionne exactement sur le même modèle que les précédentes (whitelist, callbacks...). Par exemple, window.addEventListener(<function>) permet de déclarer la méthode chargée de réagir aux messages entrants.

La bonne nouvelle, c'est que la majorité des browsers récents l'implémente déjà (dont Firefox 3+ et Opera 9+).
Peter nous en a d'ailleurs fait la démonstration, en envoyant des messages d'une page à une iframe intégrée, puis un second message de l'iframe vers sa page mère.

Conclusion

Les API de communication HTML5 vont résolument libérer le navigateur de ses chaînes historiques, en lui permettant d'établir de véritables connexions TCP vers des serveurs externes.

C'est tout un nouvel écosystème qui s'ouvre là, et la course à l'armement s'annonce frénétique. En effet, il y a un maintenant un marché énorme pour l'implémentation en Javascript de clients pour les principaux protocoles fonctionnant au-dessus de TCP : RSS, SMTP, POP, JMS, IRC, XMPP, STOMP...

Si javascript, que l'on a cru enterré il y a quelques années, avait été ressuscité par Ajax, il va maintenant s'imposer comme un langage de tout premier ordre grâce à HTML 5. Vous pouvez dès à présent commencer à étudier la programmation par prototype, et toutes ces nouvelles API. A moins que... n'est-ce pas l'ombre de GWT 2.0 que je vois planer là ?

En tout cas, maintenant que les clients et serveurs compatibles commencent à être disponibles, attendez-vous à voir apparaître nombre d'articles et de démonstrations sur le net dans les mois qui viennent !

Les slides sont disponibles sur le blog de Zenika. Bonne lecture !

Références et lectures

Spécifications au W3C

• La spécification HTML5
• La spécification WebSockets
• La spécification EventSource

Outils

• Jetty
• Chromium

Articles

• Cross-document messaging sur Ajaxian.com