Poll/Push

Kurz: Zwei gegensätzliche Strategien, um Daten aktuell zu halten: Beim Polling fragt der Client regelmäßig aktiv nach neuen Daten, beim Push schickt der Server sie von sich aus, sobald sie verfügbar sind.

Genauer: Polling ist einfach zu implementieren, verschwendet aber Ressourcen, wenn oft “nichts Neues” die Antwort ist. Push-Mechanismen (z. B. WebSockets, Server-Sent Events, Mobile Push Notifications) sind effizienter, brauchen aber eine dauerhafte Verbindung oder einen externen Push-Dienst.

Im Detail

Polling lässt sich weiter unterteilen: Beim “Short Polling” fragt der Client in festem Intervall an (z. B. alle 5 Sekunden), egal ob es Neuigkeiten gibt — einfach, aber ineffizient bei seltenen Updates. “Long Polling” verbessert das: Der Client stellt eine Anfrage, der Server beantwortet sie aber erst, sobald tatsächlich neue Daten vorliegen (oder ein Timeout erreicht ist) — dadurch fühlt es sich für den Nutzer fast wie Push an, technisch bleibt es aber eine Request/Response-Kette.

Echtes Push braucht eine offene, bidirektionale Verbindung, über die der Server jederzeit von sich aus senden kann — WebSockets sind die verbreitetste Lösung dafür im Web, Server-Sent Events (SSE) eine einfachere Variante nur für Server-zu-Client-Push, die auf normalem HTTP aufbaut statt ein eigenes Protokoll zu brauchen. Bei mobilen Apps übernehmen zentrale Push-Dienste (Apple Push Notification Service, Firebase Cloud Messaging) diese Aufgabe, damit nicht jede App einzeln eine eigene Dauerverbindung offen halten muss, was Akku und Bandbreite auf Mobilgeräten deutlich sparen würde.

Abwägung in der Praxis

Die Wahl zwischen beiden Strategien hängt stark davon ab, wie zeitkritisch Aktualität ist und wie oft sich Daten tatsächlich ändern. Ein Dashboard, das Börsenkurse in Echtzeit zeigt, profitiert massiv von Push — bei Short Polling müsste man entweder sehr häufig anfragen (verschwendet Ressourcen bei stabilen Kursen) oder nimmt veraltete Daten in Kauf. Ein E-Mail-Client, der nur alle paar Minuten neue Nachrichten prüfen muss, kommt dagegen mit einfachem Polling gut zurecht, ohne die Komplexität einer Dauerverbindung. Viele reale Systeme kombinieren beide Ansätze: eine initiale Anfrage per Polling, die bei Bedarf auf eine Push-Verbindung “hochgestuft” wird.

Serverseitige Skalierungsfragen

Push-Verbindungen haben auch eine oft unterschätzte serverseitige Kehrseite: Jede offene WebSocket- oder SSE-Verbindung belegt Speicher und einen Datei-Deskriptor auf dem Server, solange sie besteht — bei Millionen gleichzeitiger Nutzer kann das erhebliche Infrastrukturkosten verursachen, während zustandslose Polling-Anfragen sich leichter über viele Server hinweg verteilen (Load-Balancing) lassen, weil jede Anfrage unabhängig von den vorherigen ist.

Siehe auch: Streaming