Long Polling: ce este, cum funcționează și unde se utilizează

Ce este Long Polling

Long Polling este un model de interacțiune în arhitectura client-server în care clientul inițiază o cerere HTTP, iar serverul amână trimiterea răspunsului până când apar date noi sau expiră un timeout specificat. După primirea răspunsului, clientul trimite imediat următoarea cerere, creând efectul unei conexiuni continue.

Tehnica Long Polling a apărut ca o dezvoltare evolutivă a Short Polling pentru reducerea numărului de cereri HTTP goale. În interogarea tradițională, clientul trimite cereri la fiecare N secunde, iar serverul răspunde chiar și în absența datelor noi. În Long Polling, serverul utilizează un mecanism de menținere a conexiunii, ceea ce reduce radical volumul de trafic inutil.

Istoria apariției Long Polling

Înainte de apariția WebSocket în 2011, Long Polling era principala metodă de organizare a timpului real în web. Companii precum Facebook și Gmail au folosit această tehnică pentru chat-urile și notificările lor la începutul anilor 2010. Potrivit cercetării High Performance Browser Networking (Grigorik, 2013), Long Polling procesa până la 95% din toate conexiunile în timp real în aplicațiile web mari ale acelei perioade.

Principiul de bază al Long Polling

Clientul trimite o cerere HTTP standard către server. Serverul, după primirea cererii, nu returnează imediat răspunsul — plasează cererea într-o coadă de așteptare. Când pe server are loc un eveniment (mesaj nou, modificare de date), serverul formează răspunsul și îl trimite clientului. Clientul, după primirea răspunsului, creează imediat o nouă cerere Long Polling, iar ciclul se repetă.

Cum funcționează Long Polling

Long Polling funcționează conform următoarei secvențe de pași. Clientul trimite o cerere HTTP GET către endpoint-ul serverului. Serverul, după primirea cererii, verifică disponibilitatea datelor noi în coada de evenimente. Dacă nu există date, serverul menține cererea în stare de așteptare, fără a trimite imediat răspunsul. Mecanismul de menținere depinde de implementarea serverului — cel mai des se utilizează procesarea asincronă cu callback-uri sau arhitectura bazată pe evenimente.

Când pe partea serverului are loc un eveniment (de exemplu, utilizatorul a trimis un mesaj în chat), serverul formează un răspuns HTTP cu corpul ce conține aceste date și încheie conexiunea. Clientul primește răspunsul, procesează datele și inițiază imediat o nouă cerere. Dacă în timpul așteptării nu au apărut date, serverul trimite un răspuns gol la expirarea timeout-ului, iar clientul reia conexiunea. Timeout-ul este de obicei de 30–60 de secunde pentru un echilibru între încărcare și întârziere.

Timeout-uri și gestionarea conexiunii

Parametrul cheie al configurării Long Polling este timeout-ul de așteptare. Un timeout prea scurt (sub 10 secunde) duce la creșterea numărului de cereri, apropiind tehnica de Short Polling. Un timeout prea lung (peste 120 de secunde) poate cauza întreruperea conexiunii de către proxy-urile intermediare și balansoarele de sarcină. Valoarea recomandată pentru majoritatea scenariilor este de 30–45 de secunde.

Gestionarea evenimentelor multiple

Dacă pe server au avut loc mai multe evenimente în timpul unei singure cereri Long Polling, serverul trebuie să le transmită pe toate într-un singur răspuns sau să organizeze o coadă de evenimente pe partea clientului. În acest scop se utilizează bufferizarea evenimentelor: serverul acumulează evenimentele care au avut loc în timpul menținerii cererii și le transmite ca un tablou de date în corpul răspunsului.

Exemplu de implementare Long Polling în JavaScript

Să analizăm o implementare simplă a Long Polling pe partea clientului folosind Fetch API modern. Funcția client trimite o cerere și se autoapelează recursiv după primirea răspunsului.

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

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

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

longPoll("/api/events");

Acest cod creează o buclă infinită Long Polling: după primirea răspunsului, funcția trimite imediat o nouă cerere. În caz de eroare de conexiune, se stabilește o întârziere de trei secunde înainte de reîncercare, pentru a evita o încărcare în avalanșă a serverului.

Implementare server în Node.js

