Long Polling: шта је то, како ради и где се користи

Шта је Long Polling

Long Polling је образац интеракције у архитектури клијент-сервер при којем клијент покреће ХТТП захтев, а сервер одлаже слање одговора до тренутка када се појаве нови подаци или истекне задати тајм-аут. Након пријема одговора, клијент одмах шаље следећи захтев, стварајући ефекат непрекидне везе.

Техника Long Polling се појавила као еволутивни развој Short Polling-а за смањење броја празних ХТТП захтева. У традиционалном испитивању, клијент шаље захтеве сваких N секунди, а сервер одговара чак и при одсуству нових података. У Long Polling-у сервер користи механизам држања везе, што радикално смањује количину бескорисног саобраћаја.

Историја настанка Long Polling-а

Пре појаве WebSocket-а 2011. године, Long Polling је био главни начин организовања реалног времена на вебу. Компаније попут Facebook-а и Gmail-а користиле су ову технику за своје четове и обавештења почетком 2010-их. Према истраживању High Performance Browser Networking (Grigorik, 2013), Long Polling је обрађивао до 95% свих веза у реалном времену у великим веб апликацијама тог периода.

Основни принцип Long Polling-а

Клијент шаље стандардни ХТТП захтев серверу. Сервер, по пријему захтева, не враћа одговор одмах — поставља захтев у ред чекања. Када на серверу наступи догађај (нова порука, промена података), сервер формира одговор и шаље га клијенту. Клијент, по пријему одговора, одмах ствара нови Long Polling захтев и циклус се понавља.

Како ради Long Polling

Long Polling ради по следећем низу корака. Клијент шаље ХТТП GET захтев ка серверском ендпоинту. Сервер, по пријему захтева, проверава присуство нових података у реду догађаја. Ако података нема, сервер држи захтев у стању чекања, не шаљући одговор одмах. Механизам држања зависи од имплементације сервера — најчешће се користи асинхрона обрада с повратним позивима или догађајна архитектура.

Када на страни сервера наступи догађај (на пример, корисник је послао поруку у чету), сервер формира ХТТП одговор са телом које садржи те податке и завршава везу. Клијент прима одговор, обрађује податке и одмах покреће нови захтев. Ако се у току чекања подаци нису појавили, сервер шаље празан одговор по истеку тајм-аута, а клијент такође поново успоставља везу. Timeout обично износи 30–60 секунди за равнотежу између оптерећења и кашњења.

Тајм-аути и управљање везом

Кључни параметар подешавања Long Polling-а је тајм-аут чекања. Прекратак тајм-аут (мање од 10 секунди) доводи до повећања броја захтева, приближавајући технику Short Polling-у. Предугачак (више од 120 секунди) може изазвати прекид везе од стране посредничких проксија и балансера оптерећења. Препоручена вредност за већину сценарија је 30–45 секунди.

Обрада вишеструких догађаја

Ако се на серверу догодило неколико догађаја током једног Long Polling захтева, сервер их треба пренети све у једном одговору или организовати ред догађаја на страни клијента. У ту сврху се користи баферовање догађаја: сервер акумулира догађаје који су се догодили током држања захтева и преноси их као низ података у телу одговора.

Пример имплементације Long Polling-а у JavaScript-у

Размотримо једноставну имплементацију Long Polling-а на страни клијента коришћењем савременог Fetch API. Клијентска функција шаље захтев и рекурзивно позива себе након пријема одговора.

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 грешка", error);
        setTimeout(() => longPoll(url), 3000);
    }
}

function handleData(data) {
    if (data.events && data.events.length > 0) {
        data.events.forEach(event => {
            console.log("Нови догађај:", event);
        });
    }
}

longPoll("/api/events");

Овај код ствара бесконачну петљу Long Polling-а: након пријема одговора, функција одмах шаље нови захтев. При грешци везе поставља се тросекундно кашњење пре поновног покушаја како би се избегло лавинско оптерећење сервера.

Серверска имплементација у Node.js-у

