Comparación entre SSE, WebSockets y polling

WebSockets establece una conexión TCP persistente entre el cliente y el servidor. Ambos lados pueden enviar mensajes en cualquier momento, por lo que WebSockets es ideal para comunicaciones interactivas en tiempo real: aplicaciones de chat, edición colaborativa de documentos, juegos multijugador y cursores en directo. La conexión permanece abierta hasta que cualquiera de las partes la cierra explícitamente.

SSE (Server-Sent Events) utiliza una conexión HTTP normal en la que el servidor transmite datos al cliente como una serie de eventos. La conexión es unidireccional: solo el servidor envía datos. El cliente no puede enviar mensajes de vuelta a través de la conexión SSE; para ello realiza solicitudes HTTP independientes. SSE se implementa mediante la API EventSource del navegador.

El polling corto significa que el cliente envía una solicitud HTTP a intervalos fijos (por ejemplo, cada 5 segundos): «¿Hay alguna actualización?». El servidor responde inmediatamente con los datos actuales. Es la implementación más sencilla, pero también la que más recursos desperdicia: el cliente realiza muchas solicitudes cuando no hay nada nuevo. Solo es adecuado para datos que cambian muy lentamente.

El polling largo mejora el polling corto: el cliente realiza una solicitud y el servidor mantiene abierta la conexión hasta que hay nuevos datos disponibles. Cuando llegan datos nuevos, el servidor responde y el cliente realiza inmediatamente otra solicitud. Esto reduce las respuestas innecesarias, pero sigue teniendo más sobrecarga que SSE porque cada respuesta requiere establecer una nueva conexión TCP.

SSE ofrece varias ventajas prácticas frente a WebSockets para enviar actualizaciones del servidor al cliente: funciona sobre HTTP normal (sin actualización de protocolo), por lo que atraviesa proxies corporativos y balanceadores de carga sin una configuración especial. EventSource incorpora la reconexión automática. El protocolo basado en texto es fácil de depurar en la pestaña de red del navegador.

SSE tiene limitaciones reales: solo admite texto (los datos binarios deben codificarse en base64), es unidireccional (el cliente no puede enviar datos de vuelta) y HTTP/1.1 limita a 6 el número de conexiones EventSource simultáneas por dominio (HTTP/2 las multiplexa en una sola conexión y elimina este límite). Para la comunicación bidireccional, SSE requiere llamadas REST complementarias.

SSE es ideal para: paneles en directo que muestran métricas en tiempo real, fuentes de notificaciones que envían nuevas alertas, barras de progreso de procesos del servidor de larga duración, fuentes de redes sociales en directo, indicadores de cotizaciones bursátiles y interfaces de chat en las que los mensajes solo fluyen del servidor al cliente (los mensajes se envían por separado mediante POST). Todos son escenarios en los que el servidor inicia las actualizaciones.

WebSockets son necesarios cuando se necesita una comunicación bidireccional de baja latencia: chats en tiempo real en los que los mensajes circulan en ambas direcciones por una sola conexión, edición colaborativa (al estilo de Google Docs), juegos multijugador en los que las acciones del cliente y las actualizaciones del servidor se producen rápidamente, subastas en directo y plataformas de negociación. La bidireccionalidad justifica la complejidad.

HTTP/2 mejora considerablemente la viabilidad de SSE. La multiplexación de conexiones hace que todas las transmisiones SSE de un dominio compartan una sola conexión TCP, eliminando el límite de conexiones por dominio. Si el servidor admite HTTP/2, SSE resulta aún más práctico para paneles con varias transmisiones de datos simultáneas.

Marco de decisión: si necesita comunicación bidireccional de baja latencia → WebSockets. Si el servidor envía actualizaciones y el cliente solo lee → SSE. Si necesita actualizaciones ocasionales y la simplicidad es importante → polling. Si la API del servidor ya existe y no puede añadir SSE → polling. Comience con la solución más sencilla que cumpla sus requisitos de latencia.

El entramado de WebSocket añade entre 2 y 14 bytes por mensaje después del handshake inicial. SSE añade las cabeceras HTTP una vez por conexión y, después, texto delimitado por saltos de línea. El polling corto incluye las cabeceras completas de solicitud y respuesta HTTP en cada consulta. Para datos de alta frecuencia, WebSockets ofrece la menor sobrecarga. Para envíos del servidor poco frecuentes, SSE es más sencillo y su sobrecarga resulta aceptable.

¿Cuál es la diferencia direccional fundamental entre SSE y WebSockets?

WebSockets: conexión TCP persistente y bidireccional (chats, juegos y edición colaborativa). SSE: push HTTP unidireccional del servidor al cliente mediante la API EventSource (notificaciones, paneles y fuentes). Polling corto: solicitudes a intervalos fijos (más sencillo y derrochador). Polling largo: el servidor mantiene la respuesta hasta que hay datos disponibles (menos solicitudes, mayor latencia). Ventajas de SSE: funciona a través de proxies y ofrece reconexión automática. Limitaciones de SSE: solo texto, unidireccional y con límites de conexiones en HTTP/1.1.