Long Polling: co to je, jak funguje a kde se používá

Co je Long Polling

Long Polling je vzor interakce v architektuře klient-server, při kterém klient iniciuje HTTP požadavek a server odloží odeslání odpovědi do okamžiku, kdy se objeví nová data nebo vyprší zadaný časový limit. Po obdržení odpovědi klient okamžitě odešle další požadavek, čímž vytvoří efekt nepřetržitého spojení.

Technika Long Polling vznikla jako evoluční vývoj Short Polling pro snížení počtu prázdných HTTP požadavků. Při tradičním dotazování klient odesílá požadavky každých N sekund a server odpovídá i při absenci nových dat. Při Long Polling server používá mechanismus držení spojení, což radikálně snižuje objem zbytečného provozu.

Historie vzniku Long Polling

Před objevením WebSocket v roce 2011 byl Long Polling hlavním způsobem organizace reálného času na webu. Společnosti jako Facebook a Gmail používaly tuto techniku pro své chaty a oznámení na začátku roku 2010. Podle výzkumu High Performance Browser Networking (Grigorik, 2013) zpracovával Long Polling až 95 % všech spojení v reálném čase ve velkých webových aplikacích té doby.

Základní princip Long Polling

Klient odešle standardní HTTP požadavek serveru. Server po obdržení požadavku nevrátí odpověď okamžitě — umístí požadavek do fronty čekání. Když na serveru nastane událost (nová zpráva, změna dat), server vytvoří odpověď a odešle ji klientovi. Klient po obdržení odpovědi okamžitě vytvoří nový Long Polling požadavek a cyklus se opakuje.

Jak funguje Long Polling

Long Polling funguje podle následující sekvence kroků. Klient odešle HTTP GET požadavek na serverový endpoint. Server po obdržení požadavku zkontroluje dostupnost nových dat ve frontě událostí. Pokud data nejsou, server drží požadavek v čekajícím stavu, aniž by okamžitě odeslal odpověď. Mechanismus držení závisí na implementaci serveru — nejčastěji se používá asynchronní zpracování s callbacky nebo architektura založená na událostech.

Když na straně serveru nastane událost (například uživatel odeslal zprávu v chatu), server vytvoří HTTP odpověď s tělem obsahujícím tato data a ukončí spojení. Klient obdrží odpověď, zpracuje data a okamžitě zahájí nový požadavek. Pokud se během čekání data neobjevila, server odešle prázdnou odpověď po vypršení časového limitu a klient také znovu vytvoří spojení. Timeout je obvykle 30-60 sekund pro rovnováhu mezi zatížením a zpožděním.

Časové limity a správa spojení

Klíčovým parametrem konfigurace Long Polling je časový limit čekání. Příliš krátký časový limit (méně než 10 sekund) vede ke zvýšení počtu požadavků, čímž se technika přibližuje Short Polling. Příliš dlouhý (více než 120 sekund) může způsobit přerušení spojení mezilehlými proxy a load balancery. Doporučená hodnota pro většinu scénářů je 30-45 sekund.

Zpracování vícenásobných událostí

Pokud na serveru nastalo několik událostí během jednoho Long Polling požadavku, server je musí předat všechny v jedné odpovědi nebo zorganizovat frontu událostí na straně klienta. K tomu se používá ukládání do vyrovnávací paměti: server shromažďuje události, které nastaly během držení požadavku, a předává je jako pole dat v těle odpovědi.

Příklad implementace Long Polling v JavaScriptu

Podívejme se na jednoduchou implementaci Long Polling na straně klienta pomocí moderního Fetch API. Klientská funkce odešle požadavek a po obdržení odpovědi rekurzivně zavolá sama sebe.

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

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

function handleData(data) {
    if (data.events && data.events.length > 0) {
        data.events.forEach(event => {
            console.log("Nová událost:", event);
        });
    }
}

longPoll("/api/events");

Tento kód vytváří nekonečnou smyčku Long Polling: po obdržení odpovědi funkce okamžitě odešle nový požadavek. Při chybě spojení se nastaví třísekundové zpoždění před opakováním, aby se předešlo lavinovému zatížení serveru.

Serverová implementace v Node.js

