it-swarm.com.de

Was ist der Nachteil der Verwendung von websocket/socket.io, wo Ajax tun wird?

Ähnliche Fragen wurden bereits gestellt und alle kamen zu dem Schluss, dass AJAX nicht überholt sein wird. Aber inwiefern ist Ajax besser als Websockets?

Mit socket.io kann leicht auf Flash oder lange Abfragen zurückgegriffen werden, sodass die Browserkompatibilität kein Problem darstellt.

Websockets sind bidirektional. Wenn Ajax eine asynchrone Anforderung stellt, sendet der Websocket-Client eine Nachricht an den Server. Die POST/GET-Parameter können in JSON codiert werden.

Was ist also falsch daran, 100% Websockets zu verwenden? Wenn jeder Besucher eine dauerhafte Websocket-Verbindung zum Server aufrechterhält, wäre dies sinnloser, als während der gesamten Besuchssitzung ein paar Ajax-Anforderungen zu stellen?

43
oCpmture

Ich denke, es wäre verschwenderischer. Für jeden verbundenen Client benötigen Sie eine Art Objekt/Funktion/Code/was auch immer auf dem Server mit diesem einen Client gekoppelt ist. Ein Socket-Handler oder ein Dateideskriptor oder ein anderer Server ist so eingerichtet, dass er die Verbindungen handhabt.

Mit AJAX benötigen Sie keine 1: 1-Zuordnung der serverseitigen Ressource zum Client. Ihre Anzahl von Clients kann weniger abhängig skaliert werden als Ihre serverseitigen Ressourcen. Sogar node.js hat Einschränkungen, wie viele Verbindungen es verarbeiten und offenhalten kann.

Die andere Sache, die zu beachten ist, ist, dass bestimmte AJAX Antworten auch zwischengespeichert werden können. Beim Skalieren können Sie einen HTTP-Cache hinzufügen, um die Last durch häufige AJAX -Anfragen zu reduzieren.

30
futuremint

Kurze Antwort
Das Aufrechterhalten eines Websockets ist sowohl für den Client als auch für den Server mit Kosten verbunden, ob Ajax nur einmalige Kosten verursacht, je nachdem, was Sie damit tun.

Lange Antwort
Websockets werden oft missverstanden, weil "Hey, Ajax verwenden, das reicht!". Nein, Websockets sind kein Ersatz für Ajax. Sie können möglicherweise auf dieselben Felder angewendet werden, es gibt jedoch Fälle, in denen die Verwendung von Websocket absurd ist. 

Nehmen wir ein einfaches Beispiel: Eine dynamische Seite, die Daten lädt, nachdem die Seite auf der Clientseite geladen wurde. Es ist ganz einfach, einen Ajax-Anruf zu tätigen. Wir brauchen nur eine Richtung, vom Server zum Client. Der Client fragt nach diesen Daten, der Server sendet sie an den Client. Warum sollten Sie Websockets für eine solche Aufgabe implementieren? Sie brauchen nicht, dass Ihre Verbindung ständig geöffnet wird. Sie benötigen nicht, dass der Client den Server ständig fragt. Sie brauchen den Server nicht, um den Client zu benachrichtigen. Die Verbindung bleibt geöffnet, es verschwendet Ressourcen, denn um eine Verbindung offen zu halten, müssen Sie sie ständig überprüfen. 

Für eine Chat-Anwendung sind die Dinge jetzt völlig anders. Ihr Client muss vom Server benachrichtigt werden, anstatt den Client dazu zu zwingen, den Server alle x Sekunden oder Millisekunden zu fragen, ob etwas Neues vorliegt. Es würde keinen Sinn ergeben. 

Um es besser zu verstehen, sehen Sie das als zwei Personen. Einer der beiden ist der Server, der Over ist der Client. Ajax ist wie das Senden eines Briefes. Der Client sendet einen Brief, der Server antwortet mit einem anderen Brief. Tatsache ist, dass die Konversation für eine Chat-Anwendung so wäre:
"Hey Server, hast du was für mich?
- Nein.
- Hey Server, hast du was für mich?
- Nein.
- Hey Server, hast du was für mich?
- Ja hier ist es."
Der Server kann tatsächlich keinen Brief an den Client senden, wenn der Client nie nach einer Antwort gefragt hat. Es ist eine riesige Verschwendung von Ressourcen. Denn für jede Ajax-Anfrage müssen Sie, selbst wenn sie zwischengespeichert wird, eine Operation auf der Serverseite durchführen. 

Nun den Fall, den ich zuvor mit den mit Ajax geladenen Daten besprochen habe. Stellen Sie sich vor, der Client telefoniere mit dem Server. Die Verbindung aktiv zu halten, hat Kosten. Es kostet Strom und Sie müssen Ihren Betreiber bezahlen. Warum sollten Sie jemanden anrufen und ihn eine Stunde lang telefonieren lassen, wenn Sie möchten, dass diese Person Ihnen nur 3 Wörter sagt? Senden Sie einen gottverdammten Brief. 

Fazit: Websockets sind kein totaler Ersatz für Ajax!
Manchmal werden Sie brauchen Ajax, wenn die Verwendung von Websocket absurd ist. 

