Long Polling: ano ito, paano ito gumagana at saan ito ginagamit

Ano ang Long Polling

Long Polling ay isang pattern ng interaksyon sa arkitekturang kliyente-server kung saan ang kliyente ay nag-iinitiate ng HTTP request, at ang server ay nagde-delay ng pagpapadala ng tugon hanggang sa lumitaw ang bagong data o mag-expire ang tinukoy na timeout. Pagkatapos matanggap ang tugon, agad na nagpapadala ang kliyente ng susunod na request, na lumilikha ng epekto ng tuluy-tuloy na koneksyon.

Ang pamamaraang Long Polling ay lumitaw bilang ebolusyonaryong pag-unlad ng Short Polling upang bawasan ang bilang ng mga walang laman na HTTP request. Sa tradisyonal na polling, nagpapadala ang kliyente ng mga request bawat N segundo, at tumutugon ang server kahit walang bagong data. Sa Long Polling, gumagamit ang server ng mekanismo ng pagpapanatili ng koneksyon, na radikal na nagbabawas ng dami ng walang silbi na trapiko.

Kasaysayan ng Long Polling

Bago ang paglitaw ng WebSocket noong 2011, ang Long Polling ay ang pangunahing paraan ng organisasyon ng real-time sa web. Ang mga kumpanyang tulad ng Facebook at Gmail ay gumamit ng pamamaraang ito para sa kanilang mga chat at notipikasyon noong unang bahagi ng 2010s. Ayon sa pananaliksik na High Performance Browser Networking (Grigorik, 2013), pinroseso ng Long Polling ang hanggang 95% ng lahat ng real-time na koneksyon sa malalaking web application noong panahong iyon.

Pangunahing Prinsipyo ng Long Polling

Nagpapadala ang kliyente ng karaniwang HTTP request sa server. Ang server pagkatapos matanggap ang request ay hindi agad nagbabalik ng tugon — inilalagay nito ang request sa waiting queue. Kapag may naganap na kaganapan sa server (bagong mensahe, pagbabago ng data), bubuo ang server ng tugon at ipapadala ito sa kliyente. Ang kliyente pagkatapos matanggap ang tugon ay agad na gumagawa ng bagong Long Polling request, at umuulit ang cycle.

Paano gumagana ang Long Polling

Long Polling ay gumagana ayon sa sumusunod na pagkakasunod-sunod ng mga hakbang. Nagpapadala ang kliyente ng HTTP GET request sa server endpoint. Ang server pagkatapos matanggap ang request ay tinitingnan ang pagkakaroon ng bagong data sa event queue. Kung walang data, pinapanatili ng server ang request sa waiting state, hindi agad nagpapadala ng tugon. Ang mekanismo ng pagpapanatili ay depende sa implementasyon ng server — karaniwang ginagamit ang asynchronous processing na may callbacks o event-driven architecture.

Kapag may naganap na kaganapan sa panig ng server (halimbawa, nagpadala ang user ng mensahe sa chat), bubuo ang server ng HTTP response na may body na naglalaman ng data na iyon at tinatapos ang koneksyon. Natatanggap ng kliyente ang tugon, pinoproseso ang data, at agad na nag-iinitiate ng bagong request. Kung sa panahon ng paghihintay ay hindi lumitaw ang data, nagpapadala ang server ng walang laman na tugon pagkatapos mag-expire ang timeout, at muling gagawa ng koneksyon ang kliyente. Karaniwang 30-60 segundo ang timeout para sa balanse sa pagitan ng load at latency.

Time-out at Pamamahala ng Koneksyon

Ang pangunahing parameter ng pagsasaayos ng Long Polling ay ang wait timeout. Masyadong maikling timeout (mas mababa sa 10 segundo) ay humahantong sa pagtaas ng bilang ng mga request, pinalalapit ang pamamaraan sa Short Polling. Masyadong mahaba (higit sa 120 segundo) ay maaaring maging sanhi ng pagkaputol ng koneksyon ng mga intermediate proxy at load balancer. Ang inirerekomendang halaga para sa karamihan ng mga senaryo ay 30-45 segundo.

Pamamahala ng Maramihang Kaganapan

Kung maraming kaganapan ang naganap sa server sa loob ng isang Long Polling request, dapat ipadala ng server ang lahat ng ito sa isang tugon o mag-organisa ng event queue sa panig ng kliyente. Para dito ginagamit ang event buffering: iniipon ng server ang mga kaganapan na naganap habang pinapanatili ang request at ipinapadala ang mga ito bilang array ng data sa body ng tugon.

Halimbawa ng Implementasyon ng Long Polling sa JavaScript

Tingnan natin ang isang simpleng implementasyon ng Long Polling sa panig ng kliyente gamit ang modernong Fetch API. Ang function ng kliyente ay nagpapadala ng request at recursively tumatawag sa sarili pagkatapos matanggap ang tugon.

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

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

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

longPoll("/api/events");

Ang code na ito ay lumilikha ng walang katapusang Long Polling loop: pagkatapos matanggap ang tugon, agad na nagpapadala ang function ng bagong request. Sa kaso ng error sa koneksyon, nagtatakda ito ng tatlong segundong pagkaantala bago muling subukan upang maiwasan ang avalanche load sa server.