Na straně serveru je třeba držet požadavek až do objevení události nebo vypršení časového limitu. Příklad implementace pomocí EventEmitter v Node.js demonstruje tento mechanismus.

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

Serverová část používá EventEmitter k oznamování čekajícím Long Polling spojením při objevení nových dat. Po dosažení 30sekundového časového limitu server vrátí prázdné pole událostí a klient vytvoří nový požadavek.

Kdy se Long Polling používá

Long Polling se používá ve scénářích, kde je vyžadováno doručování dat v reálném čase, ale použití WebSocket je nemožné z technických nebo infrastrukturních důvodů. Nejčastější případy — firemní proxy a firewally blokující WebSocket spojení, stejně jako prostředí s omezenou podporou protokolu na straně serveru.

• Chaty a messenger — Long Polling zajišťuje doručování zpráv ve webových verzích messengerů pracujících přes HTTP bez WebSocket.
• Monitorovací panely — systémy reálného času pro DevOps metriky, logy a alerty, kde je důležitá aktuálnost dat se zpožděním 1-5 sekund.
• Oznámení — doručování oznámení v prohlížeči bez použití Service Workers a Push API.
• Kanály aktivity — sociální sítě a zpravodajské kanály s automatickou aktualizací obsahu při objevení nových příspěvků.
• Spolupráce — editory typu Google Docs se základní synchronizací změn mezi uživateli.

Klíčovým faktorem výběru Long Polling je zpětná kompatibilita. Všechny HTTP klienty a servery podporují tuto metodu, což z ní činí univerzální řešení pro reálný čas bez dalších závislostí. Podle HTTP Archive (2024) asi 8 % všech webových stránek nadále používá Long Polling pro základní funkcionalitu v reálném čase.

Long Polling vs Short Polling

Long Polling a Short Polling řeší stejný úkol — doručování dat ze serveru klientovi — ale zásadně se liší mechanismem a účinností. Short Polling používá pevný interval dotazování, při kterém klient odesílá HTTP požadavky ve stejných časových intervalech bez ohledu na to, zda se na serveru objevila nová data.

Short Polling je jednodušší na implementaci, ale vytváří výrazně větší zatížení serveru a sítě při stejné frekvenci aktualizace dat. Pokud je vyžadováno zpoždění menší než 5 sekund, Short Polling generuje desítky požadavků za minutu, zatímco Long Polling používá jeden požadavek na událost nebo timeout. Pro aplikace se vzácnými událostmi je Long Polling řádově účinnější z hlediska provozu.

Long Polling vs WebSocket

WebSocket je plnohodnotný obousměrný protokol reálného času pracující nad TCP po počátečním HTTP handshake. Na rozdíl od Long Polling vytváří WebSocket jedno trvalé spojení a umožňuje serveru odesílat data klientovi kdykoli bez vytvoření nového HTTP požadavku.

Volba mezi Long Polling a WebSocket závisí na několika faktorech. Kompatibilita: Long Polling funguje přes všechny proxy a firewally, WebSocket může být blokován firemními sítěmi. Výkon: WebSocket má menší režii (2 bajty na rámec oproti plným HTTP hlavičkám), což je kritické při vysoké frekvenci zpráv. Škálovatelnost: Long Polling vyžaduje více zdrojů na straně serveru kvůli držení více spojení, WebSocket používá pevné spojení na relaci.

• Long Polling — nejlepší volba pro aplikace s nízkou frekvencí událostí (1-10 událostí za minutu), omezenou infrastrukturou nebo potřebou podpory starých prohlížečů.
• WebSocket — optimální řešení pro vysoce zatížené aplikace reálného času (burzovní data, online hry, kolaborativní editory) se stovkami zpráv za sekundu.
• Hybridní přístup — některé aplikace používají Long Polling jako fallback pro klienty nepodporující WebSocket, s automatickým přepínáním protokolu.

Podle Mozilla Developer Network (2024) je WebSocket podporován všemi moderními prohlížeči od verzí 2011-2015, ale firemní proxy (např. Symantec Blue Coat) jej nadále blokují v 15-20 % firemních sítí, což udržuje relevanci Long Polling jako fallback řešení.