WebSockets, ou la mise en abîme de TCP
Le web est basé sur le protocole HTTP, protocole client-serveur qui a une communication entre le client et le serveur en deux étapes. Le client après avoir ouvert une connexion fiable, fait une requête sur une ressource caractérisée par une URL, et le serveur renvoi le résultat correspondant, et ferme ensuite la connexion.
Le protocole est assez simple à comprendre, et sa forme textuelle facilite beaucoup la compréhension. Voici un exemple très simple:
GET /index.html
Réponse du serveur
Ce principe de conception n'est pas adapté aux applications en temps réel, car bien trop lourd pour leurs utilisations du réseau.
Par exemple, pour un client IRC (chat en ligne) sur le web, il n'est pas possible d'avoir les messages qui arrivent en continu.
Cependant, la version 1.1 de HTTP propose de ne plus fermer automatiquement la connexion après chaque requête, pour accélérer la navigation sur le web. Cette fonctionnalité s'appelle le keep-alive.
Une astuce classique est donc de faire pleins de requêtes HTTP à la suite qui sont en attente des messages. Quand un message arrive, le serveur écrit le message dans le flux, termine la requête, et passe à la requête suivante. Cela permet en une seule connexion d'avoir un temps réel plus ou moins précis. Car le protocole HTTP est assez lourd en contenu.
Mais même avec cette astuce, il est impossible d'écrire et de lire dans la même connexion. Pour des jeux en réseau, il faudrait ouvrir de nombreuses requêtes en même temps. De plus, utiliser des astuces de ce type n'est pas vraiment beau.
Bref, le protocole HTTP n'est pas du tout adapté au applications en temps réel, et il fallait trouver une solution.
Une solution simple et efficace aurait été de fournir une API TCP et UDP dans les navigateurs webs, mais ces derniers sont très liés au protocole HTTP, et ils ne peuvent descendre les couches du modèle OSI pour toucher au transport des données. HTTP faisant parti de la couche application, le protocole n'a pas à savoir ce qui tourne en dessous de lui, et le navigateur ne peut ainsi donc pas utiliser directement TCP ou UDP.
C'est là qu'arrive WebSockets, qui est une couche de transport au dessus de HTTP, tout ça dans un navigateur web. Son fonctionnement est cependant assez étrange, par son implémentation au dessus du protocole HTTP, ce dernier étant dans la couche application. On a donc une petite incohérence au niveau de la pile de protocoles du modèle OSI. Il y a une couche transport au dessus d'une couche application. D'où la mise en abîme dans le titre.
WebSocket possède une api en javascript de bonne qualité, et son utilisation pourrait exploser dans les temps à venir.
Il est possible de s'amuser avec dans les dernières version de WebKit, en attendant une possible implémentation dans les autres navigateurs webs. La guerre des navigateurs webs étant de nouveau d'actualité.
Malgré tout, le protocole s'éloigne beaucoup de HTTP, en abandonnant le texte pour des codes contenus dans des octets, et cassant la comptabilité avec les serveurs webs. Car l'écriture par le client durant l'envoi des réponses par le serveur change beaucoup le fonctionnement d'un serveur web. Les serveurs mandataires webs sont eux aussi touchés, et il semblerait que si certains arrivent à gérer le fait que le client puisse écrire durant la réponse du serveur, d'autres n'aiment pas du tout cette éventualité.
L'arrivée sur le web ne peut donc pas se faire d'un coup, et il existera toujours des problèmes avec les vieux logiciels, ou le vieux matériel.
C'est un bon essai, mais ce n'est toujours pas demain que l'on pourra avoir un bon client IRC sans hacks pas beaux dans un navigateur web.
Sources:
