This is a "design" or a "best-practices" theoretical question.
Most commonly web apps that use websocket connections use at most one websocket connection. However, there are no limitations for a web app to use more e.g. 10. More websocket connections might be chosen for data separation or clean code use cases (obviously there's more).
My question is - Is there a significant difference (in terms of performance, uptime, etc.) between having a one open websocket and having, let's say, ten open websockets in your webapp?
Also, imagine these two architectures. In the upper one the webapp opens as many websocket connections as it needs. In the lower one the webapp has always only one websocket connection to a "proxy" server and that "proxy" server opens websocket connections to as many endpoints as needed.
Question - Could you point some theoretical (practical) insights of why would one choose one architecture over the other? P.S. the lower one seems to be over-complicated.
Thank you!
Related
The architecture I have is that clients receive events from a service through websockets. We are building another service which also needs to communicate it's events to the clients. We are faced with a design decision - whether to change existing service or just add another websocket connection from client to new service.
It is technically complex and expensive to change the other service as it's not maintained by us, but at the end of the day, if necessary, it is possbile. Adding another connection to new service would be cheap and no redesign would be needed, but it would imply that there would be two connections in parallel.
Other questions i've looked at often get answers from server perspective, where TCP connections are limited and thus it's important to reduce the amount of connections, but it's obviously not applicable here, since it's two separate services. What i'm asking is that how big of a difference it is from a client perspective that instead of a single websocket connection there would be multiple connections? My view on this has been that our goal should be to use the same connection as each connection reduces performance, but to be honest it's just an opinion and not a proven fact.
Since it's enterprise setting, backwards compatibility and performance is highly important, but at the same time, development cost is way higher if we'd choose to go with one connection instead of two. So.. is there a real difference or it's something I should not worry about?
From a client perspective, on any modern platform, the difference in cost of managing one vs two sockets in an application or browser should be negligible. It sounds to me like simplifying development and maintenance effort should dominate your decision.
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?
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.
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.
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.
I am redesigning a web application which previously has been rendered server side to a Single Page Application and started to read about websockets . The web application will be using sockets to have new records and/or messages pushed to the client. I have been wondering why most pages which make use of sockets don't handle all their communication over the socket. Most of the times there is RESTful backend in addition to the websocket. Would it be a bad idea to have the client query for new resources over the socket? If so why - other than that a RESTful api might be easier to use with other devices?
I can imagine that using websockets would probably not be the best idea in case the network connection is kind of bad like on mobile devices, but that probably should work quite well with a reasonable connection to the web.
I found this related question, however it is from 2011 and seems a little outdated:
websocket api to replace rest api?
No, it won´t be a bad idea. Actually I work in an application that uses a WebSocket connection for all what is data interaction, the web server only handles requests for resources, views under different languages, dimensions .. etc..
The problem may be the lack of frameworks/tools based on a persistent connection. For many years most of frameworks, front and back end, have been designed and built around the request/response model. The approach shift may be no so easy to accept.
Coming back to this question a few years later, I would like to point out a few aspects to illustrate that having all your communication through websockets does have its drawbacks:
there is no common support for compression. You can easily configure your webserver to compress http requests and browsers have been known to happily accept compressed responses for years, however for web sockets it is still not that easy (even though the situation has improved)
client frameworks often are build upon commonly used standards like rest. The further away you move from frameworks expectations, the less addons or features will be available.
caching in the browser is not as easy. By now this goes a long way, reaching into the realm of offline availability and PWAs.
when using technology, that is only used by a subset of users, it is more likely to find new bugs, or bugs might take longer to fix. And if it's not bugs, there might be an edge case somewhere around the corner. This isn't an issue per se - but something to be aware of. If one runs into those things, they often easily take up quite some time to fix or work around.
I'm evaluating the substitution of some http pooling features of my production application with the new JEE7 supported Websocket feature. I'm planning to use Wildfly 8 as my next production server environment and I've migrated some of my websockets compatible modules with good results on development time; but I have the doubt about how it will work on production and what performance will have the websockets implementation on a a high load enviroment.
I´ve been searching documentation about the most used JEE servers but the main manufacturers haven´t yet a production JEE7 enviroment and when they have a JEE7 version, they haven´t enought documentation about how the implementation works or some values of maximum concurrency users. In addition, some not official comments says websocket connections are associated "with a server socket" but this seems to be not very efficient.
We might assume the Websocket is used only for receive data from the client point of view and we assume each user will receive, for example, an average of 10 messages per minute with a little json serialized object (a typical model data class). My requirement is more like a stock market than a chat application, for example.
What´s the real performance can I expect for a Websockets use on production enviroment in Wildfly 8 Server, for example? Also I´m interested about some comparision with another JEE7 implementations you are acquainted with.
Web sockets are TCP/IP based, no matter the implementation they will always use a socket (and hence an open file).
Performance wise it really depends on what you are doing, basically how many clients, how many requests/sec per client, and obviously on how big your hardware is. Undertow is based on non-blocking IO and is generally pretty fast, so it should be enough for what you need.
If you are testing lots of clients just be aware that you will hit OS based limits (definitely open files, and maybe available ports depending on your test).
I hear that I can use Comet as a server push technology along with my Ajax code to increase the performance of my web applications.
How mature this Comet technology?
Is it supported by all web servers, programming languages and browsers?
What are the disadvantages of using Comet?
It is mature, though I think you should consider it more of a technique than a technology.
All web servers support it as far as I know, though you will need to research and configure your particular web server if you are building a comet application as the demands on the resources are a bit different. Specifically, there will be far more simultaneous open connections to your server. In terms of programming language support, if your server language of choice has any sort of blocking or waiting mechanism, you can support server-push. All browsers support it as well, as from the perspective of a browser, this is simply an http(s) connection that takes a long time to return.
There are a couple of disadvantages, in the browser world, the biggest is probably the fact that some browsers limit the number of open connections to a specific URL to two. So if you have a server blocking connection open waiting for some pushed data, you are down to only one connection available for the browser to get data from the server. This can be mitigated by spreading your resources over a few second level domains to allow the browser to open more connections.
"Supported by all web servers" is a bit of an odd statement. Most implementations are a server in and of themselves, and you'll need to find a server that integrates with the language you want to use.
That said, I work at a company that built one to integrate with a server, specifically IIS.
If you don't want to bother dealing with the server integration (dealing with different languages, handling scaling, etc), check out websync - the service lets you integrate any language easily, since it's hosted, but supports proxying requests through your own server so you can add your own business logic, logging, permissioning, etc.
Comet was actually in use before all the hype about AJAX started: It's just a new name for an old idea. People have been using hidden iframes to emulate server pushing for a long time without problems.