Long Polling: qué es, cómo funciona y dónde se utiliza

Qué es Long Polling

Long Polling es un patrón de comunicación en una arquitectura cliente-servidor donde un cliente inicia una solicitud HTTP y el servidor retrasa el envío de una respuesta hasta que nuevos datos estén disponibles o expire un tiempo de espera especificado. Después de recibir la respuesta, el cliente envía inmediatamente la siguiente solicitud, creando el efecto de una conexión continua.

La técnica de Long Polling surgió como una evolución de Short Polling para reducir la cantidad de solicitudes HTTP vacías. En el sondeo tradicional, el cliente envía solicitudes cada N segundos y el servidor responde incluso cuando no hay nuevos datos. En Long Polling, el servidor utiliza un mecanismo de retención de conexión, lo que reduce drásticamente el tráfico inútil.

Historia de Long Polling

Antes de la llegada de WebSocket en 2011, Long Polling era el método principal para la comunicación en tiempo real en la web. Empresas como Facebook y Gmail utilizaron esta técnica para sus chats y notificaciones a principios de la década de 2010. Según High Performance Browser Networking (Grigorik, 2013), Long Polling manejaba hasta el 95% de todas las conexiones en tiempo real en las principales aplicaciones web de ese período.

Principio básico de Long Polling

Un cliente envía una solicitud HTTP estándar al servidor. Al recibir la solicitud, el servidor no devuelve una respuesta de inmediato, sino que coloca la solicitud en una cola de espera. Cuando ocurre un evento en el servidor (un nuevo mensaje, cambio de datos), el servidor forma una respuesta y la envía al cliente. Al recibir la respuesta, el cliente crea inmediatamente una nueva solicitud Long Polling y el ciclo se repite.

Cómo funciona Long Polling

Long Polling funciona según la siguiente secuencia de pasos. El cliente envía una solicitud HTTP GET a un endpoint del servidor. Al recibir la solicitud, el servidor verifica si hay nuevos datos en la cola de eventos. Si no hay datos, el servidor mantiene la solicitud en estado de espera, sin enviar una respuesta de inmediato. El mecanismo de retención depende de la implementación del servidor; generalmente se utiliza procesamiento asíncrono con callbacks o arquitectura basada en eventos.

Cuando ocurre un evento en el lado del servidor (por ejemplo, un usuario envió un mensaje en un chat), el servidor forma una respuesta HTTP con un cuerpo que contiene estos datos y finaliza la conexión. El cliente recibe la respuesta, procesa los datos e inicia inmediatamente una nueva solicitud. Si no aparecen datos durante el período de espera, el servidor envía una respuesta vacía después de que expire el tiempo de espera, y el cliente también restablece la conexión. El tiempo de espera suele ser de 30 a 60 segundos para equilibrar la carga y la latencia.

Tiempos de espera y gestión de conexiones

Un parámetro clave de configuración para Long Polling es el tiempo de espera. Un tiempo de espera demasiado corto (menos de 10 segundos) aumenta el número de solicitudes, acercando la técnica a Short Polling. Un tiempo de espera demasiado largo (más de 120 segundos) puede provocar la interrupción de la conexión por parte de proxies intermedios y balanceadores de carga. El valor recomendado para la mayoría de los escenarios es de 30 a 45 segundos.

Manejo de eventos múltiples

Si ocurren varios eventos en el servidor durante una sola solicitud Long Polling, el servidor debe transmitirlos todos en una respuesta u organizar una cola de eventos en el lado del cliente. Para ello, se utiliza el almacenamiento en búfer de eventos: el servidor acumula los eventos que ocurrieron durante el tiempo de retención de la solicitud y los transmite como una matriz de datos en el cuerpo de la respuesta.

Ejemplo de implementación de Long Polling en JavaScript

Veamos una implementación simple de Long Polling en el lado del cliente usando la moderna Fetch API. La función del cliente envía una solicitud y se llama recursivamente después de recibir una respuesta.

async function longPoll(url) {
    try {
        const response = await fetch(url);
        const data = await response.json();

        handleData(data);
        longPoll(url);
    } catch (error) {
        console.error("Error de Long Polling", error);
        setTimeout(() => longPoll(url), 3000);
    }
}

function handleData(data) {
    if (data.events && data.events.length > 0) {
        data.events.forEach(event => {
            console.log("Nuevo evento:", event);
        });
    }
}

longPoll("/api/events");

Este código crea un bucle infinito de Long Polling: después de recibir una respuesta, la función envía inmediatamente una nueva solicitud. En caso de error de conexión, se establece un retraso de tres segundos antes de reintentar para evitar una carga de avalancha en el servidor.

Implementación del servidor en Node.js

