WebSocket: qué es, protocolo de comunicación full-duplex y cómo funciona

¿Qué es WebSocket?

WebSocket es un protocolo de comunicación que opera sobre TCP y proporciona un canal full-duplex entre un cliente y un servidor. Fue estandarizado por la IETF como RFC 6455 en 2011 y es compatible con todos los navegadores modernos, plataformas móviles y frameworks de servidor.

A diferencia de HTTP, donde el cliente inicia una solicitud y recibe una respuesta, WebSocket permite que ambos lados envíen mensajes en cualquier momento después de establecer la conexión. Esto lo hace ideal para escenarios que requieren entrega instantánea de datos: chats, notificaciones, edición colaborativa de documentos.

El protocolo WebSocket utiliza el puerto 80 de HTTP o el puerto 443 de HTTPS para el handshake inicial, después del cual cambia a su propio protocolo con una cabecera mínima — solo 2 bytes en lugar de 800+ bytes en HTTP. Esta característica proporciona una ventaja significativa de rendimiento con un gran número de mensajes.

Características clave del protocolo

Una conexión WebSocket comienza con una solicitud HTTP de actualización (Upgrade), después de la cual el protocolo cambia a un formato de trama binaria. El tamaño de la trama varía de 2 bytes a 2^63 bytes, lo que permite transmitir tanto mensajes de texto cortos como grandes datos binarios. El protocolo admite fragmentación de mensajes, enmascaramiento de datos del cliente al servidor, y ping/pong para mantener la conexión activa.

¿Cómo funciona WebSocket?

El proceso de establecimiento de una conexión WebSocket consta de dos etapas: handshake y transferencia de datos. Durante el handshake, el cliente envía una solicitud HTTP con la cabecera Upgrade: websocket, y el servidor confirma el cambio de protocolo con el estado 101 Switching Protocols. Después de esto, la conexión entra en modo de transmisión full-duplex.

Cada mensaje en WebSocket se divide en tramas. Una trama contiene un opcode (texto, datos binarios, cierre, ping/pong), longitud del payload y una clave de enmascaramiento para los datos del cliente. Las tramas pueden fragmentarse — las tramas de control (ping/pong) pueden transmitirse entre fragmentos de mensaje, evitando el tiempo de espera de la conexión durante transferencias largas.

const ws = new WebSocket('wss://example.com/chat')

ws.addEventListener('open', () => {
    console.log('Conexión establecida')
    ws.send('¡Hola, servidor!')
})

ws.addEventListener('message', (event) => {
    console.log('Recibido:', event.data)
})

ws.addEventListener('close', () => {
    console.log('Conexión cerrada')
})

En el ejemplo anterior, el cliente crea un objeto WebSocket especificando la URL segura wss://. Después de abrir la conexión, se envía un mensaje de bienvenida, y el controlador de mensajes recibe las respuestas del servidor. Al cerrar, se activa el controlador de cierre — esto es importante para la reconexión en caso de interrupciones de red.

WebSocket vs HTTP: comparación

La principal diferencia entre WebSocket y HTTP radica en el modelo de interacción. HTTP opera en un esquema de solicitud-respuesta: el cliente inicia una solicitud, el servidor devuelve una respuesta y la conexión se cierra. WebSocket, por otro lado, establece un canal persistente a través del cual ambos lados pueden iniciar la transmisión en cualquier momento.

Para aplicaciones que requieren baja latencia y un flujo constante de datos, WebSocket es significativamente más eficiente. HTTP Long Polling — una alternativa donde el servidor mantiene la solicitud abierta hasta que los datos están disponibles — crea una carga excesiva en el servidor y aumenta el consumo de memoria debido a múltiples conexiones simultáneas.

