Socket.IO — qué es, biblioteca para interacción en tiempo real

¿Qué es Socket.IO?

Socket.IO es una biblioteca JavaScript de código abierto para comunicación bidireccional basada en eventos entre cliente y servidor. Fue creada en 2010 por el desarrollador Guillermo Rauch y desde entonces se ha convertido en el estándar de facto para aplicaciones en tiempo real en Node.js.

A diferencia de la API WebSocket nativa, Socket.IO proporciona abstracciones adicionales: salas, espacios de nombres, reconexión automática y tipos de datos binarios. La biblioteca no es una implementación separada de WebSocket — utiliza Engine.IO como capa de transporte, que primero establece una conexión HTTP long-polling y luego intenta actualizar a WebSocket.

Según las estadísticas de npm (2025), se descargan más de 12 millones de copias del paquete socket.io cada semana, lo que lo convierte en una de las bibliotecas más populares del ecosistema Node.js. Socket.IO es compatible con todas las plataformas modernas: navegadores, iOS, Android, React Native y aplicaciones de escritorio.

Historia y versiones

Socket.IO versión 1.0 se lanzó en 2014 e introdujo el concepto de espacios de nombres, que permiten multiplexar múltiples canales lógicos a través de una sola conexión TCP. La versión 2.0 (2017) añadió soporte para datos binarios y mejoró el rendimiento del análisis. La versión actual 4.x (2020–2025) incluye soporte completo para TypeScript, un modo de adaptador insignia para escalado y una compatibilidad inversa mejorada.

Cada versión principal mantiene la compatibilidad inversa de API — un cliente socket.io@2 puede conectarse a un servidor socket.io@4 a través de un modo de compatibilidad especial. Esto es importante para proyectos de larga duración donde las actualizaciones del lado del cliente ocurren gradualmente.

Cómo funciona Socket.IO

La arquitectura de Socket.IO consta de dos componentes: el módulo del servidor (paquete npm socket.io) y el módulo del cliente (paquete npm socket.io-client). El servidor funciona sobre un servidor HTTP(S) de Node.js y utiliza Engine.IO para gestionar la capa de transporte.

En la conexión inicial, el cliente envía una solicitud HTTP al servidor. Engine.IO responde y establece una conexión long-polling. Después de eso, el cliente envía una solicitud para actualizar el protocolo de transporte a WebSocket. Si el servidor admite WebSocket, la actualización ocurre dentro de una sola sesión TCP. Si no, la conexión permanece en long-polling y el código de la aplicación no requiere cambios.

Según las pruebas de rendimiento de Socket.IO (2024), al usar WebSocket, la latencia es de 2 a 5 ms por transmisión de mensaje, mientras que long-polling añade de 150 a 300 ms debido a la sobrecarga HTTP. La elección del transporte es transparente para el desarrollador.

Protocolo Engine.IO

Engine.IO es la capa de transporte de bajo nivel sobre la que está construido Socket.IO. Se encarga del establecimiento de la conexión, la selección del transporte, el heartbeat (ping/pong) y la terminación de la conexión. Los tipos principales de paquetes de Engine.IO son: open (inicialización), close (cierre), ping/pong (keep-alive), upgrade (cambio de transporte) y message (datos).

Socket.IO construye su modelo basado en eventos sobre Engine.IO — es con lo que trabaja el desarrollador. Cada mensaje de Socket.IO se empaqueta en un paquete de Engine.IO de tipo message con un identificador único para la confirmación de entrega.

Características principales de Socket.IO

Socket.IO proporciona un conjunto de funciones que no están presentes en la API WebSocket nativa y facilitan significativamente el desarrollo de aplicaciones en tiempo real. Veamos las principales.

Reconexión automática — el cliente restablece automáticamente la conexión tras una interrupción con retroceso exponencial (100 ms, 200 ms, 400 ms... hasta un máximo). Según la documentación de Socket.IO (2024), la configuración de reintentos está disponible a través de los parámetros reconnectionDelay y reconnectionAttempts. Esta opción es crítica para aplicaciones móviles donde la conexión puede interrumpirse durante los cambios de red.

Soporte de salas — el servidor puede agrupar sockets en salas y enviar mensajes solo a los participantes de una sala específica. Las salas no requieren creación explícita — se crean cuando el primer socket se une. Las salas se implementan a nivel de proceso y no se comparten entre diferentes servidores sin un adaptador especial.

Espacios de nombres — separación lógica de canales de comunicación en una sola conexión. Por ejemplo, el espacio de nombres /chat para mensajes de chat y /notifications para notificaciones. Cada espacio de nombres tiene sus propias salas, middleware y manejadores. Los espacios de nombres se multiplexan a través de una sola conexión TCP, ahorrando recursos.

Confirmación de entrega — al enviar un mensaje, se puede pasar una función callback que se ejecutará cuando el servidor confirme la recepción. Esto se implementa mediante un identificador único para cada paquete. El mecanismo de confirmación garantiza que los mensajes críticamente importantes (por ejemplo, transacciones de pago) se entreguen al destinatario.