Bearbeiten: Der Fall SSE
Diese Technologie wird nicht sehr häufig eingesetzt, kann aber nützlich sein. Server-Sent Events sind, wie der Name schon sagt, ein unidirektionaler Push vom Server zum Client. Der Client fordert nichts an, der Server sendet nur die Daten. 

Zusamenfassend :
- Unidirektional vom Kunden: Ajax
- Unidirektional vom Server: SSE
- Bidirektional: Websockets 

20
Depado

Ich persönlich denke, dass Websockets statt in AJAX immer mehr in Webanwendungen verwendet werden. Sie sind nicht gut geeignet für Websites , bei denen Caching und SEO von größter Bedeutung sind, aber für Webapps Wunder bewirken.

Projekte wie DNode und Socketstream helfen, die Komplexität zu beseitigen und eine einfache Codierung im RPC-Stil zu ermöglichen. Das heißt, Ihr Client-Code ruft einfach eine Funktion auf dem Server auf und leitet die Daten an die gewünschte Funktion weiter. Und der Server kann eine Funktion auf dem Client aufrufen und auch Daten übergeben. Sie müssen sich nicht mit den kleinen Kicks von TCP beschäftigen.

Darüber hinaus gibt es bei AJAX-Aufrufen viel Aufwand. Beispielsweise muss eine Verbindung hergestellt werden und mit jeder Anforderung werden HTTP-Header (Cookies usw.) übergeben. Websockets eliminieren viel davon. Einige sagen, Websockets seien verschwenderischer, und vielleicht haben sie recht. Aber ich bin nicht überzeugt, dass der Unterschied wirklich so groß ist.

Ich habe eine weitere verwandte Frage ausführlich beantwortet, einschließlich vieler Links zu verwandten Ressourcen. Sie könnten es überprüfen:

websocket api um rest api zu ersetzen?

18
Tauren

Ich denke, früher oder später werden auf Websocket basierende Frameworks nicht nur für das Schreiben von Echtzeit-Chats wie Teilen von Web-Apps, sondern auch als eigenständige Web-Frameworks angezeigt. Sobald eine permanente Verbindung hergestellt ist, kann sie zum Empfangen aller Arten von Dingen verwendet werden, einschließlich UI-Teilen einer Webanwendung, die jetzt beispielsweise durch AJAX -Anforderungen bedient werden. Dieser Ansatz kann SEO in gewisser Weise schaden, obwohl er die durch asynchrone Anforderungen erzeugte Verkehrsmenge und Last reduzieren kann, die redundante HTTP-Header enthält.

Ich bezweifle jedoch, dass Websockets AJAX ersetzen oder gefährden, da es zahlreiche Szenarien gibt, in denen permanente Verbindungen unnötig oder unerwünscht sind. Zum Beispiel Mashup-Anwendungen, die (einmalig) auf einem einzigen Zweck basierende REST -Dienste verwenden, die nicht permanent mit Clients verbunden sein müssen.

6
yojimbo87

Daran ist nichts "falsch".

Der einzige Unterschied ist meistens die Lesbarkeit. Der Hauptvorteil von Ajax ist die schnelle Entwicklung, da die meisten Funktionen für Sie geschrieben werden.

Der Vorteil besteht darin, dass Sie das Rad nicht jedes Mal neu erfinden müssen, wenn Sie eine Steckdose öffnen möchten.

4
Yochai Timmer

WS: // -Verbindungen haben weit weniger Aufwand als "AJAX" -Anfragen. 

2
BingeBoy

Wenn Sie möchten, dass die Verbindung zum Server geöffnet ist und wenn fortlaufende Abfragen zum Server vorhanden sind, sollten Sie sich für Sockets entscheiden. Andernfalls können Sie ajax verwenden.

Einfache Analogie: Ajax stellt Fragen (Anfragen) an Server und Server und gibt Antworten (Antworten) auf diese Fragen. Wenn Sie nun fortlaufende Fragen stellen möchten, funktioniert ajax nicht, es hat einen großen Aufwand, der Ressourcen an beiden Enden erfordert.

1

Wie andere Leute sagten, kann das Offenhalten der Verbindung in einigen Szenarien übertrieben sein, in denen Sie keine Server-zu-Client-Benachrichtigungen benötigen oder die Anforderung von Client zu Server mit geringer Frequenz abläuft.

Ein weiterer Nachteil ist, dass es sich bei websockets um ein Protokoll auf niedriger Ebene handelt, das TCP keine zusätzlichen Funktionen bietet, sobald der anfängliche Handshake ausgeführt wird. Wenn Sie also ein Request-Response-Paradigma über Websockets implementieren, werden Sie wahrscheinlich Funktionen vermissen, die HTTP (eine sehr ausgereifte und umfangreiche Protokollfamilie) bietet , wie Caching (Client- und gemeinsam genutzte Caches), Validierung (bedingte Anforderungen), Sicherheit und Idempotenz (mit Auswirkungen auf das Verhalten des Agenten), Bereichsanforderungen, Inhaltstypen, Statuscodes, ...

Das heißt, Sie reduzieren die Nachrichtengröße zu einem hohen Preis.

Meine Wahl ist also AJAX für Request-Response, Websockets für Server-Pushing und Hochfrequenz-Low-Latency-Messaging

1
idelvall