Según High Performance Browser Networking (Grigorik, O'Reilly), WebSocket reduce la latencia de red en escenarios en tiempo real entre un 40 y un 60% en comparación con HTTP Long Polling, mientras que la carga del servidor se reduce de 3 a 5 veces debido a la eliminación de handshakes repetidos.

¿Dónde se usa WebSocket?

Gracias a su baja latencia y comunicación bidireccional, WebSocket se utiliza en una amplia gama de aplicaciones. Los escenarios clave incluyen mensajería instantánea, sincronización de estado en juegos y transmisión de datos de mercado en sistemas financieros.

Chats y mensajería

WebSocket se ha convertido en el estándar de facto para aplicaciones de chat. Plataformas como Slack, Telegram Web y WhatsApp Web utilizan WebSocket para la entrega instantánea de mensajes. El protocolo permite enviar tanto mensajes de texto como archivos a través de un único canal, mientras que el mecanismo ping/pong mantiene la conexión activa incluso durante períodos de inactividad.

Juegos en línea

Los juegos multijugador de navegador y móviles requieren latencia mínima para sincronizar los estados de los jugadores. WebSocket transmite coordenadas, acciones y eventos en tiempo real sin las demoras de las solicitudes HTTP. Frameworks como Socket.IO y Colyseus abstraen las operaciones de bajo nivel del protocolo, añadiendo reconexión automática y salas.

Aplicaciones financieras

Los terminales de trading y las plataformas de negociación utilizan WebSocket para recibir cotizaciones en tiempo real. Un retraso de unos pocos milisegundos puede costar millones de dólares, por lo que las API financieras — como Binance WebSocket Streams, Coinbase Pro — proporcionan interfaces WebSocket para datos de mercado.

Aplicaciones móviles e IoT

En el desarrollo móvil, WebSocket se utiliza a través de API nativas: URLSessionWebSocketTask en iOS y OkHttp WebSocket en Android. Para Flutter, existe la librería web_socket_channel, y para React Native — react-native-websocket. Los dispositivos IoT utilizan WebSocket para transmitir telemetría y recibir comandos de control, ya que el protocolo consume menos energía que el HTTP polling constante.

Ejemplos de código WebSocket

Veamos un ejemplo del lado del servidor usando Node.js con la librería ws — la implementación de WebSocket más popular para JavaScript. El servidor acepta conexiones, procesa mensajes y los difunde a todos los clientes conectados.

const WebSocket = require('ws')
const wss = new WebSocket.Server({ port: 8080 })

wss.on('connection', (ws) => {
    console.log('Nuevo cliente conectado')

    ws.on('message', (data) => {
        console.log('Recibido:', data.toString())
        ws.send('El servidor recibió tu mensaje')
    })

    ws.on('close', () => {
        console.log('Cliente desconectado')
    })
})

console.log('Servidor WebSocket iniciado en el puerto 8080')

El servidor crea una instancia de WebSocket.Server en el puerto 8080 y espera conexiones. Cada nuevo cliente recibe un objeto ws separado a través del cual el servidor puede enviar mensajes individuales. La difusión de mensajes a todos los clientes se implementa iterando a través de la matriz de conexiones. Con un gran número de clientes (más de 1000), se recomienda utilizar librerías con soporte de clustering, como Socket.IO, que añaden escalado basado en Redis y reconexión automática.

Enviar mensajes a todos los clientes

wss.clients.forEach((client) => {
    if (client.readyState === WebSocket.OPEN) {
        client.send('Mensaje para todos los participantes')
    }
})

Verificar el readyState antes de enviar es obligatorio: si el cliente ya se ha desconectado, llamar a send lanzará un error. El flag WebSocket.OPEN garantiza que la conexión está activa y que el mensaje se entregará.

Para aplicaciones móviles iOS, WebSocket se implementa a través de URLSessionWebSocketTask, disponible desde iOS 13. La sesión crea una tarea con una URL de protocolo wss://, después de lo cual se llaman a los métodos send y receive. La recepción de mensajes se puede organizar mediante recursión continua de receive, que espera el siguiente mensaje después de procesar el anterior, asegurando una recepción constante de datos sin reconexión. Para Android, se utiliza OkHttp WebSocket, que proporciona una interfaz similar con callbacks onOpen, onMessage, onClosing y onClosed, así como reconexión automática ante la pérdida de conexión.

Al trabajar con WebSocket en aplicaciones móviles, es importante considerar la gestión del ciclo de vida: cuando la aplicación pasa a segundo plano, el sistema puede terminar la conexión. En iOS, la conexión debe restablecerse al volver al primer plano mediante el delegado sceneDidBecomeActive. En Android, se deben utilizar componentes Lifecycle-aware o un Service para mantener la conexión. Además, se recomienda implementar un backoff exponencial para la reconexión — aumentar el intervalo entre intentos de 1 a 30 segundos — para evitar crear una carga excesiva en el servidor durante problemas temporales de red.