Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Should we prefer SSE + REST over websocket when using HTTP/2?

When using websocket, we need a dedicated connection for bidirectionnel communication. If we use http/2 we have a second connection maintained by the server.

In that case, using websocket seems to introduce an unecessary overhead because with SSE and regular http request we can have the advantage of bidirectionnal communication over a single HTTP/2 connection.

What do you think?

like image 290
Guillaume D. Avatar asked Sep 07 '15 14:09

Guillaume D.


People also ask

Is SSE better than WebSockets?

SSE is best used when it's not necessary to send data from client to server. For example, in status updates and push notification applications, the data flow is from the server to the client only. This is what SSE is designed for, so WebSocket would be overkill. It's always wise to use the best tool for the job.

Will WebSocket survive HTTP 2?

The answer is no. The goal between the two are very different. There is even an RFC for WebSocket over HTTP/2 which allows you to make multiple WebSocket connections over a single HTTP/2 TCP pipe.

Does HTTP 2 support WebSockets?

Our dashboard is made of a lot of components, each one issuing one or more requests at the same time; multiplexing makes it possible for several requests to coexist on a single TCP connection, thus reducing resources usage and response times. But then you notice that HTTP/2 does not support WebSockets (ouch).

Is REST faster than WebSocket?

Fast Reaction Time WebSockets allow for a higher amount of efficiency compared to REST because they do not require the HTTP request/response overhead for each message sent and received.


3 Answers

Using 2 streams in one multiplexed HTTP/2 TCP connection (one stream for server-to-client communication - Server Sent Events (SSE), and one stream for client-to-server communication and normal HTTP communication) versus using 2 TCP connections (one for normal HTTP communication and one for WebSocket) is not easy to compare.

Probably the mileage will vary depending on applications.

Overhead ? Well, certainly the number of connections doubles up. However, WebSocket can compress messages, while SSE cannot.

Flexibility ? If the connections are separated, they can use different encryptions. HTTP/2 typically requires very strong encryption, which may limit performance. On the other hand, WebSocket does not require TLS.

Does clear-text WebSocket work in mobile networks ? In the experience I have, it depends. Antiviruses, application firewalls, mobile operators may limit WebSocket traffic, or make it less reliable, depending on the country you operate.

API availability ? WebSocket is a wider deployed and recognized standard; for example in Java there is an official API (javax.websocket) and another is coming up (java.net.websocket).

I think SSE is a technically inferior solution for bidirectional web communication and as a technology it did not become very popular (no standard APIs, no books, etc - in comparison with WebSocket). I would not be surprised if it gets dropped from HTML5, and I would not miss it, despite being one of the first to implement it in Jetty.

Depending on what you are interested in, you have to do your benchmarks or evaluate the technology for your particular case.

like image 126
sbordet Avatar answered Nov 13 '22 02:11

sbordet


From the perspective of a web developer, the difference between Websockets and a REST interface is semantics. REST uses a request/response model where every message from the server is the response to a message from the client. WebSockets, on the other hand, allow both the server and the client to push messages at any time without any relation to a previous request.

Which technique to use depends on what makes more sense in the context of your application. Sure, you can use some tricks to simulate the behavior of one technology with the other, but it is usually preferably to use the one which fits your communication model better when used by-the-book.

Server-sent events are a rather new technology which isn't yet supported by all major browsers, so it is not yet an option for a serious web application.

like image 34
Philipp Avatar answered Nov 13 '22 02:11

Philipp


It depends a lot on what kind of application you want to implement. WebSocket is more suitable if you really need a bidirectional communication between server and client, but you will have to implement all the communication protocol and it might not be well supported by all IT infrastructures (some firewall, proxy or load balancers may not support WebSockets). So if you do not need a 100% bidirectional link, I would advise to use SSE with REST requests for additional information from client to server. But on the other hand, SSE comes with certain caveats, like for instance in Javascript implementation, you can not overwrite headers. The only solution is to pass query parameters, but then you can face an issue with the query string size limit. So, again, choosing between SSE and WebSockets really depends on the kind of application you need to implement. A few months ago, I had written a blog post that may give you some information: http://streamdata.io/blog/push-sse-vs-websockets/. Although at that time we didn't consider HTTP2, this can help know what question you need to ask yourself.

like image 32
Lorie Pisicchio Avatar answered Nov 13 '22 01:11

Lorie Pisicchio