it-swarm.com.de

In welchen Situationen wird AJAX long / short polling gegenüber HTML5 WebSockets bevorzugt?

Ich erstelle eine kleine Chat-Anwendung für Freunde, bin mir aber nicht sicher, wie ich rechtzeitig Informationen erhalten kann, die nicht so manuell oder rudimentär sind wie das Erzwingen einer Seitenaktualisierung.

Derzeit implementiere ich dies mit einfachem AJAX. Dies hat jedoch den Nachteil, dass der Server regelmäßig angesprochen wird, wenn ein kurzer Timer abgelaufen ist.

Bei der Suche nach langen und kurzen Abfragen bin ich auf HTML5-WebSockets gestoßen. Dies scheint einfach zu implementieren, aber ich bin nicht sicher, ob es einige versteckte Nachteile gibt. Ich denke beispielsweise, dass WebSockets nur von bestimmten Browsern unterstützt wird. Gibt es andere Nachteile von WebSockets, die ich beachten sollte?

Da es so aussieht, als ob beide Technologien dasselbe tun, in welchen Szenarien würde man es vorziehen, eine über die andere zu stellen? Konkret: Hat HTML5 WebSockets AJAX long/short polling obsolet gemacht, oder gibt es zwingende Gründe, AJAX gegenüber WebSockets vorzuziehen?

293
somdow

WebSockets ist definitiv die Zukunft.

Langes Polling ist eine fehlerhafte Umgehung, um zu verhindern, dass Verbindungen für jede Anforderung erstellt werden, wie dies bei AJAX) der Fall ist. Langes Polling wurde jedoch erstellt, als WebSockets nicht vorhanden war. Aufgrund von WebSockets wird jetzt kein langes Polling mehr durchgeführt.

WebRTC ermöglicht Peer-to-Peer-Kommunikation.

Ich empfehle zu lernen WebSockets .

Vergleich:

von verschiedenen Kommunikationstechniken im Web

  • AJAX - requestresponse. Erstellt eine Verbindung zum Server, sendet Anforderungsheader mit optionalen Daten, erhält eine Antwort vom Server und schließt die Verbindung. Wird in allen gängigen Browsern unterstützt.

  • Lange Umfrage - requestwaitresponse. Erstellt eine Verbindung zum Server wie AJAX), behält jedoch eine Verbindung bei, die noch einige Zeit (jedoch nicht lange) geöffnet ist. Während der Verbindung kann der geöffnete Client Daten vom Server empfangen Der Client muss sich aufgrund von Zeitüberschreitungen oder Datenverlust regelmäßig nach dem Schließen der Verbindung erneut verbinden. Auf der Serverseite wird die Verbindung weiterhin wie eine HTTP-Anforderung behandelt, ebenso wie AJAX, mit der Ausnahme, dass die Antwort auf Anforderung jetzt oder zu einem festgelegten späteren Zeitpunkt erfolgt von der Anwendungslogik. Support Chart (voll) | wikipedia

  • WebSockets - clientserver. Erstellen Sie eine TCP Verbindung zum Server und lassen Sie diese so lange wie nötig geöffnet. Der Server oder Client kann die Verbindung problemlos schließen. Der Client durchläuft einen HTTP-kompatiblen Handshake-Prozess. Wenn dies erfolgreich ist, Dann können Server und Client jederzeit Daten in beide Richtungen austauschen. Es ist effizient, wenn die Anwendung einen häufigen Datenaustausch in beide Richtungen erfordert. WebSockets verfügen über ein Datenframing, das eine Maskierung für jede vom Client an den Server gesendete Nachricht umfasst verschlüsselt. Support Chart (sehr gut) | wikipedia

  • WebRTC - peerpeer. Transport, um die Kommunikation zwischen Clients herzustellen, ist transportunabhängig und kann daher UDP, TCP oder noch abstraktere Ebenen verwenden. Dies wird im Allgemeinen für die Übertragung von Daten mit hohem Volumen verwendet, z. B. Video-/Audio-Streaming Wenn die Zuverlässigkeit zweitrangig ist und ein paar Frames oder eine Verringerung des Qualitätsfortschritts zu Gunsten der Reaktionszeit und zumindest einer gewissen Datenübertragung geopfert werden müssen, können beide Seiten (Peers) Daten unabhängig voneinander pushen Unabhängig von zentralisierten Servern ist immer noch eine Möglichkeit zum Austausch von Endpunktdaten erforderlich, wobei Entwickler in den meisten Fällen noch zentralisierte Server verwenden, um Peers zu "verbinden". Dies ist nur erforderlich, um wichtige Daten für den Verbindungsaufbau auszutauschen, nach denen sich ein zentralisierter Server befindet nicht erforderlich. Support Chart (mittel) | wikipedia

  • Vom Server gesendete Ereignisse - clientserver. Der Client stellt eine dauerhafte und langfristige Verbindung zum Server her. Nur der Server kann Daten an einen Client senden. Wenn der Client Daten an den Server senden möchte, muss dazu eine andere Technologie/ein anderes Protokoll verwendet werden. Dieses Protokoll ist HTTP-kompatibel und auf den meisten serverseitigen Plattformen einfach zu implementieren. Dies ist ein bevorzugtes Protokoll, das anstelle des langen Abrufs verwendet wird. Support Chart (gut, außer IE) | wikipedia

