Long Polling: Was es ist, wie es funktioniert und wo es eingesetzt wird

Was ist Long Polling

Long Polling ist ein Kommunikationsmuster in einer Client-Server-Architektur, bei dem ein Client eine HTTP-Anfrage initiiert und der Server das Senden einer Antwort verzögert, bis neue Daten verfügbar sind oder ein bestimmtes Timeout abläuft. Nach dem Empfang der Antwort sendet der Client sofort die nächste Anfrage, wodurch der Effekt einer kontinuierlichen Verbindung entsteht.

Die Long Polling-Technik entstand als evolutionäre Weiterentwicklung von Short Polling, um die Anzahl leerer HTTP-Anfragen zu reduzieren. Beim traditionellen Polling sendet der Client alle N Sekunden Anfragen, und der Server antwortet auch dann, wenn keine neuen Daten vorhanden sind. Bei Long Polling verwendet der Server einen Verbindungshaltemechanismus, der nutzlosen Datenverkehr drastisch reduziert.

Die Geschichte von Long Polling

Vor dem Aufkommen von WebSocket im Jahr 2011 war Long Polling die primäre Methode für die Echtzeitkommunikation im Web. Unternehmen wie Facebook und Gmail nutzten diese Technik in den frühen 2010er Jahren für ihre Chats und Benachrichtigungen. Laut High Performance Browser Networking (Grigorik, 2013) wickelte Long Polling bis zu 95% aller Echtzeitverbindungen in den wichtigsten Webanwendungen dieser Zeit ab.

Grundprinzip von Long Polling

Ein Client sendet eine Standard-HTTP-Anfrage an den Server. Beim Empfang der Anfrage gibt der Server nicht sofort eine Antwort zurück – er stellt die Anfrage in eine Warteschlange. Wenn auf dem Server ein Ereignis eintritt (eine neue Nachricht, Datenänderung), erstellt der Server eine Antwort und sendet sie an den Client. Nach Erhalt der Antwort erstellt der Client sofort eine neue Long Polling-Anfrage, und der Zyklus wiederholt sich.

Wie Long Polling funktioniert

Long Polling funktioniert nach der folgenden Schrittfolge. Der Client sendet eine HTTP-GET-Anfrage an einen Server-Endpunkt. Beim Empfang der Anfrage prüft der Server, ob neue Daten in der Ereigniswarteschlange vorhanden sind. Wenn keine Daten vorhanden sind, hält der Server die Anfrage in einem Wartezustand, ohne sofort eine Antwort zu senden. Der Haltemechanismus hängt von der Serverimplementierung ab – meistens wird asynchrone Verarbeitung mit Callbacks oder eine ereignisgesteuerte Architektur verwendet.

Wenn auf der Serverseite ein Ereignis eintritt (z. B. hat ein Benutzer eine Nachricht in einem Chat gesendet), erstellt der Server eine HTTP-Antwort mit einem Körper, der diese Daten enthält, und beendet die Verbindung. Der Client empfängt die Antwort, verarbeitet die Daten und initiiert sofort eine neue Anfrage. Wenn während der Wartezeit keine Daten erscheinen, sendet der Server nach Ablauf des Timeouts eine leere Antwort, und der Client stellt die Verbindung ebenfalls wieder her. Das Timeout beträgt normalerweise 30–60 Sekunden, um eine Balance zwischen Last und Latenz zu erreichen.

Timeouts und Verbindungsverwaltung

Ein wichtiger Konfigurationsparameter für Long Polling ist das Warte-Timeout. Ein zu kurzes Timeout (weniger als 10 Sekunden) führt zu einer Erhöhung der Anzahl von Anfragen und bringt die Technik näher an Short Polling. Ein zu langes Timeout (mehr als 120 Sekunden) kann zu Verbindungsabbrüchen durch zwischengeschaltete Proxys und Load Balancer führen. Der empfohlene Wert für die meisten Szenarien beträgt 30–45 Sekunden.

Verarbeitung mehrerer Ereignisse

Wenn während einer einzelnen Long Polling-Anfrage mehrere Ereignisse auf dem Server auftreten, muss der Server sie alle in einer Antwort übertragen oder eine Ereigniswarteschlange auf der Client-Seite organisieren. Dazu wird eine Ereignispufferung verwendet: Der Server sammelt die während der Haltedauer der Anfrage aufgetretenen Ereignisse und überträgt sie als Datenarray im Antwortkörper.

Long Polling Implementierungsbeispiel in JavaScript

Betrachten wir eine einfache Long Polling-Implementierung auf der Client-Seite mit der modernen Fetch API. Die Client-Funktion sendet eine Anfrage und ruft sich nach Erhalt einer Antwort rekursiv selbst auf.

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

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

longPoll("/api/events");

Dieser Code erstellt eine Endlosschleife von Long Polling: Nach Erhalt einer Antwort sendet die Funktion sofort eine neue Anfrage. Bei einem Verbindungsfehler wird vor dem erneuten Versuch eine dreisekündige Verzögerung festgelegt, um eine Lawinenlast auf dem Server zu vermeiden.

Server-Implementierung auf Node.js

