Comunicación en Tiempo Real en Node.js

"Tiempo real" en una API de Node.js casi siempre significa una cosa específica: el servidor necesita decirle algo a un cliente conectado antes de que ese cliente lo solicite.

El HTTP simple nunca fue construido para eso; cada intercambio comienza con una solicitud del cliente, y un servidor solo puede responder a una solicitud que ya llegó.

WebSocket, Server-Sent Events y long-polling son tres formas diferentes de adaptar ese modelo de "primero la solicitud" a algo que admita envíos iniciados por el servidor, y cada uno hace un compromiso diferente entre direccionalidad, complejidad y compatibilidad de infraestructura.

Conceptos Básicos de Tiempo Real muestra el código para elegir entre ellos; esta página trata sobre el problema subyacente que todos resuelven y el costo que cada solución impone a un proceso de Node una vez que las conexiones comienzan a acumularse.

Resumen

• La comunicación en tiempo real es el problema de la entrega iniciada por el servidor sobre un protocolo (HTTP) que fue diseñado estrictamente en torno a solicitudes iniciadas por el cliente, y cada técnica en tiempo real es una solución específica para esa discrepancia.
• Por Qué Importa: Elegir el mecanismo incorrecto no solo añade latencia, sino que cambia lo que tu infraestructura (balanceadores de carga, proxies, firewalls corporativos) permitirá pasar, y cambia cómo se consumen los recursos de un solo proceso de Node.
• Conceptos Clave: modelo de solicitud-respuesta, conexión persistente, actualización de conexión, direccionalidad, distribución (fanout).
• Cuándo Usar: Paneles y feeds en vivo, herramientas de chat y colaboración, entrega de notificaciones, funciones multijugador o de presencia, y cualquier interfaz de usuario que actualmente sondea un endpoint con un temporizador para "buscar actualizaciones".
• Limitaciones / Compromisos: Cada mecanismo en tiempo real sacrifica algo por su capacidad de envío: WebSocket sacrifica la compatibilidad con la infraestructura HTTP, SSE sacrifica la bidireccionalidad, long-polling sacrifica la latencia y la rotación de conexiones; ninguno de ellos hace que el problema de entrega subyacente sea gratuito.
• Temas Relacionados: el bucle de eventos y la concurrencia de conexiones, la afinidad de sesión del balanceador de carga, la distribución de mensajes pub/sub, la autenticación de conexiones.

Fundamentos

El modelo de solicitud-respuesta de HTTP significa que el servidor es fundamentalmente reactivo: solo puede hablar cuando se le habla, respondiendo a una solicitud y luego, en el modelo clásico, cerrando ese intercambio.

Eso está bien para la carga de una página, pero se rompe en el momento en que un servidor necesita decirle a un cliente ya conectado "algo cambió" sin que ese cliente lo haya preguntado en el último segundo.

Tres mecanismos resuelven esto, cada uno relajando una parte diferente de las reglas de HTTP:

• WebSocket no extiende HTTP tanto como lo abandona: una solicitud HTTP pide "actualizar" la conexión, y una vez que el servidor acepta, las dos partes abandonan HTTP por completo e intercambian mensajes bidireccionales sin procesar sobre el mismo socket TCP mientras permanezca abierto.
• Server-Sent Events (SSE) permanece dentro de HTTP: el servidor simplemente nunca termina de responder, manteniendo una respuesta HTTP larga abierta y escribiendo nuevas líneas data: en ella con el tiempo, que la API EventSource del navegador convierte de nuevo en eventos discretos.
• Long-polling no cambia las reglas de HTTP en absoluto: el cliente envía una solicitud ordinaria, y el servidor simplemente retrasa su respuesta hasta que tiene algo que decir (o pasa un tiempo de espera), después de lo cual el cliente abre inmediatamente otra.

Una forma útil de visualizar la diferencia: WebSocket es como abrir una línea telefónica y dejarla conectada para que cualquiera de las partes pueda hablar cuando quiera; SSE es como una transmisión de radio unidireccional a la que el oyente se sintonizó, donde solo la estación transmite; long-polling es como llamar repetidamente a alguien y preguntar "¿hay algo nuevo?", esperando en espera hasta que tengan noticias o cuelguen.

// SSE: el servidor nunca "termina" esta respuesta, simplemente sigue escribiendo
res.writeHead(200, { "Content-Type": "text/event-stream" });
res.write(`data: ${JSON.stringify({ price: 142.5 })}\n\n`);
// la conexión permanece abierta; más llamadas a res.write() siguen más tarde

Qué mecanismo encaja depende casi por completo de la direccionalidad: ¿el cliente necesita enviar datos a través del mismo canal después de la conexión inicial, o solo recibe?

Mecánica e Interacciones

La diferencia mecánica más profunda entre estos tres no es el formato de cable, sino lo que cada uno le cuesta a un proceso de Node mantener abierto.

Una solicitud HTTP ordinaria ocupa recursos del servidor solo durante la breve ventana entre la llegada y la respuesta; una conexión persistente (WebSocket o SSE) ocupa un socket, un trozo de memoria para búferes y estado por conexión, y una entrada en la contabilidad del bucle de eventos mientras esté abierta, independientemente de si fluyen datos activamente o no.

Ese es un modelo de recursos fundamentalmente diferente: un servidor de solicitudes por segundo escala con la tasa de solicitudes, mientras que un servidor de conexiones persistentes escala con el número de conexiones mantenidas simultáneamente; un servicio con tráfico modesto pero 50,000 conexiones WebSocket abiertas está bajo una presión de memoria real incluso si los mensajes son raros.

