WebSocket es una tecnología integral en muchas aplicaciones web modernas. Si escribe código para la web, probablemente haya escuchado el término antes, pero tal vez no esté seguro de qué es exactamente o cómo usarlo. Afortunadamente, WebSocket no es un concepto complejo y puede obtener una comprensión básica de él con bastante rapidez.
¿Qué es WebSocket?
WebSocket, desafortunadamente, es uno de esos nombres que no parece tener sentido a primera vista. WebSocket es en realidad el nombre de un Protocolo de comunicación que permite la comunicación bidireccional entre el cliente y el servidor web.
En términos más simples, WebSocket es una tecnología que permite que un cliente y un servidor creen una conexión donde cualquiera de las partes puede enviar un mensaje a la otra en cualquier momento.
Esto es diferente de una conexión HTTP regular, donde el cliente debe iniciar una solicitud y solo entonces el servidor puede enviar una respuesta. De hecho, WebSocket es un protocolo de comunicación completamente diferente de HTTP que fue diseñado para ser compatible con HTTP. Cuando una aplicación cliente quiere iniciar una conexión WebSocket, necesita usar el
Mecanismo de actualización HTTP para cambiar al protocolo WebSocket.En este punto, podría estar pensando: "un protocolo es solo un conjunto de reglas, ¿cómo puede usar eso para codificar?".
La pieza que falta es algo llamado pila de protocolos. Esencialmente, los dispositivos que admiten un protocolo tienen hardware y software incorporados que le permiten escribir aplicaciones que se comunican mediante el protocolo. El protocolo no se usa directamente para construir nada.
¿Por qué se creó WebSocket?
Para ilustrar la necesidad de WebSocket, considere el mecanismo detrás del chat en Internet.
Alguien envía un mensaje al servidor de chat desde su dispositivo, pero el servidor aún tiene que enviar ese mensaje a su dispositivo antes de que pueda leerlo. Si el servidor usa HTTP, el servidor no puede reenviarle ese mensaje directamente, porque el servidor no puede iniciar solicitudes.
Hay un par de formas de solucionar este problema con HTTP. Una forma es que el cliente envíe constantemente solicitudes de actualización al servidor, y el servidor reenviará cualquier dato que tenga en la respuesta. Esta técnica se denomina sondeo y cada solicitud se denomina sondeo. Hay dos variantes de sondeo: sondeo largo y sondeo corto.
El uso de la variante de sondeo largo significa que el dispositivo cliente pregunta constantemente al servidor si hay mensajes nuevos disponibles. Si hay nuevos mensajes disponibles, el servidor enviará los mensajes como respuesta. De lo contrario, el servidor retrasaría la respuesta y mantendría abierta la conexión hasta que tuviera datos para devolver, y luego el cliente haría una nueva solicitud de inmediato.
Esta técnica es ineficiente porque HTTP no fue diseñado para usarse de esta manera. Funciona adecuadamente a pequeña escala, pero cada solicitud HTTP implica el envío de datos adicionales en el encabezado, y da como resultado una carga significativamente mayor en el servidor cuando muchos clientes están sondeando eso.
Aquí hay un diagrama que ilustra el sondeo largo:
La variante de sondeo corto es aún menos eficiente. En el sondeo breve, el servidor no mantiene abierta la conexión hasta que haya nuevos datos, lo que significa que el cliente tiene que seguir sondeando el servidor a intervalos fijos muy cortos.
Otra técnica para la comunicación bidireccional en HTTP se llama transmisión.
En la transmisión, después de que se envía la primera solicitud, el servidor mantiene abierta la conexión indefinidamente y envía nuevos datos como respuestas parciales continuas al cliente.
El uso de la transmisión da como resultado una sobrecarga de datos y una carga del servidor menores que el sondeo, porque idealmente el cliente realiza solo una solicitud HTTP. Desafortunadamente, la transmisión crea problemas bajo ciertas condiciones porque los navegadores y los intermediarios de la red (como los proxies) a menudo intentan manejar la respuestas parciales como piezas rotas de una gran respuesta HTTP (que es el comportamiento HTTP normal), en lugar de los mensajes separados que estaban destinados a ser.
WebSocket fue creado para resolver estos problemas. A diferencia de HTTP, WebSocket se diseñó específicamente para la comunicación bidireccional. Con WebSocket, una vez que se abre una conexión, el cliente y el servidor pueden enviar mensajes de ida y vuelta sin problemas de sondeo o transmisión.
Casos de uso para WebSocket
WebSocket es excelente, pero eso no significa que deba usarse en todas partes.
La implementación de WebSocket puede agregar complejidad a su aplicación, especialmente en el lado del servidor, por lo que no debe hacerlo a menos que tenga una buena razón. Eso plantea la pregunta: ¿cómo es una buena razón?
WebSocket es ideal para casos de uso donde se requiere comunicación bidireccional frecuente con baja latencia. En otras palabras, WebSocket brinda una ventaja para las aplicaciones que necesitan comunicarse con frecuencia o a gran escala. Si la comunicación no necesita ser en tiempo real o la aplicación nunca crecerá a gran escala, el sondeo o la transmisión pueden ser suficientes para usar en esa aplicación.
Los usos típicos de WebSocket son la creación de aplicaciones de chat, juegos multijugador en línea, software de notificación y colaboración en tiempo real, etc.
Cómo usar WebSocket en el lado del cliente
El uso de WebSocket en el lado del servidor puede ser bastante complicado, y el proceso varía sustancialmente según el idioma (como C#, Java, etc.) y la biblioteca de elección, por lo que no lo cubriremos aquí. A continuación, analizaremos brevemente cómo usar WebSocket en el lado del cliente.
Todos los navegadores modernos implementan una API web llamada API de WebSocket, que es la pila de protocolos del navegador para el protocolo WebSocket. Puede usar WebSocket en JavaScript usando esta API. La API le permite crear un objeto WebSocket, a través del cual crea una conexión WebSocket e interactúa con el servidor WebSocket.
Puede usar el siguiente formato de código para crear un objeto WebSocket:
let ejemploSocket = new WebSocket("wss://www.ejemplo.com/socketserver", "protocolo ficticio");El primer argumento del constructor es el URI del servidor WebSocket con el que desea crear una conexión. Siempre comenzará con "ws" o "wss". El segundo argumento es opcional. Su valor es una cadena o una matriz de cadenas, que especifica los subprotocolos que admite.
El objeto WebSocket tiene una propiedad de solo lectura llamada readyState. El acceso a esta propiedad proporciona el estado actual de la conexión WebSocket. readyState tiene cuatro valores posibles: "conectando", "abierto", "cerrando" y "cerrado".
Cuando se ejecuta esa línea de código, el navegador intentará conectarse al servidor especificado. La conexión no se completará de inmediato, por lo que el readyState de exampleSocket estará "conectando". No se pueden enviar ni recibir mensajes hasta que se complete la conexión, momento en el que el valor de readyState se convertirá en "abierto".
los ejemploSocket objeto tiene un detector de eventos (que es diferente de Oyentes de eventos DOM) llamado "onopen" que le permite realizar más acciones solo después de que se haya establecido la conexión. El objeto también tiene un método de "envío" que le permite enviar cadenas, Blobs (datos binarios) y ArrayBuffers como mensajes al servidor.
Aquí hay un ejemplo usando estos juntos:
ejemploSocket.onopen = función (evento) {
ejemploSocket.send("WebSocket es realmente genial");
};La API también proporciona una forma de reaccionar a los mensajes que envía el servidor. Esto se hace con el detector de eventos "onmessage". Aquí hay un ejemplo:
ejemploSocket.onmessage = función (evento) {
consola.Iniciar sesión(evento.datos);
}En su lugar, también puede escribir una función de flecha:
ejemploSocket.onmessage = (evento) => { consola.log (evento.datos); }La API también proporciona una cerca() método para cerrar la conexión. Esto es lo que parece:
ejemploSocket.cerca();WebSocket permite una comunicación bidireccional eficiente
WebSocket es un protocolo de comunicaciones bidireccional. Los servidores y los navegadores implementan pilas de protocolos para comunicarse mediante WebSocket. WebSocket existe porque HTTP no fue diseñado para ser bidireccional. Hay métodos para implementar conexiones bidireccionales con HTTP, pero tienen problemas.
WebSocket es una tecnología poderosa, pero no es necesaria en todos los casos, ya que puede complicar significativamente la arquitectura de la aplicación. El uso de WebSocket en el lado del cliente se realiza con la API WebSocket del navegador.