En el lado del servidor, es necesario mantener la solicitud hasta que ocurra un evento o expire un tiempo de espera. Un ejemplo de implementación usando EventEmitter en Node.js demuestra este mecanismo.

const express = require("express");
const EventEmitter = require("events");
const app = express();

const eventBus = new EventEmitter();

app.get("/api/events", (req, res) => {
    const timeout = setTimeout(() => {
        res.json({ events: [] });
    }, 30000);

    eventBus.once("new-event", (data) => {
        clearTimeout(timeout);
        res.json({ events: [data] });
    });
});

app.post("/api/events", (req, res) => {
    eventBus.emit("new-event", req.body);
    res.send({ status: "ok" });
});

app.listen(3000);

La parte del servidor usa EventEmitter para notificar a las conexiones Long Polling en espera cuando aparecen nuevos datos. Al alcanzar el tiempo de espera de 30 segundos, el servidor devuelve un array vacío de eventos y el cliente crea una nueva solicitud.

Cuándo se usa Long Polling

Long Polling se utiliza en escenarios donde se requiere la entrega de datos en tiempo real, pero el uso de WebSocket es imposible por razones técnicas o de infraestructura. Los casos más comunes son proxies corporativos y firewalls que bloquean las conexiones WebSocket, así como entornos con soporte limitado del protocolo en el lado del servidor.

• Chats y mensajería — Long Polling proporciona entrega de mensajes en versiones web de mensajería que funcionan a través de HTTP sin WebSocket.
• Paneles de monitoreo — sistemas en tiempo real para métricas DevOps, registros y alertas donde la actualidad de los datos con un retraso de 1 a 5 segundos es importante.
• Notificaciones — entrega tipo push de alertas en el navegador sin usar Service Workers ni Push API.
• Feeds de actividad — redes sociales y feeds de noticias con actualización automática de contenido cuando aparecen nuevas publicaciones.
• Colaboración — editores tipo Google Docs con sincronización básica de cambios entre usuarios.

El factor clave para elegir Long Polling es la compatibilidad hacia atrás. Todos los clientes y servidores HTTP admiten este método, lo que lo convierte en una solución universal para funcionalidades en tiempo real sin dependencias adicionales. Según HTTP Archive (2024), aproximadamente el 8% de todos los sitios web continúan usando Long Polling para funcionalidades básicas en tiempo real.

Long Polling vs Short Polling

Long Polling y Short Polling resuelven el mismo problema (entrega de datos del servidor al cliente), pero difieren fundamentalmente en mecanismo y eficiencia. Short Polling utiliza un intervalo de sondeo fijo donde el cliente envía solicitudes HTTP a intervalos de tiempo iguales independientemente de si han aparecido nuevos datos en el servidor.

Short Polling es más simple de implementar, pero crea una carga significativamente mayor en el servidor y la red con la misma frecuencia de actualización de datos. Si se requiere una latencia inferior a 5 segundos, Short Polling genera docenas de solicitudes por minuto, mientras que Long Polling utiliza una solicitud por evento o tiempo de espera. Para aplicaciones con eventos poco frecuentes, Long Polling es mucho más eficiente en tráfico.

Long Polling vs WebSocket

WebSocket es un protocolo bidireccional completo en tiempo real que funciona sobre TCP después de un protocolo de enlace HTTP inicial. A diferencia de Long Polling, WebSocket establece una única conexión persistente y permite al servidor enviar datos al cliente en cualquier momento sin crear una nueva solicitud HTTP.

La elección entre Long Polling y WebSocket depende de varios factores. Compatibilidad: Long Polling funciona a través de cualquier proxy y firewall, mientras que WebSocket puede estar bloqueado por redes corporativas. Rendimiento: WebSocket tiene menor sobrecarga (2 bytes por frame frente a encabezados HTTP completos), lo que es crítico con alta frecuencia de mensajes. Escalabilidad: Long Polling requiere más recursos del lado del servidor debido a la retención de múltiples conexiones, mientras que WebSocket usa una conexión fija por sesión.

• Long Polling — la mejor opción para aplicaciones con baja frecuencia de eventos (1–10 eventos por minuto), infraestructura limitada o necesidad de soportar navegadores antiguos.
• WebSocket — la solución óptima para aplicaciones en tiempo real de alta carga (datos bursátiles, juegos en línea, editores colaborativos) con cientos de mensajes por segundo.
• Enfoque híbrido — algunas aplicaciones usan Long Polling como respaldo para clientes que no admiten WebSocket, con cambio automático de protocolo.

Según Mozilla Developer Network (2024), WebSocket es compatible con todos los navegadores modernos desde las versiones 2011–2015, pero los proxies corporativos (por ejemplo, Symantec Blue Coat) continúan bloqueándolo en el 15–20% de las redes corporativas, lo que mantiene la relevancia de Long Polling como solución de respaldo.