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.
quelle
Für Chat-Anwendungen oder andere Anwendungen, die in ständiger Konversation mit dem Server stehen,
WebSockets
ist dies die beste Option. Sie können sie jedoch nurWebSockets
mit 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 verwendenLong Polling
, um ähnliche Funktionen zu erhalten.quelle
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.
Vom Server gesendete Ereignisse Der Client sendet eine Anfrage an den Server. Der Server sendet jederzeit neue Daten an die Webseite.
WebSockets Nach dem ersten Handshake (über das HTTP-Protokoll). Die Kommunikation erfolgt bidirektional über das WebSocket-Protokoll.
quelle