Vorteile:

Der Hauptvorteil von WebSockets serverseitig ist, dass es sich nicht um eine HTTP-Anforderung (nach dem Handshake) handelt, sondern um ein ordnungsgemäßes nachrichtenbasiertes Kommunikationsprotokoll. Dies ermöglicht es Ihnen, enorme Leistungs- und Architekturvorteile zu erzielen. In node.js können Sie beispielsweise denselben Speicher für verschiedene Socket-Verbindungen gemeinsam nutzen, sodass sie jeweils auf gemeinsam genutzte Variablen zugreifen können. Daher müssen Sie keine Datenbank als Austauschpunkt in der Mitte verwenden (wie bei AJAX oder Long Polling mit einer Sprache wie PHP). Sie können Daten im RAM oder sogar speichern sofort zwischen den Sockets neu veröffentlichen.

Sicherheitsaspekte

Menschen sind oft besorgt über die Sicherheit von WebSockets. Die Realität ist, dass es kaum einen Unterschied macht oder sogar WebSockets als bessere Option einsetzt. Zuallererst gibt es mit AJAX eine höhere Wahrscheinlichkeit von MITM , da jede Anfrage eine neue TCP Verbindung ist, die Bei WebSockets ist das Abfangen von Daten nach dem Herstellen der Verbindung viel schwieriger, da die Frame-Maskierung beim Streaming von Daten vom Client zum Server zusätzlich erzwungen wird und zusätzliche Komprimierung erforderlich ist, um die Daten zu prüfen. Alle modernen Protokolle unterstützen sowohl HTTP als auch HTTPS (verschlüsselt).

P.S.

Denken Sie daran, dass WebSockets im Allgemeinen eine ganz andere Logik für die Vernetzung haben, eher wie Echtzeitspiele die ganze Zeit und nicht wie http.

497
moka

Eine konkurrierende Technologie, die Sie ausgelassen haben, ist Server-Sent Events/Event Source. Was sind Long-Polling, Websockets, Server-Sent-Ereignisse (SSE) und Comet? enthält eine gute Diskussion über all dies. Denken Sie daran, dass einige davon leichter als andere auf der Serverseite zu integrieren sind.

11
bmm6o

Für Chat-Anwendungen oder andere Anwendungen, die ständig mit dem Server kommunizieren, ist WebSockets die beste Option. Sie können WebSockets jedoch nur mit einem Server verwenden, der sie unterstützt. Dies kann Ihre Verwendungsmöglichkeiten einschränken, wenn Sie die erforderlichen Bibliotheken nicht installieren können. In diesem Fall müssten Sie Long Polling, um ähnliche Funktionen zu erhalten.

7
Brant Olsen

XHR polling vs SSE vs WebSockets

  • XHR-Abfrage Eine Anfrage wird beantwortet, wenn das Ereignis eintritt (kann sofort oder nach einer Verzögerung erfolgen). Nachfolgende Anfragen müssen gestellt werden, um weitere Ereignisse zu erhalten.

    Der Browser sendet eine asynchrone Anforderung an den Server. Dieser wartet möglicherweise, bis Daten verfügbar sind, bevor er antwortet. Die Antwort kann codierte Daten (normalerweise XML oder JSON) oder Javascript enthalten, die vom Client ausgeführt werden sollen. Am Ende der Verarbeitung der Antwort erstellt und sendet der Browser eine weitere XHR, um auf das nächste Ereignis zu warten. Der Browser hält also immer eine Anfrage beim Server offen, die bei jedem Ereignis beantwortet werden muss. Wikipedia

  • Vom Server gesendete Ereignisse Der Client sendet eine Anfrage an den Server. Der Server sendet jederzeit neue Daten an die Webseite.

    Üblicherweise muss eine Webseite eine Anfrage an den Server senden, um neue Daten zu erhalten. Das heißt, die Seite fordert Daten vom Server an. Bei vom Server gesendeten Ereignissen kann ein Server jederzeit neue Daten an eine Webseite senden, indem er Nachrichten an die Webseite sendet. Diese eingehenden Nachrichten können als Ereignisse + Daten innerhalb der Webseite behandelt werden. Mozilla

  • WebSockets Nach dem ersten Handshake (über das HTTP-Protokoll). Die Kommunikation erfolgt bidirektional über das WebSocket-Protokoll.

    Der Handshake beginnt mit einer HTTP-Anforderung/-Antwort, die es Servern ermöglicht, HTTP-Verbindungen sowie WebSocket-Verbindungen auf demselben Port zu verarbeiten. Sobald die Verbindung hergestellt ist, wechselt die Kommunikation zu einem bidirektionalen Binärprotokoll, das nicht dem HTTP-Protokoll entspricht. Wikipedia

0
JSON C11