Long Polling: vad det är, hur det fungerar och var det används

Vad är Long Polling

Long Polling är ett interaktionsmönster i klient-serverarkitekturen där klienten initierar en HTTP-förfrågan och servern fördröjer sändningen av svaret tills ny data dyker upp eller en angiven timeout löper ut. Efter mottagandet av svaret skickar klienten omedelbart nästa förfrågan, vilket skapar en effekt av kontinuerlig anslutning.

Long Polling-tekniken uppstod som en evolutionär utveckling av Short Polling för att minska antalet tomma HTTP-förfrågningar. Vid traditionell polling skickar klienten förfrågningar varje N sekund och servern svarar även när det inte finns ny data. Vid Long Polling använder servern en mekanism för att hålla anslutningen vid liv, vilket radikalt minskar mängden oanvändbar trafik.

Long Pollings historia

Före WebSockets uppkomst 2011 var Long Polling den huvudsakliga metoden för att organisera realtid på webben. Företag som Facebook och Gmail använde denna teknik för sina chattar och aviseringar i början av 2010-talet. Enligt forskningen High Performance Browser Networking (Grigorik, 2013) bearbetade Long Polling upp till 95 % av alla realtidsanslutningar i stora webbapplikationer under den perioden.

Grundprincipen för Long Polling

Klienten skickar en standard HTTP-förfrågan till servern. Servern returnerar inte omedelbart ett svar efter att ha tagit emot förfrågan — den placerar förfrågan i en väntekö. När en händelse inträffar på servern (nytt meddelande, dataändring) skapar servern ett svar och skickar det till klienten. Klienten skapar omedelbart en ny Long Polling-förfrågan efter att ha tagit emot svaret, och cykeln upprepas.

Hur Long Polling fungerar

Long Polling fungerar enligt följande stegsekvens. Klienten skickar en HTTP GET-förfrågan till serverns endpoint. Servern kontrollerar efter att ha tagit emot förfrågan tillgången på ny data i händelsekön. Om det inte finns någon data håller servern förfrågan i väntande tillstånd utan att omedelbart skicka ett svar. Mekanismen för att hålla beror på serverimplementeringen — oftast används asynkron bearbetning med callbacks eller händelsestyrd arkitektur.

När en händelse inträffar på serversidan (till exempel en användare skickade ett meddelande i chatten), skapar servern ett HTTP-svar med en kropp som innehåller dessa data och avslutar anslutningen. Klienten tar emot svaret, bearbetar datan och initierar omedelbart en ny förfrågan. Om data inte har dykt upp under väntetiden skickar servern ett tomt svar efter timeoutens utgång, och klienten återskapar också anslutningen. Timeout är vanligtvis 30-60 sekunder för balans mellan belastning och fördröjning.

Time-out och anslutningshantering

Den viktigaste parametern för Long Polling-konfigurationen är väntetimeout. En för kort timeout (mindre än 10 sekunder) leder till en ökning av antalet förfrågningar, vilket närmar tekniken till Short Polling. En för lång (mer än 120 sekunder) kan orsaka att anslutningen bryts av mellanliggande proxyservrar och lastbalanserare. Rekommenderat värde för de flesta scenarier är 30-45 sekunder.

Hantering av flera händelser

Om flera händelser har inträffat på servern under en enda Long Polling-förfrågan måste servern överföra dem alla i ett svar eller organisera en händelsekö på klientens sida. För detta används buffring av händelser: servern samlar händelser som inträffade under tiden förfrågan hölls och överför dem som en datamatris i svarskroppen.

Exempel på implementering av Long Polling i JavaScript

Låt oss titta på en enkel implementering av Long Polling på klientsidan med moderna Fetch API. Klientfunktionen skickar en förfrågan och anropar sig själv rekursivt efter att ha tagit emot svaret.

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-fel", error);
        setTimeout(() => longPoll(url), 3000);
    }
}

function handleData(data) {
    if (data.events && data.events.length > 0) {
        data.events.forEach(event => {
            console.log("Ny händelse:", event);
        });
    }
}

longPoll("/api/events");

Denna kod skapar en oändlig Long Polling-loop: efter att ha tagit emot svaret skickar funktionen omedelbart en ny förfrågan. Vid anslutningsfel sätts en tre sekunders fördröjning före återförsök för att undvika lavinbelastning på servern.

