Long Polling: o que é, como funciona e onde é usado

O que é Long Polling

Long Polling é um padrão de comunicação em uma arquitetura cliente-servidor onde um cliente inicia uma solicitação HTTP e o servidor atrasa o envio de uma resposta até que novos dados estejam disponíveis ou um tempo limite especificado expire. Após receber a resposta, o cliente envia imediatamente a próxima solicitação, criando o efeito de uma conexão contínua.

A técnica Long Polling surgiu como uma evolução do Short Polling para reduzir o número de solicitações HTTP vazias. Na pesquisa tradicional, o cliente envia solicitações a cada N segundos e o servidor responde mesmo quando não há novos dados. No Long Polling, o servidor usa um mecanismo de retenção de conexão, o que reduz drasticamente o tráfego inútil.

História do Long Polling

Antes do advento do WebSocket em 2011, o Long Polling era o método principal para comunicação em tempo real na web. Empresas como Facebook e Gmail usaram esta técnica para seus chats e notificações no início dos anos 2010. De acordo com High Performance Browser Networking (Grigorik, 2013), o Long Polling lidava com até 95% de todas as conexões em tempo real nas principais aplicações web daquele período.

Princípio básico do Long Polling

Um cliente envia uma solicitação HTTP padrão ao servidor. Ao receber a solicitação, o servidor não retorna uma resposta imediatamente — ele coloca a solicitação em uma fila de espera. Quando ocorre um evento no servidor (uma nova mensagem, alteração de dados), o servidor forma uma resposta e a envia ao cliente. Ao receber a resposta, o cliente cria imediatamente uma nova solicitação Long Polling, e o ciclo se repete.

Como funciona o Long Polling

Long Polling funciona de acordo com a seguinte sequência de etapas. O cliente envia uma solicitação HTTP GET a um endpoint do servidor. Ao receber a solicitação, o servidor verifica se há novos dados na fila de eventos. Se não houver dados, o servidor mantém a solicitação em estado de espera, não enviando uma resposta imediatamente. O mecanismo de retenção depende da implementação do servidor — geralmente é usado processamento assíncrono com callbacks ou arquitetura orientada a eventos.

Quando ocorre um evento no lado do servidor (por exemplo, um usuário enviou uma mensagem em um chat), o servidor forma uma resposta HTTP com um corpo contendo esses dados e encerra a conexão. O cliente recebe a resposta, processa os dados e inicia imediatamente uma nova solicitação. Se nenhum dado aparecer durante o período de espera, o servidor envia uma resposta vazia após a expiração do tempo limite, e o cliente também restabelece a conexão. O tempo limite geralmente é de 30 a 60 segundos para equilibrar carga e latência.

Tempos limite e gerenciamento de conexão

Um parâmetro chave de configuração para Long Polling é o tempo limite de espera. Um tempo limite muito curto (menos de 10 segundos) aumenta o número de solicitações, aproximando a técnica do Short Polling. Um tempo limite muito longo (mais de 120 segundos) pode causar interrupção da conexão por proxies intermediários e balanceadores de carga. O valor recomendado para a maioria dos cenários é de 30 a 45 segundos.

Tratamento de múltiplos eventos

Se vários eventos ocorrerem no servidor durante uma única solicitação Long Polling, o servidor deve transmiti-los todos em uma resposta ou organizar uma fila de eventos no lado do cliente. Para isso, é usado o buffer de eventos: o servidor acumula os eventos que ocorreram durante o tempo de retenção da solicitação e os transmite como uma matriz de dados no corpo da resposta.

Exemplo de implementação de Long Polling em JavaScript

Vejamos uma implementação simples de Long Polling no lado do cliente usando a moderna Fetch API. A função do cliente envia uma solicitação e se chama recursivamente após receber uma resposta.

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

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

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

longPoll("/api/events");

Este código cria um loop infinito de Long Polling: após receber uma resposta, a função envia imediatamente uma nova solicitação. Em caso de erro de conexão, é definido um atraso de três segundos antes da nova tentativa para evitar uma carga de avalanche no servidor.

Implementação do servidor em Node.js

