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

Derzeit implementiere ich dies mit einfachem AJAX, aber dies hat den Nachteil, dass ich regelmäßig auf den Server treffe, wenn ein kurzer Timer verstrichen ist.

Bei der Untersuchung von langen / kurzen Abfragen bin ich auf HTML5-WebSockets gestoßen. Dies scheint einfach zu implementieren zu sein, aber ich bin mir nicht sicher, ob es einige versteckte Nachteile gibt. Ich denke zum Beispiel, 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, eines über das andere zu verwenden? Hat HTML5 WebSockets AJAX Long / Short Polling überflüssig gemacht, oder gibt es zwingende Gründe, AJAX WebSockets vorzuziehen?

WebSockets ist definitiv die Zukunft.

Lange Abfragen sind eine schmutzige Problemumgehung, um zu verhindern, dass wie bei AJAX Verbindungen für jede Anforderung erstellt werden. Lange Abfragen wurden jedoch erstellt, wenn WebSockets nicht vorhanden waren. Aufgrund von WebSockets verschwinden jetzt lange Abfragen.

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

Ich empfehle, WebSockets zu lernen .

Vergleich:

von verschiedenen Kommunikationstechniken im Web

• AJAX - request→ response. 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 - request→ wait→ response. Erstellt eine Verbindung zum Server wie AJAX, hält jedoch eine Keep-Alive-Verbindung für einige Zeit offen (allerdings nicht lange). Während der Verbindung kann der offene Client Daten vom Server empfangen. Der Client muss die Verbindung regelmäßig wieder herstellen, nachdem die Verbindung aufgrund von Zeitüberschreitungen oder Datenausfällen geschlossen wurde. Auf der Serverseite wird es wie AJAX weiterhin wie eine HTTP-Anforderung behandelt, mit der Ausnahme, dass die Antwort auf Anforderung jetzt oder zu einem späteren Zeitpunkt in der Anwendungslogik erfolgt. Unterstützungsdiagramm (vollständig) | Wikipedia

• WebSockets - client↔ server. 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, können Server und Client jederzeit Daten in beide Richtungen austauschen. Es ist effizient, wenn die Anwendung einen häufigen Datenaustausch auf beide Arten erfordert. WebSockets verfügen über einen Datenrahmen, der eine Maskierung für jede vom Client an den Server gesendete Nachricht umfasst, sodass Daten einfach verschlüsselt werden. Unterstützungsdiagramm (sehr gut) | Wikipedia

• WebRTC - peer↔ peer. Transport zum Herstellen der Kommunikation zwischen Clients und transportunabhängig, sodass UDP, TCP oder noch abstraktere Schichten verwendet werden können. Dies wird im Allgemeinen für die Datenübertragung mit hohem Datenvolumen verwendet, z. B. für Video- / Audio-Streaming, bei dem die Zuverlässigkeit zweitrangig ist und einige Frames oder eine Verringerung des Qualitätsfortschritts zugunsten der Antwortzeit und zumindest einer gewissen Datenübertragung geopfert werden können. Beide Seiten (Peers) können Daten unabhängig voneinander aneinander übertragen. Obwohl es völlig unabhängig von zentralisierten Servern verwendet werden kann, erfordert es dennoch eine Möglichkeit zum Austausch von EndPoints-Daten, wobei Entwickler in den meisten Fällen immer noch zentralisierte Server verwenden, um Peers zu "verknüpfen". Dies ist nur erforderlich, um wichtige Daten für den Verbindungsaufbau auszutauschen. Danach ist kein zentraler Server mehr erforderlich. Unterstützungsdiagramm (mittel) | Wikipedia

• Vom Server gesendete Ereignisse - client← server. 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 von Long Polling verwendet wird. Support-Diagramm (gut, außer IE) | Wikipedia

Vorteile:

Der Hauptvorteil der serverseitigen WebSockets besteht darin, dass es sich nicht um eine HTTP-Anforderung (nach dem Handshake) handelt, sondern um ein ordnungsgemäßes nachrichtenbasiertes Kommunikationsprotokoll. Auf diese Weise können Sie enorme Leistungs- und Architekturvorteile erzielen . In node.js können Sie beispielsweise denselben Speicher für verschiedene Socket-Verbindungen gemeinsam nutzen, sodass diese 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 speichern oder sogar sofort zwischen den Sockets erneut veröffentlichen.

Sicherheitsüberlegungen

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 darstellt. Erstens besteht bei AJAX eine höhere Wahrscheinlichkeit für MITM , da jede Anforderung eine neue TCP-Verbindung ist, die über die Internetinfrastruktur geleitet wird. Bei WebSockets ist es nach dem Verbinden weitaus schwieriger, dazwischen abzufangen. Zusätzlich wird eine Frame-Maskierung erzwungen, wenn Daten vom Client zum Server gestreamt werden, sowie eine zusätzliche Komprimierung, die mehr Aufwand für die Datenprüfung erfordert. Alle modernen Protokolle unterstützen sowohl: HTTP als auch HTTPS (verschlüsselt).

PS

Denken Sie daran, dass WebSockets im Allgemeinen einen ganz anderen logischen Ansatz für das Networking verfolgen , eher wie Echtzeitspiele die ganze Zeit und nicht wie http.

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

Für Chat-Anwendungen oder andere Anwendungen, die in ständiger Konversation mit dem Server stehen, WebSocketsist dies die beste Option. Sie können sie jedoch nur WebSocketsmit einem Server verwenden, der sie unterstützt. Dies kann Ihre Verwendung einschränken, wenn Sie die erforderlichen Bibliotheken nicht installieren können. In diesem Fall müssten Sie verwenden Long Polling, um ähnliche Funktionen zu erhalten.

• 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, die möglicherweise darauf wartet, dass Daten verfügbar sind, bevor sie antworten. 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. Somit hält der Browser immer eine ausstehende Anfrage beim Server, 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.

  Traditionell muss eine Webseite eine Anfrage an den Server senden, um neue Daten zu empfangen. 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 innerhalb der Webseite als Ereignisse + Daten 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, sodass Server sowohl HTTP-Verbindungen als auch WebSocket-Verbindungen auf demselben Port verarbeiten können. Sobald die Verbindung hergestellt ist, wechselt die Kommunikation zu einem bidirektionalen Binärprotokoll, das nicht dem HTTP-Protokoll entspricht. Wikipedia