Long-Polling

Definition

¿Alguna vez has estado esperando un paquete importante y no parabas de asomarte a la puerta cada pocos minutos? Frustrante e ineficiente, ¿verdad? Long-polling resuelve un problema similar en el mundo digital. En lugar de que tu aplicación esté constantemente preguntando al servidor “¿hay algo nuevo? ¿hay algo nuevo? ¿hay algo nuevo?” cada segundo (lo que malgasta recursos y ancho de banda), long-polling le da la vuelta a la tortilla.

Funciona así: tu aplicación envía una petición al servidor pidiendo actualizaciones, pero en lugar de que el servidor responda inmediatamente “no, todavía nada”, mantiene esa petición abierta y espera. El servidor mantiene la conexión abierta, escuchando pacientemente a que ocurra algo interesante. En el momento en que llegan datos nuevos - quizás un mensaje de chat, una notificación o un cambio en el precio de una acción - el servidor lo envía inmediatamente a tu aplicación. Si no pasa nada después de un tiempo establecido (digamos 30 segundos), el servidor finalmente responde “sigue sin haber nada” y tu aplicación inicia una nueva petición.

Esta técnica ocupa un punto intermedio entre el polling regular (comprobaciones constantes e ineficientes) y los WebSockets (más complejos de implementar). Long-polling te da actualizaciones casi en tiempo real sin requerir los cambios de infraestructura que demandan los WebSockets. Funciona con HTTP estándar, atraviesa la mayoría de firewalls y proxies sin problemas, y está soportado en todas partes. Para muchas aplicaciones, es el equilibrio perfecto entre simplicidad y capacidad de respuesta.

Example

Long-polling está en todas partes, aunque no lo notes. Aquí tienes algunos escenarios del mundo real donde probablemente lo has experimentado:

Aplicaciones de Chat: Cuando estás esperando un mensaje en una aplicación de chat web como las versiones antiguas de Facebook Messenger o el cliente web de Slack, long-polling te mantiene conectado. Tu navegador pregunta “¿algún mensaje nuevo?” y el servidor espera hasta que alguien realmente te envíe algo antes de responder. Por eso los mensajes parecen aparecer al instante aunque estés usando HTTP normal y corriente.

Resultados Deportivos en Vivo: Los sitios web de deportes que muestran resultados en directo suelen usar long-polling. Cuando estás viendo un partido de fútbol y el marcador se actualiza segundos después de un gol, probablemente long-polling está detrás. La página mantiene una conexión abierta, esperando a que cambie el marcador, en lugar de refrescarse cada pocos segundos y perderse la acción.

Notificaciones de Email: La interfaz web de Gmail históricamente usaba long-polling para mostrar nuevos correos. Cuando alguien te envía un email, aparece en tu bandeja de entrada casi inmediatamente sin que tengas que pulsar actualizar. El navegador mantiene una petición en espera que cobra vida en el momento en que llega correo nuevo.

Documentos Colaborativos: Las primeras versiones de Google Docs usaban long-polling para mostrar cuándo los colaboradores estaban editando. Los movimientos del cursor y cambios de texto de otros usuarios aparecían suavemente porque el servidor mantenía conexiones abiertas, listo para enviar actualizaciones en el instante en que ocurrían.

Sitios de Subastas: En eBay o plataformas de subastas similares, long-polling ayuda a mostrar actualizaciones de pujas en tiempo real. Cuando alguien te supera la puja en los últimos segundos, lo ves inmediatamente porque el servidor estaba manteniendo la petición de tu navegador, esperando exactamente ese evento.

Analogía

El Bibliotecario Paciente: Imagina que estás en una biblioteca y le has pedido al bibliotecario que te avise cuando un libro específico esté disponible. En lugar de volver cada 5 minutos a preguntar (molesto para todos), el bibliotecario dice “Lo vigilaré - siéntate a leer, y te buscaré en el momento en que lo devuelvan.” Eres libre de hacer otras cosas, y en el instante en que alguien devuelve ese libro, el bibliotecario te da un toque en el hombro. Eso es long-polling: el servidor (bibliotecario) mantiene tu petición y solo responde cuando realmente tiene algo que contarte.

El Avisador del Restaurante: Cuando estás esperando mesa en un restaurante lleno, te dan uno de esos aparatos que vibran. No te quedas en la entrada preguntando “¿está mi mesa lista?” cada minuto. En su lugar, coges el avisador, te vas a dar una vuelta, y en el momento en que tu mesa está libre, vibra. Long-polling funciona igual - tu aplicación “mantiene” una conexión (como sostener el avisador), y el servidor solo “vibra” cuando pasa algo importante.

La Caña de Pescar: Piensa en long-polling como pescar. Lanzas tu sedal al agua (envías una petición) y luego esperas pacientemente. No estás constantemente recogiendo el hilo y volviendo a lanzar cada pocos segundos - eso espantaría a los peces y te agotaría. En su lugar, dejas el sedal en el agua, alerta y preparado. En el momento en que un pez muerde (llegan datos nuevos), lo notas inmediatamente y puedes reaccionar. Si nada muerde después de un rato, recoges y vuelves a lanzar (timeout y nueva petición).

La Radio del Guardia de Seguridad: Imagina un guardia de seguridad con un walkie-talkie. Cuando pulsa el botón para comunicarse, no cuelga inmediatamente si no hay respuesta. Mantiene la línea abierta durante un tiempo razonable, escuchando cualquier respuesta de la central. Si algo pasa en la base, se entera inmediatamente. Si todo sigue en calma durante demasiado tiempo, suelta el botón y lo intenta más tarde. Ese canal de comunicación mantenido abierto es exactamente lo que hace long-polling.

Diagrama

sequenceDiagram
    participant C as Cliente
    participant S as Servidor

    C->>S: GET /api/poll
    Note over S: Mantiene conexión...
esperando datos
    Note over S: Aún esperando...
    Note over S: ¡Llegan datos!
    S->>C: 200 OK {"mensaje": "¡Datos nuevos!"}

    Note over C: Reconecta inmediatamente

    C->>S: GET /api/poll
    Note over S: Mantiene conexión...
esperando datos
    Note over S: Aún esperando...
    Note over S: Timeout (30s)
    S->>C: 200 OK (sin datos)

    Note over C: Reconecta inmediatamente

    C->>S: GET /api/poll
    Note over S: Mantiene conexión...
    Note over S: ¡Llegan datos!
    S->>C: 200 OK {"mensaje": "¡Actualización!"}

    Note over C,S: El servidor mantiene la petición
hasta que hay datos o timeout

Code Example

// Client-side long-polling
async function longPoll() {
  try {
    const response = await fetch('/api/messages/poll', {
      method: 'GET',
      headers: { 'Content-Type': 'application/json' },
      // Server holds connection for up to 30s
    });

    const data = await response.json();
    if (data.messages) {
      processMessages(data.messages);
    }
  } catch (error) {
    console.error('Poll error:', error);
  }

  // Immediately poll again
  longPoll();
}

longPoll();

Notas de Seguridad

Standards & RFCs