Was ist Long Polling?

PubNub Developer Relations - Dec 12 '23 - - Dev Community

Was ist Long Polling?

Long Polling wird in Echtzeit-Webanwendungen verwendet, um eine nahezu sofortige Kommunikation zwischen dem Client und dem Webserver zu erreichen. Es ist besonders nützlich in Chat- und Messaging-Anwendungen, bei denen Echtzeit-Updates entscheidend sind.

Bei der herkömmlichen HTTP-Kommunikation sendet der Client eine neue Anfrage an den Server und wartet auf eine Antwort. Dies wird als kurzes Polling bezeichnet. In Echtzeitszenarien ist das kurze Polling jedoch möglicherweise nicht effizient, da es häufige Anfragen an den Server erfordert, was zu unnötigem Netzwerk-Overhead und erhöhter Latenzzeit führt.

Langes Polling hingegen verbessert die Effizienz, indem es die Anfrage für einen längeren Zeitraum offen hält, bis neue Daten verfügbar sind. Der Server hält die Anfrage offen und wartet, bis er neue Informationen an den Client zurücksenden kann. Sobald der Server über neue Daten verfügt, antwortet er dem Client, der dann die Daten verarbeiten und eine neue Long-Polling-Anfrage starten kann.

Durch die Aufrechterhaltung einer langlebigen Verbindung zwischen dem Client und dem Server reduziert Long Polling die Anzahl der Anfragen, minimiert die Latenzzeit und verbessert die Echtzeitkommunikation. Dies macht es ideal für Anwendungsfälle, die eine effektive Technik für den Aufbau skalierbarer und reaktionsschneller Chat- und Messaging-Anwendungen sowie anderer Anwendungen, die Echtzeitdaten nutzen, wie z. B. Spiele, erfordern.

Wie funktioniert Long Polling?

Long Polling ist eine Technik, die in der Echtzeitkommunikation eingesetzt wird, um eine nahezu sofortige Nachrichtenübermittlung zwischen Clients und Servern zu erreichen. Sie ist besonders nützlich bei der Entwicklung von Chat- und Messaging-Anwendungen, bei denen geringe Latenzzeiten und Echtzeit-Updates entscheidend sind.

Traditionell verwenden Webbrowser einen Pull-basierten Ansatz zum Abrufen von Daten von Servern. Der Client sendet eine Anfrage an den Server, der mit den angeforderten Daten antwortet. Dieser Ansatz, der als kurzes Polling bezeichnet wird, kann zu Verzögerungen bei der Kommunikation führen, da der Client wiederholt Anfragen senden muss, um nach Aktualisierungen zu suchen.

Im Gegensatz dazu ist Long Polling ein Push-basierter Ansatz, bei dem der Server Aktualisierungen an den Client sendet, sobald sie verfügbar sind. Und so funktioniert es:

  1. Der Client initiiert eine Anfrage an den Server, in der Regel über eine HTTP-Anfrage.

  2. Anstatt sofort zu antworten, hält der Server die Anfrage offen, so dass die Verbindung aktiv bleibt.

  3. Wenn keine neuen Daten verfügbar sind, wartet der Server, bis er etwas zurücksenden kann.

  4. Sobald der Server neue Daten hat oder eine vordefinierte Zeitüberschreitung eintritt, antwortet er dem Client mit den neuesten Informationen.

  5. Nach Erhalt der Antwort sendet der Client sofort eine weitere Anfrage an den Server, um die Verbindung aufrechtzuerhalten.

  6. Dieser Zyklus des Sendens von Anfragen und Empfangens von Antworten wird fortgesetzt, um Aktualisierungen in Echtzeit zu gewährleisten.

Long Polling simuliert eine Echtzeitverbindung zwischen dem Client und dem Server, indem der Anfrage-Antwort-Zyklus über einen längeren Zeitraum aufrechterhalten wird. So kann der Server Aktualisierungen an den Client weiterleiten, sobald sie verfügbar sind, und der Client muss nicht wiederholt nach Aktualisierungen suchen.