Serverimplementering i Node.js

På serversidan måste förfrågan hållas tills en händelse dyker upp eller timeout löper ut. Ett exempel på implementering med EventEmitter i Node.js demonstrerar denna mekanism.

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

Serverdelen använder EventEmitter för att meddela väntande Long Polling-anslutningar när ny data dyker upp. När 30-sekunders timeout nås returnerar servern en tom händelsematris och klienten skapar en ny förfrågan.

När används Long Polling

Long Polling används i scenarier där dataleverans i realtid krävs men användning av WebSocket är omöjlig av tekniska eller infrastrukturella skäl. De vanligaste fallen — företagsproxy och brandväggar som blockerar WebSocket-anslutningar, samt miljöer med begränsat protokollstöd på serversidan.

• Chattar och meddelandetjänster — Long Polling säkerställer meddelandeleverans i webbversioner av meddelandetjänster som fungerar via HTTP utan WebSocket.
• Övervakningspaneler — realtidssystem för DevOps-metriker, loggar och aviseringar där datans aktualitet med en fördröjning på 1-5 sekunder är viktig.
• Aviseringar — leverans av aviseringar i webbläsaren utan att använda Service Workers och Push API.
• Aktivitetsflöden — sociala nätverk och nyhetsflöden med automatisk uppdatering av innehåll när nya inlägg dyker upp.
• Samarbete — Google Docs-liknande redigerare med grundläggande synkronisering av ändringar mellan användare.

Den viktigaste faktorn för att välja Long Polling är bakåtkompatibilitet. Alla HTTP-klienter och servrar stöder denna metod, vilket gör den till en universell lösning för realtid utan ytterligare beroenden. Enligt HTTP Archive (2024) använder cirka 8 % av alla webbplatser fortfarande Long Polling för grundläggande realtidsfunktionalitet.

Long Polling vs Short Polling

Long Polling och Short Polling löser samma uppgift — dataleverans från server till klient — men skiljer sig fundamentalt i mekanism och effektivitet. Short Polling använder ett fast pollingsintervall där klienten skickar HTTP-förfrågningar med jämna tidsintervall oavsett om ny data har dykt upp på servern.

Short Polling är enklare att implementera men genererar betydligt större belastning på servern och nätverket vid samma datauppdateringsfrekvens. Om en fördröjning på mindre än 5 sekunder krävs, genererar Short Polling dussintals förfrågningar per minut, medan Long Polling använder en förfrågan per händelse eller timeout. För applikationer med sällsynta händelser är Long Polling storleksordningar mer effektivt trafikmässigt.

Long Polling vs WebSocket

WebSocket är ett fullfjädrat tvåvägs realtidsprotokoll som fungerar över TCP efter en inledande HTTP-handskakning. Till skillnad från Long Polling upprättar WebSocket en permanent anslutning och tillåter servern att skicka data till klienten när som helst utan att skapa en ny HTTP-förfrågan.

Valet mellan Long Polling och WebSocket beror på flera faktorer. Kompatibilitet: Long Polling fungerar genom alla proxy och brandväggar, WebSocket kan blockeras av företagsnätverk. Prestanda: WebSocket har mindre overhead (2 byte per ram jämfört med fulla HTTP-huvuden), vilket är kritiskt vid hög meddelandefrekvens. Skalbarhet: Long Polling kräver mer resurser på serversidan på grund av att flera anslutningar hålls, WebSocket använder en fast anslutning per session.

• Long Polling — bästa valet för applikationer med låg händelsefrekvens (1-10 händelser per minut), begränsad infrastruktur eller behov av att stödja gamla webbläsare.
• WebSocket — optimal lösning för högt belastade realtidsapplikationer (börsdata, onlinespel, samarbetsredigerare) med hundratals meddelanden per sekund.
• Hybridmetod — vissa applikationer använder Long Polling som fallback för klienter som inte stöder WebSocket, med automatisk protokollväxling.

Enligt Mozilla Developer Network (2024) stöds WebSocket av alla moderna webbläsare från versioner 2011-2015, men företagsproxy (t.ex. Symantec Blue Coat) fortsätter att blockera det i 15-20 % av företagsnätverken, vilket upprätthåller Long Pollings relevans som fallback-lösning.