Socket.IO vs WebSocket: comparación

La elección entre Socket.IO y WebSocket nativo depende de los requisitos del proyecto. WebSocket es un protocolo estandarizado (RFC 6455) compatible con todos los navegadores modernos. Socket.IO es una biblioteca que utiliza WebSocket como transporte pero añade funciones adicionales.

Si tu proyecto requiere máximo rendimiento y un tamaño mínimo de cliente — elige WebSocket nativo. Si necesitas entrega confiable, agrupación y un modelo basado en eventos — Socket.IO reducirá el tiempo de desarrollo en 2 o 3 veces gracias a las abstracciones listas para usar.

Según la encuesta State of JS 2024, el 67% de los desarrolladores de aplicaciones en tiempo real prefieren Socket.IO por su API conveniente y el manejo integrado de casos límite (desconexión de red, reconexión, datos binarios).

Cómo conectar Socket.IO en un proyecto

Instalación de Socket.IO requiere dos paquetes: del lado del servidor y del lado del cliente. Veamos la configuración básica para un proyecto Node.js. El servidor crea un servidor HTTP, inicializa Socket.IO y maneja los eventos de conexión y desconexión de clientes.

Según la documentación de Socket.IO (2024), el servidor se puede iniciar sin Express usando el módulo http integrado, pero en proyectos reales se suele usar Express o Fastify para el enrutamiento de solicitudes HTTP.

Código del servidor en Node.js

const express = require('express');
const http = require('http');
const Server = require('socket.io');

const app = express();
const server = http.createServer(app);
const io = new Server(server, {
    cors: { origin: '*' }
});

io.on('connection', (socket) => {
    console.log('Cliente conectado:', socket.id);

    socket.emit('welcome', { message: 'Hello from server' });

    socket.on('disconnect', () => {
        console.log('Cliente desconectado');
    });
});

server.listen(3000, () => {
    console.log('Servidor ejecutándose en el puerto 3000');
});

Código del cliente en el navegador

import { io } from 'socket.io-client';

const socket = io('http://localhost:3000', {
    transports: ['websocket', 'polling'],
    reconnectionDelay: 1000
});

socket.on('welcome', (data) => {
    console.log(data.message);
});

socket.emit('chat message', {
    user: 'Alice',
    text: 'Hello everyone!'
});

Eventos y salas en Socket.IO

El modelo de eventos de Socket.IO se basa en eventos nombrados. El servidor y el cliente envían y reciben mensajes vinculados a un nombre de evento específico. El payload puede ser una cadena, un objeto JSON o datos binarios (Buffer, ArrayBuffer, Blob).

Cada evento admite ACK (acknowledgement) — pasar una función callback que se ejecuta en el lado del remitente después de que el receptor procesa el evento. Esto permite implementar un patrón de solicitud-respuesta sobre el modelo de eventos. ACK solo funciona si el receptor llama explícitamente al callback.

Según la documentación de Socket.IO (2024), el tamaño máximo de un solo mensaje no debe exceder 1 MB para un rendimiento óptimo. Los mensajes más grandes deben dividirse en fragmentos o enviarse a través de un canal separado.

Trabajar con salas

io.on('connection', (socket) => {
    socket.join('room-1');

    socket.to('room-1').emit('user joined', {
        userId: socket.id
    });

    io.to('room-1').emit('message', {
        text: 'Broadcast to room'
    });

    socket.leave('room-1');
});

Escalado de Socket.IO

El escalado horizontal de Socket.IO requiere resolver el problema de compartir el estado entre múltiples procesos del servidor. Las salas, los espacios de nombres y la lista de sockets conectados se almacenan en la memoria de un solo proceso y no son visibles para otros procesos sin un adaptador.

Adaptadores oficiales de Socket.IO: redis (a través de Redis Pub/Sub), mongodb (a través de MongoDB change streams), cluster (para el modo multiproceso de Node.js cluster). El adaptador actúa como un intermediario de mensajes entre instancias de Socket.IO. Cuando se envía un evento a una sala, el adaptador lo publica en Redis y todos los servidores reciben la notificación.

Según las pruebas de carga de Socket.IO (2024), un clúster de 4 servidores con el adaptador Redis maneja hasta 400 000 conexiones simultáneas con una latencia inferior a 10 ms. Sin adaptador, la capacidad máxima de un solo proceso de Node.js es de aproximadamente 100 000 conexiones con 1 GB de memoria.

Configuración del adaptador Redis

const Server = require('socket.io');
const RedisAdapter = require('@socket.io/redis-adapter');
const Redis = require('ioredis');

const pubClient = new Redis({ host: 'localhost', port: 6379 });
const subClient = pubClient.duplicate();
const io = new Server(server);
io.adapter(RedisAdapter(pubClient, subClient));

Al usar Kubernetes o Docker Swarm, se recomienda configurar adicionalmente la afinidad de sesión (sticky sessions) para que las solicitudes de un mismo cliente lleguen al mismo servidor; de lo contrario, la asignación puede cambiar con cada reconexión.