Welche Technologien werden zur Implementierung von Long Polling verwendet?

Long Polling ist eine Technik, mit der eine Echtzeitkommunikation zwischen Client und Server erreicht wird. Sie wird häufig in Chat- und Messaging-Anwendungen eingesetzt, bei denen sofortige Aktualisierungen wichtig sind. Für die Implementierung von Long Polling können verschiedene Technologien verwendet werden, die alle ihre Vorteile haben und zu berücksichtigen sind. Im Folgenden werden einige der gängigen Technologien für die Implementierung von Long Polling vorgestellt.

Langes HTTP-Polling:

Dies ist der einfachste und am weitesten verbreitete Ansatz zur Implementierung von Long Polling. Sie nutzt das HTTP-Protokoll, um eine dauerhafte Verbindung zwischen Client und Server herzustellen und aufrechtzuerhalten. Der Client sendet eine Anfrage an den Server, und der Server hält die Anfrage offen, bis neue Daten verfügbar sind oder eine bestimmte Zeitspanne erreicht ist. Sobald neue Daten verfügbar sind, antwortet der Server mit den aktualisierten Informationen, und der Client sendet sofort eine weitere Anfrage, um den Zyklus fortzusetzen. Dieser Ansatz ist einfach zu implementieren und erfordert keine speziellen serverseitigen Technologien.

WebSocket:

WebSocket ist ein Vollduplex-Kommunikationsprotokoll, das die Echtzeitkommunikation zwischen Client und Server über eine einzige, langlebige Verbindung ermöglicht. Es bietet eine effizientere und latenzärmere Alternative zu langen Abfragen. WebSocket ermöglicht einen bidirektionalen Datenfluss, der es dem Client und dem Server erlaubt, Nachrichten asynchron zu senden. Dadurch werden häufige HTTP-Anfragen überflüssig und der Netzwerk-Overhead reduziert. WebSocket eignet sich gut für Anwendungen, die sofortige Aktualisierungen und Echtzeit-Interaktion erfordern.

Server-gesendete Ereignisse (SSE):

SSE ist eine unidirektionale Kommunikationstechnologie, die es dem Server ermöglicht, Daten über eine einzige, langlebige HTTP-Verbindung an den Client zu senden. Mit SSE kann der Server mehrere Aktualisierungen an den Client senden, ohne dass der Client ständig Anfragen stellen muss. Der Server initiiert die Verbindung und sendet Daten als eine Reihe von Ereignissen. Der Client empfängt diese Ereignisse und kann sie je nach Bedarf verarbeiten.

Bei der Auswahl einer Technologie zur Implementierung von Long Polling in Ihrer Anwendung sind mehrere Faktoren zu berücksichtigen:

  • Skalierbarkeit: Vergewissern Sie sich, dass die gewählte Technologie eine große Anzahl gleichzeitiger Verbindungen bewältigen kann und mit der wachsenden Benutzerbasis mitwachsen kann. WebSocket und SSE sind im Allgemeinen besser skalierbar als HTTP-basiertes Long Polling, da sie eine effizientere Nutzung der Serverressourcen ermöglichen.

  • Sicherheit: Berücksichtigen Sie die Sicherheitsaspekte der gewählten Technologie. WebSocket und SSE können mit Verschlüsselungsprotokollen wie SSL/TLS abgesichert werden, um den Datenschutz und die Datenintegrität zu gewährleisten. HTTP-basierte lange Abrufe können ebenfalls gesichert werden, erfordern aber möglicherweise zusätzliche Authentifizierungs- und Zugangskontrollmaßnahmen.

  • Browser-Unterstützung: Prüfen Sie die Browserkompatibilität der gewählten Technologie. WebSocket und SSE werden von den Browsern besser unterstützt als HTTP-basiertes Long Polling, das bei älteren Browsern zusätzliche Techniken oder Fallback-Optionen erfordern kann.

  • Komplexität der Implementierung: Beurteilen Sie, wie einfach die gewählte Technologie zu implementieren und zu warten ist. HTTP-basiertes Long Polling ist relativ einfach, während WebSocket und SSE möglicherweise fortgeschrittenere Kenntnisse und Infrastrukturen erfordern. Berücksichtigen Sie das in Ihrem Entwicklungsteam vorhandene Fachwissen und die für die Implementierung und Wartung der gewählten Technologie erforderlichen Ressourcen.

