Advantages of Websockets over the HTTP fallback transports #1056
Replies: 1 comment
-
Hi, here is how I see it:
WebSocket is nice because it allows dynamic subscriptions. If your use case requires stable set of subscriptions known at connection time - unidirectional HTTP-streaming may be a very good choice (SSE is also good, but HTTP-streaming has some advantages these days - it's POST in browser, supports binary transfer). Your app may require stable set of subscriptions on start, but after some time you will realize that dynamic subscriptions are needed - with WebSocket you can introduce it at any point. Bi-directional protocol also opens a road for easier recovery, built-in protocol features: easier delta compression, presence, join/leave, reconnects - since this all managed with Centrifugal real-time SDKs. But it's also a disadvantage for some devs. That's why Centrifugo supports all these approaches - all come with their own trade-offs. At least Centrifugo users can choose which fits better in the specific case.
It's true, but in practice this overhead is usually not a game changer. At some point in the past me with the team measured the overhead of this and got that we can reduce number of conns on 13% if re-using connections in our app. So it turned out the benefit is not radical. It may vary for different apps of course. Some people are using SharedWorkers to maintain a single WS connection per browser. With Web Locks API implementation is not very hard these days, but still not straightforward. I think in most use cases it does not worth it. Also, as I mentioned - generally WS connections are more lightweight/optimized/tunable than HTTP-based. So benefiting in one place you are losing in another.
I can say for sure that WS conns consume less memory per connection, but generally regarding data transfer from server to client both WS and HTTP should be very comparable. At least in Centrifugo case I can't find the reason why to expect a huge difference. WebSocket transport is default in bidirectional protocol of Centrifugo - for bidirectional protocol it makes the best sense - it allows dynamic subscriptions, have SDKs which hide the complexity of recovery/reconnect, provide RPC over WebSocket (it's actually a game changer for some users because cloud infrastructure adds more latency to HTTP requests from client to server - like CloudFlare for example). For unidirectional transports HTTP-based are just fine and as you mentioned you can have some benefits from HTTP/2 protocol with them. To conclude: everything is trade-off. No ideal transport. And the new one which is being developed these days - WebTransport - comes with its own downsides also. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
First of all, Centrifugo is awesome. Documentation is unbeliavable good. Congrats!
The docs indicates that, as a best practice, instead of publishing new messages via websockets to the server, we should use regular ajax/fetch requests to sending data to our backend (see https://centrifugal.dev/docs/faq#can-i-publish-new-messages-over-a-websocket-connection-from-a-client), and only then use centrifugo to broadcast the realtime updates to the clients.
We really like this approach.
However, this brings the question: if the bi-directional capability of websockets is not being used, should it still be used as the main transport?
Specially because of this:
Users will, very often, have multiple tabs opened.
If websockets transport - the default - creates one new connection per tab, I would estimate that it would need to be multiple times less taxing on the server than the HTTP transports to justify it's usage, because the HTTP transports would share a single connection per browser, instead of a single connection per tab.
Is there any benchmark from Centrifugo regarding this? Do the HTTP transports perform poorly (or are much more taxing on the server) when compared to Websockets to justify it's usage as the default transport?
Beta Was this translation helpful? Give feedback.
All reactions