На страни сервера потребно је држати захтев док се не појави догађај или не истекне тајм-аут. Пример имплементације коришћењем EventEmitter у Node.js-у демонстрира овај механизам.

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

Серверски део користи EventEmitter за обавештавање Long Polling веза које чекају при појави нових података. По достизању 30-секундног тајм-аута, сервер враћа празан низ догађаја, а клијент ствара нови захтев.

Када се примењује Long Polling

Long Polling се примењује у сценаријима где је потребна достава података у реалном времену, али је употреба WebSocket-а немогућа из техничких или инфраструктурних разлога. Најчешћи случајеви — корпоративни проксији и заштитни зидови који блокирају WebSocket везе, као и окружења с ограниченом подршком протокола на страни сервера.

• Четови и месенџери — Long Polling обезбеђује доставу порука у веб верзијама месенџера који раде преко ХТТП-а без WebSocket-а.
• Контролне табле — системи реалног времена за DevOps метрике, евиденције и аларме, где је важна ажурност података са кашњењем од 1–5 секунди.
• Обавештења — достава обавештења у прегледачу без коришћења Service Workers и Push API.
• Фидови активности — друштвене мреже и вести са аутоматским ажурирањем садржаја при појави нових уноса.
• Заједнички рад — уређивачи попут Google Docs-а са основном синхронизацијом промена између корисника.

Кључни фактор избора Long Polling-а је уназад компатибилност. Сви ХТТП клијенти и сервери подржавају ову методу, што је чини универзалним решењем за реално време без додатних зависности. Према HTTP Archive (2024), око 8% свих веб-сајтова наставља да користи Long Polling за основну функционалност реалног времена.

Long Polling vs Short Polling

Long Polling и Short Polling решавају исти задатак — доставу података од сервера до клијента — али се суштински разликују по механизму и ефикасности. Short Polling користи фиксни интервал испитивања, при чему клијент шаље ХТТП захтеве у једнаким временским размацима без обзира на то да ли су се на серверу појавили нови подаци.

Short Polling је једноставнији за имплементацију, али ствара знатно веће оптерећење сервера и мреже при истој учесталости ажурирања података. Ако је потребно кашњење мање од 5 секунди, Short Polling ствара десетине захтева у минути, док Long Polling користи један захтев по догађају или тајм-ауту. За апликације са ретким догађајима, Long Polling је за ред величине ефикаснији по саобраћају.

Long Polling vs WebSocket

WebSocket је пуноправан двосмерни протокол реалног времена који ради преко TCP-а након почетног ХТТП руковања. За разлику од Long Polling-а, WebSocket успоставља једну сталну везу и омогућава серверу да шаље податке клијенту у било ком тренутку без стварања новог ХТТП захтева.

Избор између Long Polling-а и WebSocket-а зависи од неколико фактора. Компатибилност: Long Polling ради кроз све проксије и заштитне зидове, WebSocket могу блокирати корпоративне мреже. Перформансе: WebSocket има мањи overhead (2 бајта по оквиру наспрам потпуних ХТТП заглавља), што је критично при великој учесталости порука. Скалабилност: Long Polling захтева више ресурса на страни сервера због држања вишеструких веза, WebSocket користи фиксну везу по сесији.

• Long Polling — најбољи избор за апликације с ниском учесталошћу догађаја (1–10 догађаја у минути), ограниченом инфраструктуром или потребом за подршком старих прегледача.
• WebSocket — оптимално решење за високооптерећене апликације реалног времена (берзански подаци, онлајн игре, колаборативни уређивачи) са стотинама порука у секунди.
• Хибридни приступ — неке апликације користе Long Polling као fallback за клијенте који не подржавају WebSocket, са аутоматским пребацивањем протокола.

Према Mozilla Developer Network (2024), WebSocket је подржан у свим савременим прегледачима од верзија 2011–2015, али корпоративни проксији (нпр. Symantec Blue Coat) настављају да га блокирају у 15–20% корпоративних мрежа, што одржава актуелност Long Polling-а као fallback решења.