Langes Polling vs. WebSockets

Long Polling und WebSockets sind Techniken zur Herstellung einer Echtzeitverbindung zwischen einem Client (z. B. einem Webbrowser) und einem Server. Obwohl sie einem ähnlichen Zweck dienen, gibt es erhebliche Unterschiede zwischen beiden.

Long Polling ist eine Technik, bei der der Client eine Anfrage an den Webserver stellt und der Server die Verbindung offen hält, bis er neue Daten zurücksenden kann. Der Server kann sofort antworten, wenn er neue Daten zur Verfügung hat, oder eine bestimmte Zeitspanne abwarten, bevor er eine leere Antwort sendet. In beiden Fällen stellt der Client, sobald er die Antwort erhält, sofort eine weitere Anfrage an den Server, um eine neue Verbindung herzustellen. Dieser Vorgang wiederholt sich ständig, so dass der Server Aktualisierungen an den Client weiterleiten kann, sobald sie verfügbar sind.

Andererseits bieten WebSockets einen dauerhaften, bidirektionalen Kommunikationskanal zwischen dem Client und dem Server. Im Gegensatz zum Long-Polling, bei dem für jede Anfrage eine neue Verbindung aufgebaut wird, wird eine WebSocket-Verbindung einmal aufgebaut und auf unbestimmte Zeit offen gehalten. Dies ermöglicht eine Echtzeit-Kommunikation mit geringer Latenz in beide Richtungen. Der Server kann jederzeit Daten an den Client senden, und der Client kann ebenfalls Daten an den Server senden, ohne auf eine Antwort zu warten.

Ähnlichkeiten zwischen Long Polling und Web Sockets:

1. Aktualisierungen in Echtzeit: Sowohl Long Polling als auch WebSockets ermöglichen eine Echtzeit-Kommunikation zwischen Server und Client, so dass sofortige Aktualisierungen ohne ständiges Abfragen oder Auffrischen möglich sind.

2. Geringere Serverlast: Beide Techniken minimieren unnötige Anfragen, indem sie Daten nur dann senden, wenn sie verfügbar sind, was die Serverlast verringert und die Skalierbarkeit verbessert.

3. Breite Sprach- und Framework-Unterstützung: Viele gängige Programmiersprachen und Frameworks unterstützen Long Polling und WebSockets und machen sie damit für Entwickler in verschiedenen Ökosystemen zugänglich.

Unterschiede zwischen Long Polling und Web Sockets:

1. Latenzzeit: Long Polling führt zu Latenzzeiten, da es eine Verzögerung zwischen dem Senden einer Antwort durch den Server und dem Empfang durch den Client gibt. WebSockets bieten eine bidirektionale Kommunikation mit geringer Latenz, die eine schnellere Echtzeitfähigkeit ermöglicht.

2. Ressourcenverbrauch: Langes Polling erfordert, dass der Server offene Verbindungen mit jedem Client aufrechterhält, was zu Ressourcenverbrauch führen und die Anzahl der gleichzeitigen Verbindungen begrenzen kann. WebSockets hingegen verwenden eine dauerhafte Verbindung, was den Ressourcenverbrauch insgesamt verringert.

3. Skalierbarkeit: Die Notwendigkeit, Verbindungen für einen längeren Zeitraum offen zu halten, kann eine Herausforderung für die horizontale Skalierung des Servers darstellen. Mit ihrer dauerhaften Verbindung ermöglichen WebSockets eine bessere Skalierbarkeit, da sie nicht viele offene Verbindungen erfordern.

