Las conexiones de red permanentes y bidireccionales en el mundo web siempre habían sido un poco problemáticas por cómo funcionan los protocolos sobre los que se basan. Esto ya no es así gracias a la estandarización del protocolo WebSocket en 2011.
Qué es
WebSocket es un protocolo de comunicación bidireccional entre cliente y servidor. Cualquiera de las dos partes puede enviar un mensaje en cualquier momento, a diferencia de una conexión HTTP, donde sí o sí, el intercambio de datos debe ser iniciado por el cliente y, solo entonces, el servidor puede responder.
Este protocolo se diseñó para ser compatible con HTTP. Cuando desde una página web se crea un WebSocket, se inicia un cambio de protocolo a través de la cabecera Upgrade de HTTP.
Qué problemas soluciona
Para entender la necesidad de un mecanismo como WebSocket es ideal el ejemplo de una aplicación de chat.
Imagina que mandas un mensaje a otra persona. Tú, como cliente, desde la aplicación, mandas la petición al servidor para que deje cierto mensaje al destinatario. Lo que sucede ahora, es que el servidor lo guarda, ya que en HTTP no es posible que el servidor inicie ninguna petición, siempre tiene que ser el cliente. Hasta que el destinatario no solicite al servidor los mensajes, no verá lo que le has enviado.
Este comportamiento es un problema, ya que de ser así, las aplicaciones de chat funcionarían igual que el correo electrónico.
¿Solución sin WebSockets? Sí, pero...
Una posible solución es que el cliente solicite actualizaciones al servidor de forma continuada. Esta técnica se llama polling.
Puede pasar que el servidor, una vez reciba una solicitud de actualización, en caso de no haber ninguna, no responda y mantenga esa conexión abierta hasta que haya novedades. En el momento que el cliente recibe actualizaciones, immediatamente manda otra solicitud al servidor. A esto se le llama long polling, y es un problema si hay muchas peticiones ya que la carga del servidor aumenta mucho.
Otra forma de hacerlo es mediante lo que se llama short polling, que consiste en que el servidor no mantiene la conexión abierta, responde directamente haya novedades o no. Entonces, el cliente hace de nuevo otra petición de forma immediata o cada ciertos intervalos cortos de tiempo. Esta solución es casi peor que la anterior.
Otra técnica diferente es el streaming. ¿Te suena? Es otra forma de comunicación bidireccional, en la que una vez que el cliente envía la primera petición, el servidor mantiene la conexión abierta y devuelve de forma continuada respuestas parciales. Esta técnica es de lejos mejor que el polling, pero es una solución "antinatural" ya que el protocolo HTTP no está hecho para tratar muchas respuestas como si fueran una sola y esto suele ocasionar problemas.
Con WebSockets sí que sí
Con este protocolo se solucionan todos los problemas presentados, es un protocolo específico para cubrir los requerimientos de una comunicación bidireccional. Con WebSockets, una vez se abre una conexión, tanto el cliente como el servidor pueden enviar y recibir mensajes sin problemas.
Cúando usarlo
Como hemos visto, una aplicación de chat es ideal para esto porque se necesita una comunicación bidireccional y, además, latencia baja. Si se cumplen esas dos condiciones, WebSocket es tu protocolo.
Para comunicaciones frecuentes a gran escala nos viene como agua de mayo. Si las comunicaciones no son a gran escala, soluciones como el polling o el streaming son aceptables, ya que usar WebSocket va a añadir cierta complejidad a la aplicación.
Otros casos de uso pueden ser por ejemplo juegos online multijugador, aplicaciones de colaboración en tiempo real o aplicaciones de notificaciones.
Conclusión
El protocolo HTTP no se creó teniendo en mente una comunicación bidireccional instantánea, su función era otra. Cuando ha aparecido la necesidad de actualizaciones en tiempo real entre cliente y servidor, WebSocket ha sido el protocolo que ha venido a poner orden.
Con este protocolo solucionamos todos los problemas ocasionados al simular una comunicación instantánea y bidireccional con HTTP. Lo malo es que añade un poco más de complejidad a la aplicación, pero nada que no sea abarcable si la necesidad aprieta.
Para ver cómo implementar este protocolo con JavaScript desde el lado del cliente y Python desde el lado del servidor, esta es la continuación.