Auf der Serverseite ist es notwendig, die Anfrage zu halten, bis ein Ereignis eintritt oder ein Timeout abläuft. Ein Implementierungsbeispiel mit EventEmitter in Node.js demonstriert diesen 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);

Der Serverteil verwendet EventEmitter, um wartende Long Polling-Verbindungen zu benachrichtigen, wenn neue Daten erscheinen. Bei Erreichen des 30-Sekunden-Timeouts gibt der Server ein leeres Ereignis-Array zurück, und der Client erstellt eine neue Anfrage.

Wann Long Polling verwendet wird

Long Polling wird in Szenarien eingesetzt, in denen eine Echtzeit-Datenlieferung erforderlich ist, aber die Verwendung von WebSocket aus technischen oder infrastrukturellen Gründen nicht möglich ist. Die häufigsten Fälle sind Unternehmens-Proxys und Firewalls, die WebSocket-Verbindungen blockieren, sowie Umgebungen mit eingeschränkter Protokollunterstützung auf der Serverseite.

• Chats und Messenger – Long Polling ermöglicht die Nachrichtenübermittlung in Web-Versionen von Messengern, die über HTTP ohne WebSocket arbeiten.
• Dashboard-Panels – Echtzeitsysteme für DevOps-Metriken, Protokolle und Benachrichtigungen, bei denen die Aktualität der Daten mit einer Verzögerung von 1–5 Sekunden wichtig ist.
• Benachrichtigungen – Push-ähnliche Zustellung von Warnmeldungen im Browser ohne Verwendung von Service Workers und Push API.
• Aktivitätsfeeds – Soziale Netzwerke und Nachrichtenfeeds mit automatischer Inhaltsaktualisierung beim Erscheinen neuer Beiträge.
• Zusammenarbeit – Google Docs-ähnliche Editoren mit grundlegender Synchronisation von Änderungen zwischen Benutzern.

Der Schlüsselfaktor bei der Wahl von Long Polling ist die Abwärtskompatibilität. Alle HTTP-Clients und -Server unterstützen diese Methode, was sie zu einer universellen Lösung für Echtzeit-Funktionalität ohne zusätzliche Abhängigkeiten macht. Laut HTTP Archive (2024) verwenden etwa 8% aller Websites weiterhin Long Polling für grundlegende Echtzeitfunktionalität.

Long Polling vs Short Polling

Long Polling und Short Polling lösen dasselbe Problem – die Datenlieferung vom Server zum Client – unterscheiden sich jedoch grundlegend in Mechanismus und Effizienz. Short Polling verwendet ein festes Abfrageintervall, bei dem der Client in gleichen Zeitabständen HTTP-Anfragen sendet, unabhängig davon, ob neue Daten auf dem Server erschienen sind.

Short Polling ist einfacher zu implementieren, erzeugt aber bei gleicher Datenaktualisierungsfrequenz eine erheblich höhere Last auf Server und Netzwerk. Wenn eine Latenz von weniger als 5 Sekunden erforderlich ist, generiert Short Polling Dutzende von Anfragen pro Minute, während Long Polling eine Anfrage pro Ereignis oder Timeout verwendet. Für Anwendungen mit seltenen Ereignissen ist Long Polling hinsichtlich des Datenverkehrs um Größenordnungen effizienter.

Long Polling vs WebSocket

WebSocket ist ein vollwertiges bidirektionales Echtzeitprotokoll, das nach einem anfänglichen HTTP-Handshake über TCP arbeitet. Im Gegensatz zu Long Polling stellt WebSocket eine einzige dauerhafte Verbindung her und ermöglicht es dem Server, jederzeit Daten an den Client zu senden, ohne eine neue HTTP-Anfrage zu erstellen.

Die Wahl zwischen Long Polling und WebSocket hängt von mehreren Faktoren ab. Kompatibilität: Long Polling funktioniert über alle Proxys und Firewalls, während WebSocket von Unternehmensnetzwerken blockiert werden kann. Leistung: WebSocket hat einen geringeren Overhead (2 Bytes pro Frame gegenüber vollständigen HTTP-Headern), was bei hoher Nachrichtenfrequenz entscheidend ist. Skalierbarkeit: Long Polling benötigt aufgrund des Haltens vieler Verbindungen mehr Ressourcen auf der Serverseite, während WebSocket eine feste Verbindung pro Sitzung verwendet.

• Long Polling – die beste Wahl für Anwendungen mit niedriger Ereignisfrequenz (1–10 Ereignisse pro Minute), begrenzter Infrastruktur oder der Notwendigkeit, ältere Browser zu unterstützen.
• WebSocket – die optimale Lösung für hochbelastete Echtzeitanwendungen (Börsendaten, Online-Spiele, kollaborative Editoren) mit Hunderten von Nachrichten pro Sekunde.
• Hybrider Ansatz – einige Anwendungen verwenden Long Polling als Fallback für Clients, die WebSocket nicht unterstützen, mit automatischem Protokollwechsel.

Laut Mozilla Developer Network (2024) wird WebSocket von allen modernen Browsern ab den Versionen 2011–2015 unterstützt, aber Unternehmens-Proxys (z. B. Symantec Blue Coat) blockieren es weiterhin in 15–20% der Unternehmensnetzwerke, was Long Polling als Fallback-Lösung relevant hält.