Sowohl Long Polling als auch WebSockets bieten Aktualisierungen in Echtzeit und verringern die Serverlast, unterscheiden sich aber in Bezug auf Latenz, Ressourcenverbrauch und Skalierbarkeit. WebSockets bieten eine schnellere, bidirektionale Kommunikation bei geringerem Ressourcenverbrauch und eignen sich daher für Anwendungen, die eine geringe Latenzzeit und hohe Skalierbarkeit erfordern. Andererseits kann Long Polling eine gute Alternative sein, wenn eine geringe Latenzzeit nicht entscheidend ist und die Anzahl der gleichzeitigen Verbindungen relativ gering ist. Entwickler sollten diese Faktoren bei der Wahl zwischen den beiden Techniken für ihre Echtzeit-Chat- und Messaging-Anwendungen berücksichtigen.

Langes Polling vs. Server-gesendete Ereignisse (SSE)

SSE ist dem Long Polling in Bezug auf seine Einfachheit und leichte Implementierung ähnlich, bietet jedoch eine effizientere und standardisierte Methode für die Kommunikation zwischen Server und Client. Sehen wir uns einige zusätzliche Ähnlichkeiten und Unterschiede zwischen den beiden Technologien an.

Gemeinsamkeiten zwischen Long Polling und SSE:

  1. Aktualisierungen in Echtzeit: Sowohl Long Polling als auch SSE ermöglichen eine Echtzeit-Kommunikation zwischen Server und Client, so dass sofortige Aktualisierungen ohne ständiges Polling oder Refreshing möglich sind.

  2. Geringere Serverlast: Beide Techniken minimieren unnötige Anfragen, indem sie Daten nur dann senden, wenn sie verfügbar sind, was die Serverlast verringert und die Skalierbarkeit verbessert.

  3. Breite Sprach- und Framework-Unterstützung: Viele gängige Programmiersprachen und Frameworks unterstützen Long Polling und SSE und machen sie damit für Entwickler in verschiedenen Ökosystemen zugänglich.

Unterschiede zwischen Long Polling und SSE:

  1. Latenzzeit: Long Polling führt zu Latenzzeiten, da eine Verzögerung zwischen dem Senden einer Antwort durch den Server und dem Empfangen der Antwort durch den Client besteht. SSE hingegen liefert einen kontinuierlichen Datenstrom vom Server zum Client, wodurch die Latenzzeit verringert und die Echtzeitfähigkeit verbessert wird.

  2. Ressourcenverbrauch: Bei einer langen Abfrage muss der Server mit jedem Client eine offene Verbindung aufrechterhalten, was zu einem hohen Ressourcenverbrauch führen kann und die Anzahl der gleichzeitigen Verbindungen begrenzt. SSE hingegen verwendet eine einzige langlebige Verbindung, was den Gesamtressourcenverbrauch reduziert.

  3. Skalierbarkeit: Die Notwendigkeit von Long Polling, Verbindungen über einen längeren Zeitraum offen zu halten, kann eine Herausforderung für die horizontale Skalierung des Servers darstellen. Mit einer einzigen Verbindung pro Client ermöglicht SSE eine bessere Skalierbarkeit, da es nicht viele offene Verbindungen benötigt.

Wie kann man Long Polling optimieren?

Long Polling wird in Echtzeit-Chat- und Messaging-Anwendungen verwendet, um nahezu sofortige Client-Aktualisierungen zu ermöglichen. Es kann jedoch ressourcenintensiv sein und Skalierbarkeitsprobleme verursachen, wenn es nicht richtig optimiert wird. Im Folgenden werden einige Techniken vorgestellt, die zur Optimierung von Long Polling für bessere Leistung und Skalierbarkeit verwendet werden können.

Gepufferte Antworten: Anstatt für jede Anfrage eine Antwort zu senden, können Sie mehrere Aktualisierungen zusammenfassen und in einer einzigen Antwort senden. Dies reduziert die Anzahl der HTTP-Anfragen und hilft, den Overhead zu minimieren.