Pe partea serverului, este necesar să se mențină cererea până la apariția evenimentului sau expirarea timeout-ului. Un exemplu de implementare folosind EventEmitter în Node.js demonstrează acest mecanism.

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);

Partea server utilizează EventEmitter pentru a notifica conexiunile Long Polling în așteptare la apariția datelor noi. La atingerea timeout-ului de 30 de secunde, serverul returnează un tablou gol de evenimente, iar clientul creează o nouă cerere.

Când se aplică Long Polling

Long Polling se aplică în scenarii care necesită livrarea datelor în timp real, dar unde utilizarea WebSocket este imposibilă din motive tehnice sau de infrastructură. Cele mai frecvente cazuri — proxy-uri corporative și firewall-uri care blochează conexiunile WebSocket, precum și medii cu suport limitat al protocolului pe partea serverului.

• Chaturi și mesagerie — Long Polling asigură livrarea mesajelor în versiunile web ale mesagerelor care funcționează prin HTTP fără WebSocket.
• Panouri de monitorizare — sisteme în timp real pentru metrici DevOps, loguri și alerte, unde actualitatea datelor cu o întârziere de 1–5 secunde este importantă.
• Notificări — livrarea notificărilor în browser fără utilizarea Service Workers și Push API.
• Feeduri de activitate — rețele sociale și feeduri de știri cu actualizare automată a conținutului la apariția noilor intrări.
• Lucru colaborativ — editoare de tip Google Docs cu sincronizare de bază a modificărilor între utilizatori.

Factorul cheie al alegerii Long Polling este compatibilitatea inversă. Toți clienții și serverele HTTP suportă această metodă, ceea ce o face o soluție universală pentru timp real fără dependențe suplimentare. Potrivit HTTP Archive (2024), aproximativ 8% din toate site-urile web continuă să utilizeze Long Polling pentru funcționalitatea de bază în timp real.

Long Polling vs Short Polling

Long Polling și Short Polling rezolvă aceeași sarcină — livrarea datelor de la server la client — dar diferă fundamental prin mecanism și eficiență. Short Polling utilizează un interval fix de interogare, în care clientul trimite cereri HTTP la intervale egale, indiferent dacă pe server au apărut date noi.

Short Polling este mai simplu de implementat, dar generează o încărcare semnificativ mai mare asupra serverului și rețelei la aceeași frecvență de actualizare a datelor. Dacă se necesită o întârziere mai mică de 5 secunde, Short Polling generează zeci de cereri pe minut, în timp ce Long Polling utilizează o cerere per eveniment sau timeout. Pentru aplicații cu evenimente rare, Long Polling este cu un ordin de mărime mai eficient din punct de vedere al traficului.

Long Polling vs WebSocket

WebSocket este un protocol bidirecțional complet în timp real, care funcționează pe TCP după o strângere de mână HTTP inițială. Spre deosebire de Long Polling, WebSocket stabilește o singură conexiune permanentă și permite serverului să trimită date clientului în orice moment fără a crea o nouă cerere HTTP.

Alegerea între Long Polling și WebSocket depinde de mai mulți factori. Compatibilitatea: Long Polling funcționează prin orice proxy și firewall, WebSocket poate fi blocat de rețelele corporative. Performanța: WebSocket are un overhead mai mic (2 octeți per cadru față de antetele HTTP complete), ceea ce este critic la frecvența ridicată a mesajelor. Scalabilitatea: Long Polling necesită mai multe resurse pe partea serverului din cauza menținerii multiplelor conexiuni, WebSocket utilizează o conexiune fixă per sesiune.

• Long Polling — cea mai bună alegere pentru aplicații cu frecvență scăzută a evenimentelor (1–10 evenimente pe minut), infrastructură limitată sau necesitatea de a suporta browsere vechi.
• WebSocket — soluția optimă pentru aplicații în timp real cu încărcare mare (date bursiere, jocuri online, editoare colaborative) cu sute de mesaje pe secundă.
• Abordarea hibridă — unele aplicații utilizează Long Polling ca fallback pentru clienții care nu suportă WebSocket, cu comutarea automată a protocolului.

Potrivit Mozilla Developer Network (2024), WebSocket este suportat de toate browserele moderne începând cu versiunile 2011–2015, dar proxy-urile corporative (de exemplu, Symantec Blue Coat) continuă să îl blocheze în 15–20% din rețelele corporative, ceea ce menține relevanța Long Polling ca soluție fallback.