Long Polling: mi ez, hogyan működik és hol használják

Mi az a Long Polling

Long Polling egy interakciós minta a kliens-szerver architektúrában, ahol a kliens HTTP-kérést indít, a szerver pedig késlelteti a válasz küldését addig, amíg új adatok meg nem jelennek vagy egy meghatározott timeout le nem jár. A válasz kézhezvétele után a kliens azonnal elküldi a következő kérést, létrehozva a folyamatos kapcsolat hatását.

A Long Polling technika a Short Polling evolúciós fejlődéseként jelent meg az üres HTTP-kérések számának csökkentésére. A hagyományos lekérdezésnél a kliens minden N másodpercben kéréseket küld, és a szerver válaszol még új adatok hiányában is. A Long Pollingnál a szerver egy kapcsolat tartó mechanizmust használ, ami radikálisan csökkenti a haszontalan forgalom mennyiségét.

A Long Polling kialakulásának története

A WebSocket 2011-es megjelenése előtt a Long Polling volt a valós idejű szervezés fő módja a weben. Olyan cégek, mint a Facebook és a Gmail, ezt a technikát használták chatekhez és értesítésekhez a 2010-es évek elején. A High Performance Browser Networking (Grigorik, 2013) kutatás szerint a Long Polling az akkori nagy webes alkalmazásokban a valós idejű kapcsolatok akár 95%-át is feldolgozta.

A Long Polling alapelve

A kliens szabványos HTTP-kérést küld a szervernek. A szerver a kérés kézhezvétele után nem küld azonnal választ — várakozási sorba helyezi a kérést. Amikor a szerveren esemény történik (új üzenet, adatváltozás), a szerver választ képez és elküldi a kliensnek. A kliens a válasz kézhezvétele után azonnal új Long Polling kérést hoz létre, és a ciklus megismétlődik.

Hogyan működik a Long Polling

Long Polling a következő lépéssorozat szerint működik. A kliens HTTP GET kérést küld a szerver végpontjára. A szerver a kérés kézhezvétele után ellenőrzi az új adatok elérhetőségét az eseménysorban. Ha nincs adat, a szerver várakozó állapotban tartja a kérést, nem küld azonnal választ. A tartási mechanizmus a szerver implementációjától függ — leggyakrabban aszinkron feldolgozást használnak callbackekkel vagy eseményvezérelt architektúrát.

Amikor a szerver oldalán esemény történik (például a felhasználó üzenetet küldött a chatben), a szerver HTTP-választ képez az adatokat tartalmazó törzzsel és befejezi a kapcsolatot. A kliens megkapja a választ, feldolgozza az adatokat, és azonnal új kérést indít. Ha a várakozás ideje alatt nem jelentek meg adatok, a szerver a timeout lejárta után üres választ küld, és a kliens szintén újrakapcsolódik. A timeout általában 30-60 másodperc a terhelés és késleltetés közötti egyensúly érdekében.

Időtúllépések és kapcsolatkezelés

A Long Polling konfiguráció kulcsparamétere a várakozási időtúllépés (timeout). Túl rövid timeout (kevesebb mint 10 másodperc) a kérések számának növekedéséhez vezet, közelítve a technikát a Short Pollinghoz. Túl hosszú (több mint 120 másodperc) a kapcsolat megszakadását okozhatja a köztes proxyk és terheléselosztók által. Az ajánlott érték a legtöbb forgatókönyvhöz 30-45 másodperc.

Több esemény kezelése

Ha a szerveren több esemény történt egy Long Polling kérés alatt, a szervernek mindet egy válaszban kell átadnia, vagy eseménysort kell szerveznie a kliens oldalán. Ehhez eseménypufferelést használnak: a szerver összegyűjti a kérés tartása alatt történt eseményeket, és adattömegként adja át őket a válasz törzsében.

Long Polling implementáció példa JavaScriptben

Tekintsünk egy egyszerű Long Polling implementációt a kliens oldalán a modern Fetch API használatával. A kliens függvény kérést küld, és a válasz kézhezvétele után rekurzívan meghívja önmagát.

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

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

function handleData(data) {
    if (data.events && data.events.length > 0) {
        data.events.forEach(event => {
            console.log("Új esemény:", event);
        });
    }
}

longPoll("/api/events");

Ez a kód egy végtelen Long Polling ciklust hoz létre: a válasz kézhezvétele után a függvény azonnal új kérést küld. Kapcsolati hiba esetén három másodperces késleltetés kerül beállításra az újrapróbálkozás előtt, hogy elkerülje a szerver lavinaszerű terhelését.

Szerver oldali implementáció Node.js-ben

