使用HTTP / 2时，我们是否应该优先选择SSE + REST而不是websocket？

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.