Sollten wir SSE + REST über Websocket bei Verwendung von HTTP / 2 bevorzugen?

8

Bei der Verwendung von Websocket benötigen wir eine dedizierte Verbindung für die bidirektionale Kommunikation. Wenn wir http / 2 verwenden, haben wir eine zweite Verbindung, die vom Server aufrechterhalten wird.

In diesem Fall scheint die Verwendung von Websocket einen unnötigen Overhead einzuführen, da wir mit SSE und regulärer HTTP-Anfrage den Vorteil der bidirektionalen Kommunikation über eine einzelne HTTP / 2-Verbindung haben können.

Was denkst du?

    
Guillaume D. 07.09.2015, 14:17
quelle

3 Antworten

4

Verwendung von zwei Streams in einer gemultiplexten HTTP / 2-TCP-Verbindung (ein Stream für die Server-zu-Client-Kommunikation - Server Sent Events <) / a> (SSE) und ein Stream für Client-zu-Server-Kommunikation und normale HTTP-Kommunikation) im Gegensatz zu zwei TCP-Verbindungen (eine für normale HTTP-Kommunikation und eine für WebSocket) ist nicht einfach zu vergleichen.

Wahrscheinlich wird der Kilometerstand je nach Anwendung variieren.

Über uns? Nun, sicherlich verdoppelt sich die Anzahl der Verbindungen. WebSocket kann jedoch Nachrichten komprimieren, SSE dagegen nicht.

Flexibilität? Wenn die Verbindungen getrennt sind, können sie verschiedene Verschlüsselungen verwenden. HTTP / 2 erfordert in der Regel eine sehr starke Verschlüsselung, was die Leistung beeinträchtigen kann. Auf der anderen Seite benötigt WebSocket kein TLS.

Funktioniert clear-text WebSocket in Mobilfunknetzen? In der Erfahrung, die ich habe, kommt es darauf an. Antivirenprogramme, Anwendungsfirewalls und Mobilfunkbetreiber können den WebSocket-Datenverkehr einschränken oder weniger zuverlässig machen, je nachdem, in welchem ​​Land Sie tätig sind.

API-Verfügbarkeit? WebSocket ist ein breiter angewandter und anerkannter Standard; Zum Beispiel gibt es in Java eine offizielle API ( javax.websocket ) und eine andere ( java.net.websocket ).

Ich denke, SSE ist eine technisch minderwertige Lösung für bidirektionale Web-Kommunikation und als Technologie wurde es nicht sehr populär (keine Standard-APIs, keine Bücher, etc. - im Vergleich zu WebSocket). Ich wäre nicht überrascht, wenn es von HTML5 fallen würde, und ich würde es nicht verpassen, obwohl es eins der ersten zu Implementieren Sie es in Jetty.

Je nachdem, was Sie interessiert, müssen Sie Ihre Benchmarks durchführen oder die Technologie für Ihren speziellen Fall auswerten.

    
sbordet 07.09.2015, 18:07
quelle
1

Aus der Perspektive eines Webentwicklers besteht der Unterschied zwischen Websockets und einer REST-Schnittstelle in der Semantik. REST verwendet ein Anforderungs- / Antwortmodell, bei dem jede Nachricht vom Server die Antwort auf eine Nachricht vom Client ist. WebSockets ermöglichen es andererseits dem Server und dem Client, jederzeit Nachrichten ohne Beziehung zu einer vorherigen Anforderung zu senden.

Welche Technik zu verwenden ist, hängt davon ab, was im Kontext Ihrer Anwendung sinnvoller ist. Sicher, Sie können ein paar Tricks anwenden, um das Verhalten einer Technologie mit der anderen zu simulieren, aber es ist in der Regel am besten, diejenige zu verwenden, die Ihrem Kommunikationsmodell besser entspricht, wenn sie nach dem Buch verwendet wird.

Vom Server gesendete Ereignisse sind eine ziemlich neue Technologie, die noch nicht von allen gängigen Browsern unterstützt wird. Daher ist sie für eine seriöse Webanwendung noch keine Option.

    
Philipp 07.09.2015 14:31
quelle
1

Es hängt sehr davon ab, welche Art von Anwendung Sie implementieren möchten. WebSocket ist besser geeignet, wenn Sie wirklich eine bidirektionale Kommunikation zwischen Server und Client benötigen, aber Sie müssen das gesamte Kommunikationsprotokoll implementieren und es wird möglicherweise nicht von allen IT-Infrastrukturen gut unterstützt (einige Firewalls, Proxy oder Load Balancer unterstützen möglicherweise WebSockets nicht) . Wenn Sie also keine 100% bidirektionale Verbindung benötigen, rate ich Ihnen, SSE mit REST-Anforderungen für zusätzliche Informationen von Client zu Server zu verwenden. Auf der anderen Seite, SSE kommt mit bestimmten Einschränkungen, wie zum Beispiel in Javascript-Implementierung, können Sie nicht Header überschreiben. Die einzige Lösung ist das Übergeben von Abfrageparametern, aber dann kann ein Problem mit der Größenbeschränkung für Abfragezeichenfolgen auftreten. Die Auswahl zwischen SSE und WebSockets hängt also von der Art der zu implementierenden Anwendung ab. Vor ein paar Monaten hatte ich einen Blogpost geschrieben, der Ihnen vielleicht einige Informationen geben könnte: Ссылка . Obwohl wir HTTP2 zu diesem Zeitpunkt nicht berücksichtigt haben, kann dies helfen zu wissen, welche Frage Sie sich stellen müssen.

    
Lorie Pisicchio 08.09.2015 06:58
quelle