Desde el 2009 he estado mencionando a WebSockets acá en eliax, pero creo que el tiempo ha llegado para que los desarrolladores de software lo tomen ya en serio, pues dado que las últimas versiones de todos los navegadores web populares (Chrome, Safari, Firefox, Opera, y la próxima versión de Internet Explorer 10) lo soportan, es hora de entender de qué se trata esta tecnología...

Noten que esta no es una guía de programación (pues ya hay varias en la red y no quiero reinventar la rueda, y al final de este artículo los dirijo a unos cuantos recursos de esa naturaleza), sino que una guía de alto nivel para que entiendan (1) qué es WebSockets, (2) por qué se necesita, y (3) cuáles son sus ventajas.

El problema que WebSockets trata de solucionar es el de cómo hacer que un servidor le envíe datos a un cliente (es decir, a un navegador web).

Hoy día existen dos maneras populares de lograr eso, y ambas pueden ser consideradas "hacks" y no soluciones a largo plazo (y lo digo por experiencia, pues he utilizado ambas maneras en mi propio código). Y para ilustrar con un ejemplo, asumamos que queremos crear una aplicación de chateo que comunique a varias personas que se comuniquen a un mismo portal web entre sí.

La primera forma de hacer ese sistema es con una técnica llamada polling. Esta es una técnica en donde en código de javascript en el navegador web uno pone un intervalo usualmente fijo (por ejemplo, cada 5 segundos), y al final de esos 5 segundos uno hace una llamada al servidor web preguntando "¿tengo un mensaje nuevo?".

Por lo general, uno no tendrá un mensaje nuevo (salvo que se esté chateando activamente, pero esa es la excepción a la regla), por lo que posiblemente la mayoría de esas conexiones al servidor serán respondidas con "no, no hay novedad".

Eso, como se podrán imaginar, es un gran malgasto de recursos, ya que estamos haciendo conexiones constantes al servidor (y transfiriendo datos con el protocolo HTTP), innecesariamente la mayor parte del tiempo.

De paso es un problema serio ya que puede sobrecargar la capacidad del servidor de tener que responder a potencialmente miles o millones de usuarios simultáneamente sin razón alguna.

Y lo peor es que en aplicaciones de tiempo real (como chateo) no podemos poner un tiempo de intervalo muy largo (como por ejemplo, 30 segundos), ya que eso haría que el usuario tenga que esperar demasiado tiempo esperando, y tomamos el riesgo a que se desespere y deje de utilizar la aplicación.

La otra opción es una variante que se llama long-polling, y se trata de crear una conexión al servidor, pero nunca cerrarla, de modo que el servidor pueda en cualquier momento responder al pedido del cliente cuando esté listo para responder.

Sin embargo, esa técnica tiene también sus problemas. Por ejemplo, si no sucede nada por mucho tiempo es posible que obtengamos un timeout y se cierre la conexión, lo que hace el código más complejo para lidiar con esos escenarios. Además, el mantener demasiadas conexiones abiertas (en particular con miles de usuarios conectados simultáneamente) es una tremenda carga para el servidor cuando se utiliza el protocolo HTTP, necesitándose de hardware más potente.

Y es aquí en donde entra en acción WebSockets...

WebSockets, como alude su nombre, trae el modelo de sockets de TCP/IP a la web, permitiendo comunicación bi-direccional entre servidores y navegadores web, en cualquier momento.

Pero, ¿cómo puede eso ser posible? Pues para empezar, el navegador web debe soportar la tecnología, y además el servidor web (o servidor de aplicaciones) debe implementar también el protocolo. No es algo que se hace encima de librerías existentes de Javascript.

De la manera que funciona es que el navegador web debe primero notificarle al servidor web que desea recibir mensajes por WebSockets, y proveer al subsistema de WebSockets local (es decir, javascript) la función a ser llamada estilo Callback cuando el servidor desee enviar datos.

En esencia, tu simplemente tienes que poner tu código que recibe el mensaje del servidor en la función callback, y te olvidas del resto. Cuando el servidor te envíe un mensaje, tu función será llamada de modo asíncrono, y tu código se ejecutará. Así de sencillo.

Algo genial es que el overhead de WebSockets es minúsculo comparado con el de HTTP. Para que tengan una idea, en mediciones realizadas (fuente) es posible bajar de requerir 655Mbps de ancho de banda (para soportar a 100,00 usuarios enviando 1 mensaje por segundo), a tan solo 1.5Mbps. Es decir, 430 veces menos ancho de banda.

Y ese ahorro en recursos se debe a que el protocolo soporta no solo la transferencia de objetos, sino que además de datos binarios (en forma de Blob o ArrayBuffer en javascript), permitiendo un nivel de baja latencia y rendimiento que hasta ahora era solo dominio de sockets de bajo nivel.

En cuanto a aplicaciones de WebSockets, son infinitas. Prácticamente cualquier aplicación que requiera de información del servidor en intervalos desconocidos y en tiempo real es candidato para utilizar Web Scoekts. Así mismo como cualquier aplicación que requiere de la eficiente transmisión de datos (como por ejemplo, programas de chateo, o incluso de voz, o de transferencia de archivos).

RFC 6455 (especificación oficial de WebSockets)

WebSocket.org (con recursos y ejemplos)

introducción a WebSockets (con muchas notas importantes)

introducción a WebSockets (con código)

Web Socket en Wikipedia

autor: josé elías