Komprimierung: Durch Komprimierung der Daten vor dem Versand über das Netz kann die Größe der Nutzlast erheblich reduziert werden, was zu einer schnelleren Übertragung und einem geringeren Bandbreitenverbrauch führt. Techniken wie die Gzip-Komprimierung können hierfür eingesetzt werden.

Caching : Die Implementierung einer Caching-Schicht kann dazu beitragen, die Belastung der Datenbank oder anderer Datenquellen zu verringern. Durch die Zwischenspeicherung häufig angeforderter Daten können nachfolgende Anfragen aus dem Cache selbst bedient werden, was die Antwortzeit verkürzt und die Skalierbarkeit verbessert.

Pooling von Verbindungen: Die Aufrechterhaltung eines Pools wiederverwendbarer Verbindungen anstelle des Aufbaus einer neuen Verbindung für jede Anfrage kann die Effizienz des Long-Polling-Mechanismus verbessern. Dadurch entfällt der Overhead, der durch den Aufbau einer neuen Verbindung für jede Anfrage entsteht, was zu einer besseren Leistung führt.

Drosselung und Ratenbegrenzung: Durch die Implementierung von Drosselungs- und Ratenbegrenzungsmechanismen kann verhindert werden, dass der Server durch übermäßige Anfragen überlastet wird. Dies gewährleistet eine faire Ressourcenzuweisung und verhindert Missbrauch, was die Leistung und Skalierbarkeit verbessert.

Lastausgleich: Die Verteilung der eingehenden Anfragen auf mehrere Server mit Hilfe von Lastausgleichstechniken kann dazu beitragen, die Last zu verteilen und zu verhindern, dass ein einzelner Server überlastet wird. Dies verbessert die Gesamtleistung und Skalierbarkeit des Long Polling Systems.

Überwachung und Optimierung: Die regelmäßige Überwachung der Leistung des Long-Polling-Systems und die Ermittlung von Engpässen oder verbesserungswürdigen Bereichen kann dazu beitragen, das System für eine bessere Leistung und Skalierbarkeit zu optimieren. Techniken wie Profiling, Lasttests und Leistungsoptimierung können eingesetzt werden, um Leistungsprobleme zu erkennen und zu beheben.

Asynchrone Verarbeitung (Async): Das Auslagern zeitaufwändiger Aufgaben auf asynchrone Prozesse oder Hintergrundarbeiter kann dazu beitragen, Ressourcen freizusetzen und die Reaktionsfähigkeit des Long-Polling-Systems zu verbessern. Dies kann über Nachrichtenwarteschlangen, Worker-Prozesse oder verteiltes Rechnen geschehen.

Verbindungs-Timeouts: Durch die Implementierung geeigneter Verbindungs-Timeouts kann verhindert werden, dass ungenutzte Verbindungen unnötig Ressourcen verbrauchen. Indem ungenutzte Verbindungen nach einer bestimmten Zeit der Inaktivität geschlossen werden, kann das System Ressourcen für andere Clients freigeben und die Skalierbarkeit verbessern.

Skalierbare Infrastruktur: Für die Optimierung langer Abfragen ist es entscheidend, dass die zugrunde liegende Infrastruktur skalierbar ist und die erwartete Last bewältigen kann. Dies kann den Einsatz von Technologien wie Cloud Computing, automatische Skalierung oder Containerisierung beinhalten, um Ressourcen dynamisch und bedarfsorientiert zuzuweisen.

Welche Programmiersprachen sind mit Long Polling kompatibel?

