Últimamente, el ritmo en que las tecnologías están evolucionando es frenético. Hace apenas 10 años, comenzaron a salir los primeros SmartPhones. Seguro que todos recordáis aquel famoso Iphone 3G que revolucionó el mundo, y provocó un cambio radical en el sector del teléfono móvil. Y es sorprendente ver que al cabo de pocos años, ya había una nueva versión, y luego otra, y otra … Al punto de que actualmente, cada año aparece un nuevo modelo de las grandes compañías, un nuevo modelo que es más rápido, más potente, tiene mejores prestaciones, etc.

Esto, sumado a que la informática cada vez es más protagonista en nuestras vidas, ha creado una bola de nieve haciendo que las personas cada vez quieran que las aplicaciones tengan una respuesta más rápida, e incluso en tiempo real. Jugando a videojuegos, chateando por las diferentes redes sociales, o haciendo una compra online, hemos llegado al punto donde el usuario espera una respuesta instantánea de estos eventos.

Pero, ¿cómo se puede conseguir esta interacción en tiempo real? Aquí es donde entran en juego los WebSockets.

¿Qué son los websockets?

Websocket es una tecnología desarrollada por el W3C (World Wide Web Consortium) que permite establecer una comunicación bidireccional entre cliente y servidor proporcionando canales a través de una única connexión TCP. Los websockets permiten prescindir del antiguo model HTTP llamado polling, que consistía en el envío de peticiones HTTP en un cierto intervalo para obtener una respuesta “inmediata”, y consigue una comunicación directa entre ambos puntos sin necesidad del envío de peticiones constantes.

Ejemplos del uso de websockets

• Feed de redes sociales
• Videojuegos con multijugador
• Edición colaborativa de documentos en red
• Chats
• Aplicaciones de localitzación

En todos estos casos, es necesaria una comunicación en tiempo real entre los usuaris i el servidor. ¿Cómo se crea esta comunicación?

Comunicación con websockets

La siguiente imatgen muestra el proceso de creación de la comunicación a través de websockets entre cliente i servidor.

El cliente envía una solicitud de handshake con el servidor para poder establecer una comunicación. Esta solicitud consiste en una petición HTTP con los siguientes headers:

• “host: {url}”. Indica el servidor al cual se quiere establecer la comunicación.
• “upgrade: websocket”. El campo de upgrade de una petición HTTP permite cambiar de protocolo una vez se ha podido realizar la conexión HTTP. En este caso, se indica que se quiere cambiar al protocolo websocket.
• “connection: upgrade”. Este campo indica el tipo de conexión que se quiere realizar. Normalmente se realiza una conexión de tipo “Keep-Alive”, pero en este caso, para poder hacer el cambio al protocolo websocket, este campo debe contener un tipo de conexión “upgrade”.
• “sec-websocket-key: {key}”. Este header proporciona parte de información del servidor de websockets para verificar que se ha recibido una petición válida en el momento de hacer el handshake.

El servidor recibe y comprueba esta petición, y responde realizando el cambio al protocolo que se ha indicado desde la petición del cliente, y por tanto, se establece la comunicación bidireccional entre cliente y servidor.

¿Qué otras ventajas podemos obtener con su uso?

Ponemos un ejemplo muy sencillo donde tenemos un servidor situado en una red A, que necesita hacer peticiones directas a un equipo situado en una red B.

Si el equipo dispone de una dirección IP pública (raramente pasará), el paquete se podrá enviar directamente al equipo. Antes pero, tendrá que pasar por el firewall y el router de la red B, lo que significa que en la red B será necesario permitir los paquetes que lleguen desde la red A.

Normalmente a los equipos se les asigna una dirección IP privada que solo es accesible dentro de la propia red. Esto hace que el paquete ya no se pueda enviar directamente al equipo, y se tenga que enviar a la IP pública de la red B, es decir, el punto de acceso de la red (firewall).

Una vez el paquete llega al punto de entrada de la red B, hay que hacerlo llegar al equipo destino, por tanto, hace falta que en este punt de entrada se tenga que añadir algún tipo de mecanismo que reenvie el paquete hacia el equipo destino (NAT).

Tampoco se quiere entrar en mucho detalle, pero resumidamente, este sistema no proporciona una buena escalabilidad para el tipo de servicios comentados anteriormente.

Con los websockets uno se puede olvidar de todo esto. Como ya se ha explicado, la conexión no se hace de Servidor → Cliente, sino de Cliente → Servidor. Esto permite que, en este ejemplo, sea el propio equipo de la red B quien haga la petición para crear la comunicación directamente con el servidor de la red A, siguiendo el proceso que se ha explicado en la sección anterior.