Long Polling: wat het is, hoe het werkt en waar het wordt gebruikt

Wat is Long Polling

Long Polling is een interactiepatroon in de client-serverarchitectuur waarbij de client een HTTP-verzoek initieert en de server het antwoord uitstelt tot er nieuwe gegevens verschijnen of een bepaalde time-out verloopt. Na ontvangst van het antwoord stuurt de client onmiddellijk het volgende verzoek, waardoor een continu verbindingseffect ontstaat.

De Long Polling-techniek is ontstaan als een evolutionaire ontwikkeling van Short Polling om het aantal lege HTTP-verzoeken te verminderen. Bij traditionele polling stuurt de client elke N seconden verzoeken en de server antwoordt zelfs bij afwezigheid van nieuwe gegevens. Bij Long Polling gebruikt de server een mechanisme voor het vasthouden van de verbinding, waardoor de hoeveelheid nutteloos verkeer drastisch afneemt.

Geschiedenis van Long Polling

Vóór de komst van WebSocket in 2011 was Long Polling de belangrijkste methode voor realtime organisatie op het web. Bedrijven zoals Facebook en Gmail gebruikten deze techniek voor hun chats en meldingen in het begin van de jaren 2010. Volgens het onderzoek High Performance Browser Networking (Grigorik, 2013) verwerkte Long Polling tot 95% van alle realtime verbindingen in grote webapplicaties uit die periode.

Basisprincipe van Long Polling

De client stuurt een standaard HTTP-verzoek naar de server. De server retourneert na ontvangst van het verzoek niet onmiddellijk een antwoord — hij plaatst het verzoek in een wachtrij. Wanneer er een gebeurtenis op de server plaatsvindt (nieuw bericht, gegevenswijziging), vormt de server het antwoord en stuurt het naar de client. De client maakt na ontvangst van het antwoord onmiddellijk een nieuw Long Polling-verzoek en de cyclus herhaalt zich.

Hoe werkt Long Polling

Long Polling werkt volgens de volgende reeks stappen. De client stuurt een HTTP GET-verzoek naar het server-endpoint. De server controleert na ontvangst van het verzoek de beschikbaarheid van nieuwe gegevens in de gebeurtenissenwachtrij. Als er geen gegevens zijn, houdt de server het verzoek in wachtstand zonder onmiddellijk een antwoord te sturen. Het mechanisme voor vasthouden hangt af van de serverimplementatie — meestal wordt asynchrone verwerking met callbacks of gebeurtenisarchitectuur gebruikt.

Wanneer er aan serverzijde een gebeurtenis plaatsvindt (bijvoorbeeld een gebruiker heeft een bericht in de chat gestuurd), vormt de server een HTTP-antwoord met de gegevens en beëindigt de verbinding. De client ontvangt het antwoord, verwerkt de gegevens en initieert onmiddellijk een nieuw verzoek. Als er tijdens het wachten geen gegevens zijn verschenen, stuurt de server een leeg antwoord na het verlopen van de time-out en herstelt de client de verbinding. De time-out bedraagt meestal 30-60 seconden voor een balans tussen belasting en vertraging.

Time-outs en verbindingsbeheer

De belangrijkste parameter van de Long Polling-configuratie is de wacht-time-out. Een te korte time-out (minder dan 10 seconden) leidt tot een toename van het aantal verzoeken, waardoor de techniek dichter bij Short Polling komt. Een te lange (meer dan 120 seconden) kan de verbinding laten verbreken door tussenliggende proxy's en load balancers. De aanbevolen waarde voor de meeste scenario's is 30-45 seconden.

Verwerking van meerdere gebeurtenissen

Als er op de server meerdere gebeurtenissen hebben plaatsgevonden tijdens één Long Polling-verzoek, moet de server ze allemaal in één antwoord doorgeven of een gebeurtenissenwachtrij aan clientzijde organiseren. Hiervoor wordt buffering van gebeurtenissen gebruikt: de server verzamelt de gebeurtenissen die tijdens het vasthouden van het verzoek hebben plaatsgevonden en geeft ze door als een gegevensarray in de antwoordbody.

Voorbeeld implementatie Long Polling in JavaScript

Laten we een eenvoudige implementatie van Long Polling aan clientzijde bekijken met behulp van moderne Fetch API. De clientfunctie stuurt een verzoek en roept zichzelf recursief aan na ontvangst van het antwoord.

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

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

longPoll("/api/events");

Deze code creëert een oneindige Long Polling-lus: na ontvangst van het antwoord stuurt de functie onmiddellijk een nieuw verzoek. Bij een verbindingsfout wordt een drie seconden vertraging ingesteld vóór een nieuwe poging om een lawinebelasting op de server te voorkomen.