Mehrere Programmiersprachen sind mit der Implementierung von Long Polling in Echtzeit-Chat- und Messaging-Anwendungen kompatibel. Hier sind ein paar Beispiele:

  1. JavaScript: Langes Polling wird häufig mit JavaScript kombiniert, was eine nahtlose clientseitige Implementierung ermöglicht. JavaScript-Frameworks wie React, Angular und Vue.js bieten Bibliotheken und Tools, die die Implementierung von Long Polling in Ihrer Anwendung vereinfachen.

  2. PHP: PHP ist eine beliebte serverseitige Sprache, die häufig in der Webentwicklung eingesetzt wird. Sie bietet Funktionen und Bibliotheken, mit denen Entwickler Long Polling effizient implementieren können. Das PHP-Framework Laravel beispielsweise bietet über sein Event-Broadcasting-System Unterstützung für Long Polling.

  3. Python: Python ist eine weitere vielseitige Sprache, die für die Implementierung von Long Polling verwendet werden kann. Python-Frameworks wie Django und Flask bieten die Tools und Bibliotheken für die Entwicklung von Echtzeitanwendungen mit Long-Polling-Techniken.

  4. Ruby: Ruby ist eine dynamische, objektorientierte Programmiersprache, die sich gut für die Webentwicklung eignet. Ein beliebtes Web-Framework, Ruby on Rails, unterstützt Long Polling durch verschiedene Bibliotheken und Erweiterungen.

  5. Java: Java ist eine weit verbreitete Sprache in der Unternehmensentwicklung und bietet Unterstützung für Long Polling. Java-Frameworks wie Spring und Java EE bieten Bibliotheken und Tools für die Implementierung von Long Polling in Echtzeitanwendungen.

  6. .NET/C#: Das .NET-Framework mit seiner Programmiersprache C# wird häufig für die Entwicklung von Webanwendungen verwendet. Es bietet Bibliotheken und Frameworks wie ASP.NET SignalR, die die Implementierung von Long-Polling-Techniken vereinfachen.

Dies sind nur einige Beispiele für Programmiersprachen, die Long Polling unterstützen. Viele andere Sprachen und Frameworks können ebenfalls Long Polling in Echtzeit-Chat- und Messaging-Anwendungen implementieren.

Bei der Auswahl einer Programmiersprache für die Implementierung von Long Polling sind einige Faktoren zu berücksichtigen. Berücksichtigen Sie zunächst die spezifischen Anforderungen Ihrer Anwendung und wählen Sie eine Sprache, die diese Anforderungen am besten erfüllt. Berücksichtigen Sie Skalierbarkeit, Leistung und einfache Implementierung im Backend.

Berücksichtigen Sie auch die Gemeinschaft und das Ökosystem, das die Programmiersprache umgibt. Eine starke und aktive Community kann Unterstützung, Tutorials, Dokumentation und Ressourcen bereitstellen, um die Implementierung von Long Polling in Ihrer Anwendung zu erleichtern.

Wie wird Long Polling in Echtzeitanwendungen eingesetzt?

Einer der Hauptvorteile von Long Polling ist seine Effizienz bei der Bereitstellung von Echtzeit-Updates. Durch die Minimierung der Anzahl der von den Clients gesendeten Anfragen werden die Netzwerklatenzzeiten erheblich reduziert und die Gesamtleistung verbessert. Außerdem können die Server Aktualisierungen sofort an die Clients weiterleiten, wodurch sichergestellt wird, dass Nachrichten und Benachrichtigungen zeitnah zugestellt werden.

Außerdem erleichtert ein langes Polling die Skalierbarkeit von Echtzeitanwendungen. Durch die Verringerung der Anzahl offener Verbindungen können die Server mehr gleichzeitige Clients bedienen. Dies ist besonders wichtig bei Chat- und Messaging-Anwendungen, bei denen die Zahl der Nutzer ständig schwankt.

Langes Polling hilft, Systemressourcen zu sparen. Beim herkömmlichen Polling muss der Server jede Anfrage verarbeiten und beantworten, selbst wenn keine Aktualisierungen vorliegen. Diese ständige Verarbeitung kann die Serverressourcen belasten und die Leistung beeinträchtigen. Im Gegensatz dazu löst Long Polling die Serververarbeitung nur dann aus, wenn neue Daten verfügbar sind oder eine Zeitüberschreitung auftritt. Dies minimiert die Belastung der Systemressourcen und ermöglicht eine bessere Skalierbarkeit und Zuverlässigkeit.