El bucle de eventos de un solo hilo de Node maneja esto razonablemente bien para las conexiones inactivas, ya que un socket abierto pero silencioso cuesta memoria pero no CPU; el bucle solo trabaja cuando un mensaje llega realmente a uno de ellos.

Donde se vuelve costoso es en la distribución activa (fanout), es decir, transmitir un mensaje a muchas conexiones a la vez, porque serializar y escribir en cada socket es un trabajo síncrono que ocupa el mismo hilo único detrás del cual esperan los mensajes de todas las demás conexiones.

// La transmisión es un trabajo O(n) en el único hilo que comparten todas las conexiones.
// Esta es la parte que consume CPU, no las conexiones inactivas en sí mismas.
for (const client of connectedClients) {
  client.send(payload); // cada llamada se ejecuta en serie en el mismo bucle de eventos
}

Esa única línea es la razón por la que "cuántas conexiones puede mantener Node" y "qué tan rápido puede Node transmitir a todas ellas" son dos preguntas diferentes con dos respuestas diferentes: el recuento de conexiones inactivas está limitado principalmente por la memoria, pero el rendimiento de la transmisión está limitado por cuánto trabajo síncrono cuesta cada send(), multiplicado por la cantidad de destinatarios.

La autenticación también tiene su propia particularidad mecánica aquí: debido a que una conexión persistente no es una solicitud nueva cada vez, las credenciales deben verificarse una vez, en el momento de la conexión o actualización; un WebSocket no tiene un "encabezado de autorización" por mensaje como lo tiene HTTP, por lo que un socket no autenticado al que se le permite conectarse primero y verificarse más tarde es una brecha real y explotable.

Consideraciones y Aplicaciones Avanzadas

Un solo proceso de Node no es donde los sistemas en tiempo real permanecen por mucho tiempo una vez que necesitan escalar más allá de una instancia, y ahí es donde aparece un segundo problema, más difícil: la distribución (fanout) entre procesos.

Si dos usuarios en el mismo canal de chat se conectan a dos instancias de Node diferentes detrás de un balanceador de carga, un mensaje de uno debe llegar de alguna manera al otro; las conexiones WebSocket en sí mismas son locales al proceso, por lo que la instancia A no tiene forma directa de escribir en un socket que la instancia B está manteniendo.

La solución estándar es un bus de mensajes compartido (Redis pub/sub es la opción común en esta pila) al que se suscribe cada instancia: la instancia A publica el mensaje una vez, y cada instancia, incluida la B, lo recibe y lo reenvía a cualquiera de sus propios sockets locales que les interese.

Esa única adición cambia el modo de falla de todo el sistema: el recuento de conexiones ya no necesita un enrutamiento fijo para "simplemente funcionar" por corrección, pero el bus de mensajes en sí mismo se convierte en una nueva dependencia que debe permanecer activa, y las garantías de ordenación/entrega de mensajes ahora son tan fuertes como las que proporciona el bus.

Escalado en Tiempo Real cubre este patrón (sesiones pegajosas, adaptadores de Redis y las compensaciones operativas) en profundidad; el punto a este nivel es reconocer por qué una solución de un solo proceso deja de ser suficiente mucho antes de que el recuento de conexiones sin procesar sea el cuello de botella.

Existen bibliotecas de nivel superior específicamente para absorber esta complejidad: Socket.IO agrupa la reconexión automática, la distribución basada en salas y un adaptador de Redis para este problema exacto entre instancias, a costa de un protocolo personalizado superpuesto a WebSocket (o un transporte de respaldo) en lugar de tramas WebSocket sin procesar.

Malentendidos Comunes

• "WebSocket es solo una versión más rápida de las solicitudes HTTP." No es HTTP en absoluto después del handshake de actualización inicial; es un protocolo de mensajes bidireccional sin procesar sobre el mismo socket TCP, sin la semántica de solicitud/respuesta de HTTP.
• "SSE está obsoleto porque existe WebSocket." SSE es una mejor opción siempre que el servidor solo necesite enviar, precisamente porque permanece dentro de HTTP simple: infraestructura más sencilla, reconexión automática y sin necesidad de negociación de actualización.
• "Más conexiones abiertas siempre significan más carga de CPU." Las conexiones persistentes inactivas cuestan memoria, no CPU; el bucle de eventos solo gasta ciclos en una conexión cuando un mensaje necesita ser enviado o recibido en ella.
• "Un balanceador de carga simplemente distribuye las conexiones WebSocket como las solicitudes HTTP." Una conexión WebSocket dada está anclada a la instancia de backend que la aceptó; el balanceador de carga no puede redirigir libremente una conexión abierta como lo hace con una nueva solicitud HTTP sin estado.
• "Las características en tiempo real escalan añadiendo más procesos de Node." Más procesos resuelven la capacidad de CPU/conexión, pero introducen un nuevo problema: un mensaje en una instancia no puede llegar a un cliente conectado a otra sin un bus compartido, por lo que escalar requiere resolver la distribución, no solo añadir instancias.

Preguntas Frecuentes

Relacionado

• Conceptos Básicos de Tiempo Real - ejemplos prácticos de selección de protocolo
• Biblioteca ws - detalles de implementación de WebSocket puro
• Server-Sent Events - el formato de cable y la API del navegador de SSE
• Socket.IO - la abstracción de nivel superior y sus compromisos
• Escalado en Tiempo Real - distribución (fanout), sesiones pegajosas y patrones multi-instancia
• El Bucle de Eventos de Node.js - el modelo de concurrencia sobre el que se ejecutan las conexiones persistentes

Versiones de la pila: Esta página fue escrita para Node.js 24 LTS, npm 10+ y TypeScript 5.6+.