Technologies

Rendre ses applications vivantes avec les WebSockets

Publié le : Auteur: Florent DUPONT Un commentaire
technologies

Petit retour sur la présentation du Nantes JUG d’Octobre sur les WebSockets « Build Living Web Applications with WebSockets » de Peter Moskovits.

Les WebSockets, c’est quoi ?

Les sockets, vous avez déjà entendu parler ? C’est une connexion point à point entre 2 machines qui reste ouverte offrant un canal de communication bidirectionnel. Depuis le navigateur, il n’était pas techniquement possible de le faire nativement avec HTTP. Des solutions techniques ont donc émergées permettant de passer par du polling ou du long polling (AJAX/Comet) pour émuler ce comportement. Ces solutions restent non standardisées et ne sont que des émulations pour contourner le besoin technique.

C’est alors que HTML5 arrive …

Le principe

Le principe des WebSocket est d’offrir un canal connecté full-duplex entre le client et le serveur directement implémenté par le navigateur et qui va donc transiter sur le même port HTTP que l’application. L’idée est d’économiser les coûts des entêtes HTTP classiques qui sont envoyés lors des requêtes AJAX. En effet, lors d’envoi de petites quantités de données, l’approche AJAX est coûteuse car elle nécessite un entête HTTP classique d’ou généralement un paquet bien plus conséquent que la taille de données utile à envoyer.
Les WebSockets limitent la taille des paquets au strict minimum, tout en assurant une connexion ouverte, limitant également ainsi les temps de reconnexion et donc un temps de latence plus réduit qu’avec AJAX.
On gagne beaucoup de temps à utiliser une API conçu pour un besoin particulier plutôt que d’émuler avec des technologies qui n’étaient pas prévues pour.

Les WebSockets s’inscrivent dans une approche HTML5 dans laquelle la partie présentation est gérée entièrement côté navigateur et non sur le middleware (pas de « server-side generated HTML« ). Le serveur ne fait que gérer les messages à ses clients, ne fait pas création couche présentation, ce qui le rend beaucoup plus léger, plus réactif, et donc permettant de mieux répondre à la charge.

Le WebSocket en tant que tel est très simple et ne spécifie pas le format des données envoyées (on sait juste qu’elles sont en texte ou binaire). Par exemple, pas de système d’acknowledgement en WebSocket : il faut donc définir un protocole haut niveau qui le gérera. C’est une bonne pratique d’utiliser des protocoles de hauts niveaux qui vont valider l’envoi/réception de message, la sérialisation des données, etc.
Le WebSocket est en soi un sous protocole, il ne va faire que porter le flux de données et il est donc préférable de lui ajouter un protocole de plus haut niveau. Le constat est le suivant : si on l’utilise tel quel, en pratique, on va arriver à un point auquel on va avoir à créer son propre protocole haut niveau « maison ». Pourquoi alors ne pas réutiliser l’existant ?
On peut donc réutiliser les protocoles de messaging déjà connu : JMS, mais également XMPP ou AMQP.

Côté sécurité, au même titre qu’HTTPS repose sur SSL, WebSocket propose un mode sécurisé SSL : WebSocketSecure.

En savoir plus

Je conseille très vivement d’essayer la démo disponible sur le site de Kaazing. Elle montre comment faire intéragir deux parties clientes grâce à deux clienst dont la communication se fait via WebSocket au serveur (un client qui produit et un autre qui consomme). A tester avec Chrome et votre portable sous iOS ou Android.

A noter également, cette Refcardz disponible sur DZone qui donne une vision synthétique des WebSockets.

Quelques outils et liens intéressants

  • websocket.org : pour un test rapide.
  • ImpressJS : équivalent de Prezi en OpenSource.
  • caniuse.com (Can I use ?) permet de vérifier si votre navigateur est compatible avec les WebSocket.
  • JS Fiddle : permet de tester le codage d’appui HTML5/JS en live.
  • Kaazing.com : PaaS pour WebSocket.

Question ouverte

Comment gérer le fait que les devices mobiles nécessitent une connexion limitée (pour réduire la consommation de la batterie) ? Garder une connexion ouverte n’est pas forcément conseillé en mobilité…

  • Merci Florent pour ce post sur les WebSockets ou j’ai hâte de pouvoir l’utiliser dans nos projets professionnels. J’avais joue avec WebSocket en ayant développé une application de chat : côté client l’API WebSocket est très facile a utiliser (ça marchait par contre que sous Chrome) mais côté serveur c’est la partie ou j’en ai le plus sué car il n’y avait (à l’époque) pas vraiment de spécification au niveau API WebSocket.

    La solution que j’avais utilisé c’était celle de Jetty qui propose un support WebSocket que l’on peut utiliser en mode Embedded et qui permet ainsi de lancer l’application de chat sur un n’importe quel serveur qui ne supporte pas WebSocket (ex: serveur Tomcat). Si l’application de chat avec WebSocket intéresse quelqu’un j’ai tout expliqué pas à pas comment développer cette application avec WebSocket sur http://angelozerr.wordpress.com/about/websockets_jetty/

    Mais aujourd’hui il existe une JSR WebSocket http://www.jcp.org/en/jsr/detail?id=356 ce qui j’espère va forcer les serveurs d’applications à fournir un support WebSocket standard.

    Angelo.