A szerver oldalán a kérést addig kell tartani, amíg esemény meg nem jelenik vagy a timeout le nem jár. Egy EventEmitter használatával készült implementációs példa Node.js-ben bemutatja ezt a mechanizmust.

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 szerver rész az EventEmitteret használja a várakozó Long Polling kapcsolatok értesítésére új adatok megjelenésekor. A 30 másodperces timeout elérésekor a szerver egy üres eseménytömböt ad vissza, és a kliens új kérést hoz létre.

Mikor alkalmazzák a Long Pollingot

Long Polling olyan forgatókönyvekben alkalmazzák, ahol valós idejű adatszolgáltatásra van szükség, de a WebSocket használata technikai vagy infrastrukturális okokból lehetetlen. A leggyakoribb esetek — vállalati proxyk és tűzfalak, amelyek blokkolják a WebSocket kapcsolatokat, valamint a szerver oldali korlátozott protokolltámogatással rendelkező környezetek.

• Chat és üzenetküldők — a Long Polling biztosítja az üzenetek kézbesítését a WebSocket nélkül, HTTP-n keresztül működő üzenetküldők webes verzióiban.
• Monitorozó panelek — valós idejű rendszerek DevOps metrikákhoz, naplókhoz és riasztásokhoz, ahol az adatok időszerűsége 1-5 másodperces késleltetéssel fontos.
• Értesítések — értesítések kézbesítése a böngészőben Service Workers és Push API használata nélkül.
• Aktivitási hírfolyamok — közösségi hálózatok és hírcsatornák automatikus tartalomfrissítéssel új bejegyzések megjelenésekor.
• Együttműködő munka — Google Docs-szerű szerkesztők a változtatások alapvető szinkronizálásával a felhasználók között.

A Long Polling választásának kulcstényezője a visszafelé kompatibilitás. Minden HTTP kliens és szerver támogatja ezt a módszert, ami univerzális megoldássá teszi a valós idejű működéshez további függőségek nélkül. A HTTP Archive (2024) szerint az összes webhely körülbelül 8%-a továbbra is Long Pollingot használ az alapvető valós idejű funkciókhoz.

Long Polling vs Short Polling

Long Polling és a Short Polling ugyanazt a feladatot oldja meg — adatok szállítását a szervertől a klienshez — de alapvetően különböznek mechanizmusban és hatékonyságban. A Short Polling rögzített lekérdezési intervallumot használ, ahol a kliens HTTP-kéréseket küld egyenlő időközönként, függetlenül attól, hogy jelentek-e meg új adatok a szerveren.

Short Polling egyszerűbb implementálni, de jelentősen nagyobb terhelést generál a szerveren és a hálózaton ugyanolyan adatfrissítési gyakoriság mellett. Ha 5 másodpercnél kisebb késleltetés szükséges, a Short Polling több tucat kérést generál percenként, míg a Long Polling egy kérést használ eseményenként vagy timeoutonként. Ritka eseményekkel rendelkező alkalmazásokhoz a Long Polling nagyságrendileg hatékonyabb forgalom szempontjából.

Long Polling vs WebSocket

WebSocket egy teljes értékű kétirányú valós idejű protokoll, amely a kezdeti HTTP kézfogás után TCP felett működik. A Long Pollinggal ellentétben a WebSocket egy állandó kapcsolatot hoz létre, és lehetővé teszi a szerver számára, hogy bármikor adatot küldjön a kliensnek anélkül, hogy új HTTP-kérést hozna létre.

A Long Polling és a WebSocket közötti választás több tényezőtől függ. Kompatibilitás: a Long Polling minden proxy-n és tűzfalon átműködik, a WebSocketet blokkolhatják a vállalati hálózatok. Teljesítmény: a WebSocket kisebb overhead-del rendelkezik (2 bájt keretenként a teljes HTTP fejlécekkel szemben), ami magas üzenetgyakoriságnál kritikus. Skálázhatóság: a Long Polling több erőforrást igényel a szerver oldalán a több kapcsolat tartása miatt, a WebSocket rögzített kapcsolatot használ munkamenetenként.

• Long Polling — a legjobb választás alacsony eseménygyakoriságú (percenként 1-10 esemény), korlátozott infrastruktúrájú alkalmazásokhoz vagy régi böngészők támogatásának szükségessége esetén.
• WebSocket — optimális megoldás nagy terhelésű valós idejű alkalmazásokhoz (tőzsdei adatok, online játékok, együttműködő szerkesztők) másodpercenként több száz üzenettel.
• Hibrid megközelítés — egyes alkalmazások Long Pollingot használnak fallbackként a WebSocketet nem támogató kliensek számára, automatikus protokollváltással.

A Mozilla Developer Network (2024) szerint a WebSocketet támogatja az összes modern böngésző a 2011-2015-ös verzióktól kezdve, de a vállalati proxyk (pl. Symantec Blue Coat) továbbra is blokkolják a vállalati hálózatok 15-20%-ában, ami fenntartja a Long Polling relevanciáját fallback megoldásként.