Die Implementierung von Long Polling kann jedoch auch einige Herausforderungen mit sich bringen. Eine Herausforderung ist die effektive Verwaltung der Serverressourcen. Da beim Long Polling die Verbindungen über einen längeren Zeitraum offen gehalten werden, erfordert die Verarbeitung mehrerer gleichzeitiger Verbindungen erhebliche Serverressourcen. Diesem Problem kann mit Technologien wie Cloud Computing, automatischer Skalierung oder Containerisierung begegnet werden, um Ressourcen dynamisch und bedarfsgerecht zuzuweisen. Durch die automatische Skalierung von Ressourcen auf der Grundlage der Anzahl aktiver Verbindungen können Entwickler sicherstellen, dass der Server die erwartete Last effektiv bewältigen kann.

Eine weitere Herausforderung ist der Umgang mit Zeitüberschreitungen und Verbindungsfehlern. Bei langen Abfragen hält der Server die Anfrage offen, bis neue Daten verfügbar sind oder eine Zeitüberschreitung auftritt. Tritt eine Zeitüberschreitung ein, muss der Server dies angemessen behandeln und die Verbindung schließen, um Ressourcen freizugeben. Darüber hinaus sollte der Server in der Lage sein, eine fehlgeschlagene Verbindung zu erkennen und Wiederverbindungsversuche entsprechend zu behandeln. Durch die Implementierung robuster Mechanismen für die Fehlerbehandlung und die Verbindungsverwaltung können Entwickler die Zuverlässigkeit von langen Abfragen in Echtzeitanwendungen sicherstellen.

Die Sicherheit ist ein weiterer wichtiger Aspekt bei der Implementierung von Long Polling in Echtzeitanwendungen. Da bei Long Polling dauerhafte Verbindungen zwischen Clients und Servern aufrechterhalten werden müssen, ist es wichtig, diese Verbindungen zu sichern, um sensible Daten zu schützen. Die Implementierung von Secure Socket Layers (SSL) oder Transport Layer Security (TLS) Protokollen kann dazu beitragen, die über Long Polling-Verbindungen übertragenen Daten zu verschlüsseln und das Abhören oder den unbefugten Zugriff zu verhindern.

Mit über 15 Präsenzpunkten weltweit, die 800 Millionen monatlich aktive Nutzer unterstützen, und einer Zuverlässigkeit von 99,999 % müssen Sie sich keine Sorgen über Ausfälle, Gleichzeitigkeitsgrenzen oder Latenzprobleme aufgrund von Verkehrsspitzen machen. PubNub ist perfekt für jede Anwendung, die Echtzeitdaten benötigt.

Melden Sie sich für eine kostenlose Testversion an und Sie erhalten bis zu 200 MAUs oder 1 Mio. Gesamttransaktionen pro Monat inklusive.

Wie kann PubNub Ihnen helfen?

Dieser Artikel wurde ursprünglich auf PubNub.com veröffentlicht.

Unsere Plattform hilft Entwicklern bei der Erstellung, Bereitstellung und Verwaltung von Echtzeit-Interaktivität für Webanwendungen, mobile Anwendungen und IoT-Geräte.

Die Grundlage unserer Plattform ist das größte und am besten skalierbare Echtzeit-Edge-Messaging-Netzwerk der Branche. Mit über 15 Points-of-Presence weltweit, die 800 Millionen monatlich aktive Nutzer unterstützen, und einer Zuverlässigkeit von 99,999 % müssen Sie sich keine Sorgen über Ausfälle, Gleichzeitigkeitsgrenzen oder Latenzprobleme aufgrund von Verkehrsspitzen machen.

PubNub erleben

Sehen Sie sich die Live Tour an, um in weniger als 5 Minuten die grundlegenden Konzepte hinter jeder PubNub-gestützten App zu verstehen

Einrichten

Melden Sie sich für einen PubNub-Account an und erhalten Sie sofort kostenlosen Zugang zu den PubNub-Schlüsseln

Beginnen Sie

Mit den PubNub-Dokumenten können Sie sofort loslegen, unabhängig von Ihrem Anwendungsfall oder SDK

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .