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.
Related
Some pieces of middleware support websockets natively e.g. HiveMQ: http://www.hivemq.com/mqtt-over-websockets-with-hivemq/. What advantages are conferred to a developer using the websockets API as a first class client to the middleware, rather than routing requests through an intermediary server that supports language specific APIs e.g.
Client -> Middleware
vs
Client -> Server -> Middleware
For example, we could argue that skipping an intermediary server will reduce bandwidth costs, not require a developer to write an extra layer, native SSL websockets support?
What other advantages might be provided to not just a developer, but any party through providing websockets support for middleware?
The main advantage you get is simplicity and in case of HiveMQ, scalability.
Let me explain these advantages:
Simplicity
In case of HiveMQ, you just start the server and you are good to go. All web applications which use a MQTT library over websockets can connect to the server without even knowing that websockets as transport is used. For HiveMQ itself, it's just another MQTT client. So it doesn't matter if the clients are connected via websockets or via a classic TCP connection. I think you already mentioned the other arguments in your question. And of course last but not least the operations guys will thank you if they have one system (in your case the "Server") less to maintain.
Scalability
Software like HiveMQ is very scalable and it can handle up to hundreds of thousands of concurrent connected clients. The chance is high, that the additional layer ("Server" in your case) could introduce a bottleneck. Also, things like load balancing with a HW or SW load balancer gets a lot easier if you can throw out unneeded layers. In general, your architecture of your system will get a lot of easier if you don't need these additional layers (which are not services which can be reused for other applications, like microservices are).
Last but not least it's worth noting, that HiveMQ itself is often integrated with classic middleware / ESBs. That means, people write custom plugins for integrating HiveMQ to their existing middleware. JMS or webservice calls (REST, SOAP) are often used for doing that.
Take that answer with a grain of salt, since I'm involved developing HiveMQ :-)
If my web application has a number of regular AJAX methods in it, but I've introduced an always-on SignalR connection, is it worth refactoring to make the regular AJAX methods be hub methods instead? Would it be faster since it's using the already-there connection?
IMHO this would be a misuse of SignalR.
Would it be faster? It really depends on several factors. The first of which is which transport ends up being used. If it's Web Sockets, then, yes, because a message will be sent over a connection that's guaranteed to already be established, but if it's SSE or LongPolling you're still doing a plain old HTTP POST every time to send messages. Second factor is that if the server is allowing Keep-Alive connections, then browsers will keep open TCP connections to the server for some period of time between requests anyway so there would be no overhead in terms of establishing a connection anyway.
Also, let's not forget our powerful friend the GET verb and all the goodness it brings in terms of one of the most important features of the web: caching. If you have a lot of cacheable data, you wouldn't want to be sending real-time messages over web sockets to fetch and retrieve that because you're basically throw out the entire infrastructure of the web if you do. The browsers can't help you any more, you'd have to build all the intelligence yourself with local storage and custom messages which would be, for lack of a better word, insane. :) You also give up the power of proxies caching public data entirely as well which is extremely underrated in terms of how much it can help performance.
My guidance is that you leave what can be simple request/response exactly the way it is today leveraging AJAX and only use a technology like SignalR for what it's intended to be: real-time communications.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
or do Server-Sent Events and WebSocket replace Comet techniques?
I will approach this answer from both a terminology and historical perspective.
As I wrote in this other answer, we can use one of the several umbrella terms to refer to the set of technologies available to asynchronously send events from a web server to a web client (and vice versa). The "Push Technology" term has been used for fifteen years (for a short history of Push Technology you can see this old white paper I wrote many years ago—full disclosure: I am the creator of Lightstreamer). Now, the "Web Streaming" term is gaining consensus among the IT analysts (see Gartner, "Cool Vendors in Application and Integration Platforms, 2012", by Massimo Pezzini and Jess Thompson, 11 April 2012).
The important aspect is that we are talking about Web-based communication, that is, leveraging Web protocols. There are tons of messaging protocols and technologies that are not Web based (most of MOMs, for example) and we do not consider them as part of Push Technology (or Web Streaming).
That being said, you can distinguish between two sub-categories of Push Technology (or Web Streaming):
HTTP based
WebSockets based
Both HTTP and WebSockets are Web protocols.
If you explode the HTTP-based push mechanisms, you can identify:
HTTP Streaming
HTTP Long Polling
HTTP Polling
Traditionally, the "Comet" term (coined in 2006 by Alex Russell) has been referring to both HTTP Streaming and HTTP Polling. But consider that the first implementations of HTTP Streaming go back to 2000, well before the Comet term was coined (examples are Pushlets and Lightstreamer).
Now WebSockets make it simpler to implement Web Streaming, especially for the "backward" channel (messages sent from the browser to the server). For a more detailed explanation on the peculiarities of the backward channel over HTTP, see the final part of this article I wrote for CometDaily: http://cometdaily.com/2011/07/06/push-technology-comet-and-websockets-10-years-of-history-from-lightstreamers-perspective/
As pointed out by Phil, Comet is still necessary and will probably be for some more years, as there are not only old browsers around (including IE9, which does not support WebSockets…) but also infinite pieces of network intermediaries that do not speak WS. For example, we have seen that some mobile carriers in some countries (for example Vodafone Italy) support WSS but block WS. So a world without the Comet "hacks" is still far away… And let me add, on a personal note, that I've never loved the term "hack" applied to Comet (or, from a more correct historical point of view, applied to HTTP Streaming and HTTP Long Polling). Having worked on these techniques for 12 years now, I can say we have been able to refine them so much that they have become a full-blown technology themselves, completely reliable and used every day in many critical production scenarios (in finance, aerospace, and military, to name a few industries).
Now, let's imagine a world where WebSockets are universally supported and Comet is no more necessary. What do you get exactly? Well, just a bi-directional transport, nothing more... On the top of it you need to build everything: a messaging protocol (perhaps based on pub/sub), a server-side interface to talk to your server code, and a good set of optimization techniques and algorithms to manage the data flow, including bandwidth management, data conflation, automatic throttling, delta delivery, etc.
The good thing is that both the messaging protocols and the optimization mechanisms have already been implemented by good Comet solutions. So, extending former Comet servers to support WebSocket is the natural evolution that all of us vendors have implemented.
So, in a nutshell, in a not-so-near future WebSockets might make Comet transports obsolete, but will need to suck in all the higher layers already implemented and well tested on traditional Comet servers.
Comet is a set of technology principles/communication patterns that are typically implemented using HTTP long-poll. It enables a server to send data to the browser on demand (i.e. server push). Current comet implementations require some complex Javascript on the client side and support from the server-side (for long-held requests).
Server-Sent Events is a standard (HTML5) browser API for enabling this sort of on demand server push. You can think of Server-Sent Events as taking what has been done with complex Javascript and pushing it down into the browser itself.
WebSockets allows a browser to establish a persistent full-duplex/bi-directional connection to a server with WebSocket support. It does not require the client to keep making periodic HTTP requests to the server in order to maintain the connection as with AJAX/long-poll. Once the connection is established the overhead per message is very low (a few bytes) compared to the overhead with normal HTTP/HTTP long-poll. You can use WebSockets for efficient server push, but this is just one application.
There are also libraries that build on the AJAX/comet/WebSockets transport layer to provide things like session management, channels, broadcast, pubsub, etc. CometD is an example of this. Another popular example is Socket.IO. Both support WebSockets if it is available for the underlying transport but also support standard AJAX/long-poll if WebSockets is not available.
I initially thought that WebSockets realise Comet. They’re not an alternative. However, after some discussion I was later corrected and convinced by Alex Russell, the creator of "Comet", that this was not the case.
Comet, as #kanaka says, is a set of principles for simulating bi-directional communication between client and server (server push is half of the solution and is now provided by Server-Sent Events and the Event Source API).
However, Comet solutions are hacks because they work inconsistently across web browsers. For that reason Alex Russell says:
Next, are Web Sockets a form of Comet? Or is Comet just the HTTP hacks? I'm gonna go for the latter definition. The phrase and the hacks should probably ride off into the sunset together. I, for one, welcome our non-HTTP realtime overlords. To the extent that we can forget about old browsers (and god know I'm doing my bit: http://google.com/chromeframe), we can all get on board with "Web Sockets" and the need for any particular umbrella goes away.
So lets focus on that: how do we get users into a shiny new browser car? What sort of offer can we make to them about the richness and real-time experiences that an app based on WebSockets can deliver? Comet is about the past. Lets make the future real.
I'm now with Alex on this one. However, Comet - HTTP solutions - aren't going to become obsolete until:
Browser support is 100% and we don't need fallbacks for < IE10. I don't believe that Firefox, Safari, and Opera users are going to be a problem. There may be a small percentage of users that ignore the auto-update prompts for browsers like Firefox but not many.
Anti-virus manufacturers (such as Avast!) start support HTML5 web technologies and stop their software interfering with connectivity.
Some Internet infrastructure is updated to ensure the support of WebSockets. In my experiences connected over WSS over port 443 (a secure WebSocket connection) normally means connections make their way through Firewalls and Proxies but we want WS over port 80 to always be supported too.
While WebSocket does provide at the most fundamental level a way to communicate bi-directionally between a client and a server within the context of the Web and HTTP, it is a simple form of communications.
Comet provides more functionality on top of WebSocket (in fact, cometd even supports websocket), for features:
like publish/subscribe and channels of communications
fallback to older client<->server communications techniques when websocket is unvailable
I've been using WebSockets for a while now, I have chosen to create an Agile project management tool for my final year project at University utilizing Node server and WebSockets. I found using WebSockets provided a 624% increase in the number of requests per second my application could process.
However since starting the project I've read of security loopholes, and some browsers choosing to disable WebSockets by default..
This leads me to the question:
Why use AJAX when WebSockets seems to do such a great job of lowering latency and resource overhead, is there anything that AJAX does better than WebSockets?
WebSockets isn't intended to replace AJAX and is not strictly even a replacement for Comet/long-poll (although there are many cases where this makes sense).
The purpose of WebSockets is to provide a low-latency, bi-directional, full-duplex and long-running connection between a browser and server. WebSockets opens up new application domains to browser applications that were not really possible using HTTP and AJAX (interactive games, dynamic media streams, bridging to existing network protocols, etc).
However, there is certainly an overlap in purpose between WebSockets and AJAX/Comet. For example, when the browser wants to be notified of server events (i.e. push) then Comet techniques and WebSockets are certainly both viable options. If your application needs low-latency push events then this would be a factor in favor of WebSockets. On the other hand, if you need to co-exist with existing frameworks and deployed technologies (OAuth, RESTful APIs, proxies, load balancers) then this would be a factor in favor of Comet techniques (for now).
If you don't need the specific benefits that WebSockets provides, then it's probably a better idea to stick with existing techniques like AJAX and Comet because this allows you to re-use and integrate with a huge existing ecosystem of tools, technologies, security mechanisms, knowledge bases (i.e. far more people on stackoverflow know HTTP/Ajax/Comet than WebSockets), etc.
On the other hand, if you are creating a new application that just doesn't work well within the latency and connection constraints of HTTP/Ajax/Comet, then consider using WebSockets.
Also, some answers indicate that one of the downsides of WebSockets is limited/mixed server and browser support. Let me just diffuse that a bit. While iOS (iPhone, iPad) still supports the older protocol (Hixie) most WebSockets servers support both Hixie and the HyBi/IETF 6455 version. Most other platforms (if they don't already have built-in support) can get WebSockets support via web-socket-js (Flash based polyfill). This covers the vast majority of web users. Also, if you are using Node for the server backend, then consider using Socket.IO which includes web-socket-js as a fallback and if even that is not available (or disabled) then it will fall back to using whatever Comet technique is available for the given browser.
Update: iOS 6 now supports the current HyBi/IETF 6455 standard.
Fast forward to December 2017, Websockets are supported by (practically) every browser and their use is very common.
However, this does not mean that Websockets managed to replace AJAX, at least not completely, especially as HTTP/2 adaptation is on the rise.
The short answer is that AJAX is still great for most REST applications, even when using Websockets. But god is in the details, so...:
AJAX for polling?
The use of AJAX for polling (or long polling) is dying out (and it should be), but it still remains in use for two good reasons (mainly for smaller web apps):
For many developers, AJAX is easier to code, especially when it comes to coding and designing the backend.
With HTTP/2, the highest cost related to AJAX (the establishment of a new connection) was eliminated, allowing AJAX calls to be quite performant, especially for posting and uploading data.
However, Websocket push is far superior to AJAX (no need to re-authenticate or resend headers, no need for "no data" roundtrips, etc'). This was discussed a number of times.
AJAX for REST?
A better use for AJAX is REST API calls. This use simplifies the code base and prevents the Websocket connection from blocking (especially on medium sized data uploads).
There are a number of compelling reasons to prefer AJAX for REST API calls and data uploads:
The AJAX API was practically designed for REST API calls and it's a great fit.
REST calls and uploads using AJAX are significantly easier to code, both on the client and the backend.
As data payload increases, Websocket connections might get blocked unless message fragmentation / multiplexing logic is coded.
If an upload is performed in a single Websocket send call, it could block a Websocket stream until the upload had finished. This will reduce performance, especially on slower clients.
A common design uses small bidi messages transferred over Websockets while REST and data uploads (client to server) leverage AJAX's ease of use to prevent the Websocket from blocking.
However, on larger projects, the flexibility offered by Websockets and the balance between code complexity and resource management will tip the balance in favor of Websockets.
For example, Websocket based uploads could offer the ability to resume large uploads after a connection is dropped and re-established (remember that 5GB movie you wanted to upload?).
By coding upload fragmentation logic, it's easy to resume an interrupted upload (the hard part was coding the thing).
What about HTTP/2 push?
I should probably add that the HTTP/2 push feature doesn't (and probably can't) replace Websockets.
This had been discussed here before, but suffice to mention that a single HTTP/2 connection serves the whole browser (all the tabs/windows), so data being pushed by HTTP/2 doesn't know which tab/window it belongs to, eliminating it's capacity to replace Websocket's ability to push data directly to a specific browser tab / window.
While Websockets are great for small bi-directional data communication, AJAX still carried a number of advantages - especially when considering larger payloads (uploads etc').
And Security?
Well, generally, the more trust and control is offered to a programmer, the more powerful the tool... and the more security concerns that creep up.
AJAX by nature would have the upper hand, since it's security is built in to the browser's code (which is sometimes questionable, but it's still there).
On the other hand, AJAX calls are more susceptible to "man in the middle" attacks, while Websockets security issues are usually bugs in the application code that introduced a security flaw (usually backend authentication logic is where you'll find these).
Personally I don't find this to be that big of a difference, if anything I think Websockets are slightly better off, especially when you know what you're doing.
My Humble Opinion
IMHO, I would use Websockets for everything but REST API calls. Big data uploads I would fragment and send over Websockets when possible.
Polling, IMHO, should be outlawed, the cost in network traffic is horrid and Websocket push is easy enough to manage even for new developers.
In addition to issues with older browsers (including IE9, as WebSockets will be supported starting from IE10), there are still big problems with network intermediaries not yet supporting WebSockets, including transparent proxies, reverse proxies, and load balancers.
There are some mobile carriers that completely block the WebSocket traffic (that is, after the HTTP UPGRADE command).
With years passing, WebSockets will be more and more supported, but in the meantime you should always have an HTTP-based fall-back method for sending data to the browsers.
Most of the complaining I have read about websockets and security is from security vendors of web browser security and firewall security tools. The problem is they don't know how to do security analysis of websockets traffic, because once it has done the upgrade from HTTP to the websocket binary protocol, the packet content and its meaning is application specific (based on whatever you program). This is obviously a logistic nightmare for these companies whose livelihood is based on analyzing and classifying all your internet traffic. :)
WebSockets don't work in older web browsers, and the ones that do support it often have differing implementations. That's pretty much the only good reason why they aren't used all the time in place of AJAX.
I don't think we can do a a clear comparison of Websockets and HTTP as they're no rivals nor solve the same problems.
Websockets are a great choice for handling long-lived bidirectional data streaming in near real-time manner, whereas REST is great for occasional communications. Using websockets is a considerable investment, hence it is an overkill for occasional connections.
You may find that Websockets do better when high loads are present, HTTP is slightly faster in some cases because it can utilise caching. Comparing REST with Websockets is like comparing apples to oranges.
We should be checking which one provides better solution for our application, which one fits best in our use case wins.
An example of the differences between HTTP and Websockets in the form of a client-size lib that can handle Websocket endpoint like REST APIs and RESTful endpoints like Websockets on the client.
https://github.com/mikedeshazer/sockrest
Also, for those who are trying to consume a websocket API on client or vice versa the way they are used to. The libs/sockrest.js pretty much makes it clear the differences (or rather is supposed to).
If you want to open a two-way connection between the browser and server, the only choice is to poll (hammer the server), or use comet (crufty and prone to disconnects).
Why don't browsers just let you open up a plain TCP connection? Is there any practical benefit to not having this ability?
The underlying protocol HTTP is basically a half duplex communication protocol which is stateless as well and does not supports full duplex communication. However, with HTML 5 websockets things are going to change. Websockets is a new standard which is being considered in HTML 5 specification. Once the specifications have been finalized and all the browser vendors have adapted the standards you can possibly use websockets to establish a dedicated TCP connection through browsers itself.
We must also keep in mind that HTTP was basically designed to deliver documents & share information between the geographically distributed teams and it was not intended to be a communication protocol as such.
Having said that, there are already companies which have built some messaging gateways to enable you to implement full duplex communication.
Given that this functionality is effectively available through flash, there's no real security rationale - but these days no browser wants to be the first to implement a non-standard extension like that. Moreover, there's no easy way to do threads, which could make using a socket rather awkward.
Over the years so many aspects or elements of the web have been hijacked in order to deliver richer experiences. Comet is but one example, where long lived connections were exploited in order to allow server side push. Originally web pages were just meant to be hyperlinked documnts of text and not the rich applications we often see today. Hacks and abuses of what the original thought intended will continue, until one day these things become more standardised.
The answer to your question is essentially no, there is no tangible advantage to not being able to open a two-way connection between client and server in a browser. The reason it can't be done is simply that this was not the intention of web browsers, which were developed to poll/retrieve documents. With the advent of Rich Internet Applications, it has become desirable to have such functionality, but previously this had never been the goal of a browser. Currently there is a void to be filled by an eventual protocol or implementation of an existing protocol which will govern two-way communication between a browser and the server. There are existing techniques used to simulate this behavior to different degrees (AJAX, Comet, etc.) or it can be accomplished with embedded objects (Java, Flash, ActiveX Controls in IE) but these are simply paths around the void, not bridges over it.
We will simply have to wait (or act) for the standard to be written and the implementation to follow. More than likely, the implementation will actually come first, and we will have a fistfull of new cross-browser compatibility issues to enjoy :) Oh, the bleeding edge!
Firewalls. Non-HTTP traffic is often blocked by firewalls, so opening up a random TCP port for communication will often fail.