Serverimplementatie in Node.js

Aan serverzijde moet het verzoek worden vastgehouden tot er een gebeurtenis plaatsvindt of de time-out verloopt. Een voorbeeldimplementatie met EventEmitter in Node.js demonstreert dit mechanisme.

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

Het serverdeel gebruikt EventEmitter om wachtende Long Polling-verbindingen op de hoogte te stellen bij het verschijnen van nieuwe gegevens. Bij het bereiken van de 30-seconden time-out retourneert de server een lege gebeurtenisarray en maakt de client een nieuw verzoek.

Wanneer wordt Long Polling toegepast

Long Polling wordt toegepast in scenario's waar realtime gegevenslevering vereist is, maar gebruik van WebSocket om technische of infrastructurele redenen onmogelijk is. De meest voorkomende gevallen — bedrijfsproxy's en firewalls die WebSocket-verbindingen blokkeren, en omgevingen met beperkte protocolondersteuning aan serverzijde.

• Chats en messengers — Long Polling zorgt voor berichtbezorging in webversies van messengers die via HTTP zonder WebSocket werken.
• Monitoringspanelen — realtime systemen voor DevOps-metrieken, logs en alerts waar actualiteit van gegevens met een vertraging van 1-5 seconden belangrijk is.
• Meldingen — levering van meldingen in de browser zonder gebruik van Service Workers en Push API.
• Activiteitsfeeds — sociale netwerken en nieuwsfeeds met automatische inhoudsupdate bij het verschijnen van nieuwe berichten.
• Samenwerking — Google Docs-achtige editors met basissynchronisatie van wijzigingen tussen gebruikers.

De belangrijkste factor bij het kiezen van Long Polling is achterwaartse compatibiliteit. Alle HTTP-clients en servers ondersteunen deze methode, wat het een universele oplossing maakt voor realtime zonder extra afhankelijkheden. Volgens HTTP Archive (2024) gebruikt ongeveer 8% van alle websites nog steeds Long Polling voor basisfunctionaliteit in realtime.

Long Polling vs Short Polling

Long Polling en Short Polling lossen dezelfde taak op — gegevenslevering van server naar client — maar verschillen fundamenteel in mechanisme en efficiëntie. Short Polling gebruikt een vast polling-interval, waarbij de client HTTP-verzoeken stuurt op gelijke tijdsintervallen, ongeacht of er nieuwe gegevens op de server zijn verschenen.

Short Polling is eenvoudiger te implementeren, maar genereert aanzienlijk meer belasting op de server en het netwerk bij dezelfde gegevensverversingsfrequentie. Als een vertraging van minder dan 5 seconden vereist is, genereert Short Polling tientallen verzoeken per minuut, terwijl Long Polling één verzoek per gebeurtenis of time-out gebruikt. Voor applicaties met zeldzame gebeurtenissen is Long Polling qua verkeer een orde van grootte efficiënter.

Long Polling vs WebSocket

WebSocket is een volwaardig bidirectioneel realtime protocol dat over TCP werkt na een initiële HTTP-handshake. In tegenstelling tot Long Polling vestigt WebSocket één permanente verbinding en stelt de server in staat om op elk moment gegevens naar de client te sturen zonder een nieuw HTTP-verzoek te maken.

De keuze tussen Long Polling en WebSocket hangt af van verschillende factoren. Compatibiliteit: Long Polling werkt door alle proxy's en firewalls heen, WebSocket kan worden geblokkeerd door bedrijfsnetwerken. Prestaties: WebSocket heeft minder overhead (2 bytes per frame versus volledige HTTP-headers), wat kritisch is bij hoge berichtfrequentie. Schaalbaarheid: Long Polling vereist meer bronnen aan serverzijde door het vasthouden van meerdere verbindingen, WebSocket gebruikt een vaste verbinding per sessie.

• Long Polling — de beste keuze voor applicaties met lage gebeurtenisfrequentie (1-10 gebeurtenissen per minuut), beperkte infrastructuur of de noodzaak om oude browsers te ondersteunen.
• WebSocket — de optimale oplossing voor zwaarbelaste realtime applicaties (beursgegevens, online games, collaboratieve editors) met honderden berichten per seconde.
• Hybride aanpak — sommige applicaties gebruiken Long Polling als fallback voor clients die WebSocket niet ondersteunen, met automatische protocolomschakeling.

Volgens Mozilla Developer Network (2024) wordt WebSocket ondersteund door alle moderne browsers vanaf versies 2011-2015, maar bedrijfsproxy's (bijv. Symantec Blue Coat) blijven het blokkeren in 15-20% van de bedrijfsnetwerken, wat de relevantie van Long Polling als fallback-oplossing behoudt.