af83

Soyez branchés avec les websockets

Le HTML5, dans sa définition large, inclut de nombreuses avancées, dont une que j'attends avec une certaine impatience : les websockets.

Que sont les websockets ?

Les websockets sont une sorte de TCP over HTTP : cela permet d'ouvrir une connexion persistante et bi-directionnelle entre un navigateur et un serveur. Le W3C a une spécification pour l'API Websockets (ça explique comment utiliser les websockets avec du javascript dans un navigateur). L'IETF s'occupe de l'autre partie, le protocole Websockets (qui décrit les échanges réseaux).

À quoi ça sert ?

Les websockets permettent de dialoguer rapidement entre un navigateur et un serveur sans avoir à ouvrir une nouvelle connexion à chaque message échangé. L'exemple typique d'utilisation est la discussion en ligne, le "chat".

Mais les websockets peuvent aussi être très utiles pour des notifications : indiquer qu'un nouveau mail vient d'arriver dans un webmail ou qu'un ticket vient d'être ouvert sur un outil de gestion de projets, afficher quasi-instantanément de nouvelles enchères sur un site d'enchères en ligne, actualiser le stock d'un produit lors d'une vente flash, etc.

En fait, dès que l'on commence à comprendre les websockets, on peut facilement trouver plein d'idées où les websockets seraient très utiles.

Quelles différences avec COMET ?

On peut déjà faire quasiment tout ce que les websockets proposent avec COMET. En gros, ça consiste à ouvrir une connexion et d'attendre que le serveur ait quelque chose à envoyer. Et quand le serveur finit par envoyer un message, la connexion est fermée et le navigateur en ouvre une deuxième. Pour les messages du navigateur vers le serveur, c'est plus simple : une simple requête Ajax (en parallèle de la connexion en attente) et le tour est joué.

Cette technique est quand même bien moins pratique à utiliser. Tout d'abord, du coté navigateur, ça fait pas mal de connexions à gérer, faut faire attention aux timeouts, etc. Ensuite, si le serveur veut envoyer plusieurs messages de manière rapprochée, il y a un risque que le client soit un peu trop long pour ouvrir la nouvelle connexion et qu'un message soit perdu. Enfin, toutes ses ouvertures et fermetures de connexions ont un coup élevé en termes de performances.

On peut l'utiliser pour de vrai ?

Voici la question qui fâche. La spécification de l'IETF est encore très discutée. Du coup, très peu de serveurs ou reverse-proxys implémentent le protocole websockets. Par exemple, ce n'est pas encore possible d'utiliser Nginx ou Varnish avec des websockets.

Coté navigateurs, ce n'est pas beaucoup mieux. Internet Explorer n'implémente pas du tout les websockets. Opera et Firefox 4 ont une implémentation mais désactivée par défaut car le protocole dans sa version actuelle souffre de problèmes de sécurité. Chrome et Safari ont également une implémentation, celle-ci est activée par défaut mais on peut s'attendre à ce qu'elle soit désactivée pour les mêmes raisons de sécurité.

En bref, les websockets, c'est bien, mais pas encore tout de suite, ou alors, il vaut mieux prévoir des fallbacks (sockets flash ou COMET).

blog comments powered by Disqus