Server-side Implementasyon sa Node.js

Sa panig ng server, kailangan panatilihin ang request hanggang lumitaw ang kaganapan o mag-expire ang timeout. Ang halimbawa ng implementasyon gamit ang EventEmitter sa Node.js ay nagpapakita ng mekanismong ito.

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

Ang bahagi ng server ay gumagamit ng EventEmitter upang ipaalam sa mga naghihintay na Long Polling na koneksyon kapag lumitaw ang bagong data. Kapag naabot ang 30 segundong timeout, nagbabalik ang server ng walang laman na array ng mga kaganapan, at gumagawa ang kliyente ng bagong request.

Kailan ginagamit ang Long Polling

Long Polling ay ginagamit sa mga senaryo na nangangailangan ng paghahatid ng data sa real-time, ngunit hindi posible ang paggamit ng WebSocket dahil sa teknikal o imprastruktura na mga kadahilanan. Ang pinakakaraniwang kaso — corporate proxy at firewall na humaharang sa WebSocket koneksyon, pati na rin ang mga kapaligiran na may limitadong suporta ng protocol sa panig ng server.

• Chat at messenger — tinitiyak ng Long Polling ang paghahatid ng mensahe sa mga web version ng messenger na gumagana sa pamamagitan ng HTTP nang walang WebSocket.
• Monitoring panel — real-time system para sa DevOps metrics, log at alert kung saan mahalaga ang pagiging napapanahon ng data na may latency na 1-5 segundo.
• Notipikasyon — paghahatid ng notipikasyon sa browser nang hindi gumagamit ng Service Workers at Push API.
• Activity feed — social media at news feed na may awtomatikong pag-update ng content kapag lumitaw ang mga bagong entry.
• Collaborative na trabaho — mga editor tulad ng Google Docs na may pangunahing synchronize ng mga pagbabago sa pagitan ng mga user.

Ang pangunahing factor sa pagpili ng Long Polling ay backward compatibility. Lahat ng HTTP client at server ay sumusuporta sa pamamaraang ito, na ginagawa itong unibersal na solusyon para sa real-time nang walang karagdagang dependencies. Ayon sa HTTP Archive (2024), humigit-kumulang 8% ng lahat ng website ay patuloy na gumagamit ng Long Polling para sa pangunahing real-time na functionality.

Long Polling vs Short Polling

Long Polling at Short Polling ay lumulutas ng parehong gawain — paghahatid ng data mula server patungo sa kliyente — ngunit pangunahing nagkakaiba sa mekanismo at kahusayan. Ang Short Polling ay gumagamit ng fixed polling interval, kung saan ang kliyente ay nagpapadala ng HTTP request sa pantay na agwat ng oras kahit may bagong data sa server o wala.

Short Polling ay mas simple sa implementasyon, ngunit lumilikha ng mas malaking load sa server at network sa parehong frequency ng pag-update ng data. Kung kinakailangan ang latency na mas mababa sa 5 segundo, ang Short Polling ay lumilikha ng dose-dosenang request kada minuto, habang ang Long Polling ay gumagamit ng isang request bawat kaganapan o timeout. Para sa mga aplikasyon na may madalang na kaganapan, ang Long Polling ay mas episyente sa usapin ng trapiko.

Long Polling vs WebSocket

WebSocket ay isang ganap na bidirectional real-time protocol na gumagana sa ibabaw ng TCP pagkatapos ng paunang pag-shake ng kamay ng HTTP. Hindi tulad ng Long Polling, ang WebSocket ay nagtatag ng isang permanenteng koneksyon at pinapayagan ang server na magpadala ng data sa kliyente anumang oras nang hindi gumagawa ng bagong HTTP request.

Ang pagpili sa pagitan ng Long Polling at WebSocket ay depende sa ilang factor. Kompatibilidad: Long Polling ay gumagana sa lahat ng proxy at firewall, ang WebSocket ay maaaring harangin ng corporate network. Pagganap: WebSocket ay may mas maliit na overhead (2 bytes per frame kumpara sa kumpletong HTTP header), na kritikal sa mataas na frequency ng mensahe. Scalability: Long Polling ay nangangailangan ng mas maraming resources sa panig ng server dahil sa pagpapanatili ng maraming koneksyon, WebSocket ay gumagamit ng fixed na koneksyon bawat session.

• Long Polling — pinakamahusay na pagpipilian para sa mga aplikasyon na may mababang frequency ng kaganapan (1-10 kaganapan kada minuto), limitadong imprastruktura, o pangangailangang suportahan ang mga lumang browser.
• WebSocket — optimal na solusyon para sa high-load na real-time na aplikasyon (data ng stock market, online games, collaborative editor) na may daan-daang mensahe bawat segundo.
• Hybrid approach — ilang aplikasyon ay gumagamit ng Long Polling bilang fallback para sa mga kliyente na hindi sumusuporta sa WebSocket, na may awtomatikong paglipat ng protocol.

Ayon sa Mozilla Developer Network (2024), WebSocket ay suportado ng lahat ng modernong browser mula sa bersyon 2011-2015, ngunit ang corporate proxy (hal. Symantec Blue Coat) ay patuloy na humaharang dito sa 15-20% ng corporate network, na nagpapanatili ng kaugnayan ng Long Polling bilang fallback solution.