WebSockets, Long Polling y SSE: cómo funciona el intercambio de datos en tiempo real

Chaats, notificaciones, cotizaciones bursátiles, edición colaborativa, respuestas de redes neuronales que aparecen por palabras — todo esto requiere que el servidor transmita datos al cliente de inmediato, sin nuevas solicitudes repetidas. HTTP está diseñado originalmente de otra manera: el cliente pregunta, el servidor responde. Para el intercambio en tiempo real sobre él se utilizan tres enfoques: Long Polling, Server-Sent Events (SSE) y WebSockets.

Long Polling

Long Polling — técnica, no un protocolo separado. El cliente envía una petición HTTP normal, y el servidor no responde de inmediato, sino que mantiene la petición abierta hasta que haya datos o hasta que caduque el tiempo de espera. Al recibir la respuesta, el cliente envía inmediatamente la siguiente petición.

Ventajas:

• funciona en cualquier lugar donde funcione HTTP: a través de cualquier proxy, cortafuegos y navegadores antiguos;
• no requiere nada especial en el servidor ni en el balanceador.

Desventajas:

• cada mensaje implica una petición HTTP completa con cabeceras;
• entre la respuesta y la nueva petición existe una ventana en la que el evento puede retrasarse;
• miles de peticiones en espera cargan el servidor si atiende cada petición con un proceso o hilo separado.

Hoy en día Long Polling se usa como alternativa de reserva si otros métodos no están disponibles.

Server-Sent Events (SSE)

SSE — mecanismo estándar del navegador para la transmisión unidireccional de eventos del servidor al cliente. El cliente abre una conexión HTTP normal, el servidor responde con el tipo text/event-stream y no la cierra, sino que envía eventos a medida que aparecen.

En el navegador existe el objeto incorporado EventSource:

const events = new EventSource("/api/events");

events.onmessage = (e) => {
  console.log("Nuevo evento:", e.data);
};

events.addEventListener("order-status", (e) => {
  console.log("Estado del pedido:", e.data);
});

Ventajas:

• HTTP normal: no se necesita un protocolo separado ni una configuración especial del balanceador;
• el navegador vuelve a conectarse automáticamente en caso de desconexión;
• se admiten eventos con nombre.

Limitaciones:

• solo del servidor al cliente; para enviar datos al servidor el cliente hace peticiones normales;
• solo texto;
• con HTTP/1.1 el navegador mantiene como máximo 6 conexiones simultáneas con un mismo dominio, y cada pestaña abierta con SSE ocupa una de ellas. Con HTTP/2 los eventos van en flujos separados de una misma conexión y este problema desaparece.

SSE es una buena elección para notificaciones, feeds de eventos, indicadores de progreso de tareas y respuestas por streaming de redes neuronales.

WebSockets

WebSocket (RFC 6455, 2011) — protocolo independiente con intercambio bidireccional sobre una única conexión persistente.

La conexión comienza como una petición HTTP normal con las cabeceras Upgrade: websocket y Sec-WebSocket-Key. El servidor responde con el código 101 Switching Protocols, y a partir de ahí por la misma conexión TCP ambas partes intercambian frames — textuales o binarios. Las direcciones tienen la forma ws:// (puerto 80) y wss:// (puerto 443, con TLS). Para verificar la conexión el protocolo prevé frames de control ping y pong.

Ventajas:

• intercambio en ambas direcciones sin nuevas peticiones;
• gastos generales mínimos por mensaje;
• soporte de datos binarios.

Particularidades:

• la conexión vive mucho tiempo, por lo que es necesario configurar proxies y balanceadores para que no la corten;
• la reconexión, la confirmación de entrega y la recuperación de mensajes perdidos las implementa la aplicación — el navegador no lo hace;
• cada conexión abierta ocupa recursos del servidor, por lo que con un gran número de clientes se necesita un servidor diseñado para muchas conexiones simultáneas.

WebSocket sobre HTTP/2

Inicialmente WebSocket funcionaba solo sobre HTTP/1.1. RFC 8441 (septiembre de 2018) describe el lanzamiento de WebSocket dentro de un flujo HTTP/2: el servidor anuncia soporte con el parámetro SETTINGS_ENABLE_CONNECT_PROTOCOL, y el cliente abre un flujo con el método extendido CONNECT y el pseudocabecero :protocol: websocket. Así la conexión WebSocket y las peticiones normales transitan por una única conexión TCP. Si esto funciona en su stack depende del navegador, del proxy y de la aplicación — por defecto la mayoría de proxies todavía enruta WebSocket a través de HTTP/1.1.

Qué elegir

Muchas bibliotecas (por ejemplo, Socket.IO) eligen automáticamente el mejor transporte disponible y vuelven a Long Polling si WebSocket no está disponible.

Proxies y balanceadores

La configuración en el proxy es necesaria en dos puntos: el paso de cabeceras de actualización para WebSocket y los timeouts de conexiones largas.

• Nginx. Las cabeceras Upgrade y Connection no se pasan a la aplicación automáticamente; se deben establecer explícitamente; por defecto nginx cierra la conexión si no hay datos durante 60 segundos, y para SSE hay que desactivar el buffer de respuesta. Una configuración funcional con un bloque map y el manejo de errores — en el artículo «Proxies: Parte 2 — Nginx».
• HAProxy. WebSocket está soportado sin módulos adicionales, pero se necesita la directiva timeout tunnel, de lo contrario las conexiones se cierran por los timeouts habituales. Ejemplo — en el artículo «Proxies: Parte 3 — HAProxy».
• Caddy. La directiva reverse_proxy proxyfica WebSocket sin configuración adicional, y envía respuestas con tipo text/event-stream al cliente inmediatamente, sin buffering. Al recargar la configuración las conexiones WebSocket se cierran por defecto; este comportamiento se cambia con los parámetros stream_timeout y stream_close_delay.

Errores típicos

• La conexión se corta exactamente al cabo de un minuto. Ha actuado el timeout del proxy para conexiones inactivas. Aumente el timeout y envíe ping desde la aplicación.
• Los eventos SSE llegan agrupados al final. El proxy está haciendo buffering de la respuesta. Desactive el buffering para esa ruta.
• WebSocket funciona localmente, pero no detrás del balanceador. No se pasaron las cabeceras Upgrade y Connection, o el balanceador reparte las peticiones de un mismo cliente entre distintos servidores y la aplicación guarda estado en memoria. Hace falta pegar al cliente a un servidor (session affinity) o un almacenamiento de estado compartido.
• Mensajes perdidos después de la reconexión. El protocolo no lo garantiza: la aplicación necesita identificadores de mensajes y reenvío.