No lado do servidor, é necessário manter a solicitação até que um evento ocorra ou um tempo limite expire. Um exemplo de implementação usando EventEmitter em Node.js demonstra esse 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);

A parte do servidor usa EventEmitter para notificar as conexões Long Polling em espera quando novos dados aparecem. Ao atingir o tempo limite de 30 segundos, o servidor retorna uma matriz vazia de eventos, e o cliente cria uma nova solicitação.

Quando usar Long Polling

Long Polling é usado em cenários onde a entrega de dados em tempo real é necessária, mas o uso de WebSocket é impossível por razões técnicas ou de infraestrutura. Os casos mais comuns são proxies corporativos e firewalls que bloqueiam conexões WebSocket, bem como ambientes com suporte limitado de protocolo no lado do servidor.

• Chats e mensageiros — Long Polling fornece entrega de mensagens em versões web de mensageiros que operam via HTTP sem WebSocket.
• Painéis de monitoramento — sistemas em tempo real para métricas DevOps, logs e alertas onde a atualidade dos dados com atraso de 1 a 5 segundos é importante.
• Notificações — entrega tipo push de alertas no navegador sem usar Service Workers e Push API.
• Feeds de atividade — redes sociais e feeds de notícias com atualização automática de conteúdo quando novas publicações aparecem.
• Colaboração — editores tipo Google Docs com sincronização básica de alterações entre usuários.

O fator chave na escolha do Long Polling é a compatibilidade reversa. Todos os clientes e servidores HTTP suportam este método, tornando-o uma solução universal para funcionalidades em tempo real sem dependências adicionais. De acordo com HTTP Archive (2024), cerca de 8% de todos os sites continuam usando Long Polling para funcionalidades básicas em tempo real.

Long Polling vs Short Polling

Long Polling e Short Polling resolvem o mesmo problema — entrega de dados do servidor ao cliente — mas diferem fundamentalmente em mecanismo e eficiência. Short Polling usa um intervalo de pesquisa fixo onde o cliente envia solicitações HTTP em intervalos de tempo iguais, independentemente de novos dados terem aparecido no servidor.

Short Polling é mais simples de implementar, mas cria uma carga significativamente maior no servidor e na rede com a mesma frequência de atualização de dados. Se for necessária uma latência inferior a 5 segundos, o Short Polling gera dezenas de solicitações por minuto, enquanto o Long Polling usa uma solicitação por evento ou tempo limite. Para aplicações com eventos pouco frequentes, o Long Polling é muito mais eficiente em tráfego.

Long Polling vs WebSocket

WebSocket é um protocolo bidirecional completo em tempo real que opera sobre TCP após um handshake HTTP inicial. Ao contrário do Long Polling, o WebSocket estabelece uma única conexão persistente e permite que o servidor envie dados ao cliente a qualquer momento sem criar uma nova solicitação HTTP.

A escolha entre Long Polling e WebSocket depende de vários fatores. Compatibilidade: Long Polling funciona através de qualquer proxy e firewall, enquanto o WebSocket pode ser bloqueado por redes corporativas. Desempenho: WebSocket tem menor sobrecarga (2 bytes por frame contra cabeçalhos HTTP completos), o que é crítico em alta frequência de mensagens. Escalabilidade: Long Polling requer mais recursos no lado do servidor devido à retenção de múltiplas conexões, enquanto o WebSocket usa uma conexão fixa por sessão.

• Long Polling — a melhor escolha para aplicações com baixa frequência de eventos (1–10 eventos por minuto), infraestrutura limitada ou necessidade de suportar navegadores antigos.
• WebSocket — a solução ótima para aplicações em tempo real de alta carga (dados de bolsa, jogos online, editores colaborativos) com centenas de mensagens por segundo.
• Abordagem híbrida — algumas aplicações usam Long Polling como fallback para clientes que não suportam WebSocket, com comutação automática de protocolo.

De acordo com Mozilla Developer Network (2024), WebSocket é suportado por todos os navegadores modernos desde as versões 2011–2015, mas proxies corporativos (por exemplo, Symantec Blue Coat) continuam bloqueando-o em 15–20% das redes corporativas, o que mantém o Long Polling relevante como solução de fallback.