Some days before I asked a simple question in many groups on facebook.
Which one is best for real time web app?
- HTTP Long-Polling
- HTTP Streaming
But only a few people could compare between these technologies. In this article, I am going to tell what does real time web app mean and what is difference between these technologies?
What is real time app?
The real time web apps are the applications which functions within a time frame that the user senses as immediate or current. For example, live streaming, video chat, chat on facebook, monitoring on google analytics etc.
After AJAX took hold, it was a short jump to try and take the browser event out of the equation and to automate
setInterval() function to check for updates every n seconds.
As shown in the figure, client sends request after a fixed interval to check if anything new is available to load. It is not efficient because of a lot of vain requests which overheat the server. For example, assume this technology is used on the facebook and request time interval is 1s and your friend is responding to your chat in 10s then there are 9 waste requests to the server. (What about if total users are 100000?)
3) HTTP Long polling:
HTTP long-polling is the practice of opening an HTTP request for a set period of time to listen for a server response. If there is new data, the server will send it and close the request; otherwise, the request is closed after the interval limit is reached and a new one will be opened. This approach provides a mechanism by which the server can alert the client about new data without requiring any action on the part of the client. But this approach has also two problems. First that this is not a bidirectional approach. Once the connection is open then client has to make a new connection for next request. It overloads the requests. Second it has also overheating due to vain requests ( of course less than polling).
4) HTTP Streaming
HTTP streaming is very similar to HTTP long-polling, except the connection isn’t closed when new data is available or at a given interval. Instead, new data is pushed over the existing connection which remains open. Good part is that it solves the problem of overload, but there is still problem with bidirectional communication. One big problem with the HTTP streaming approach is the inconsistencies of how it is achieved within different web browsers. In Gecko-based browsers, it is possible to use multipart replace headers which indicate to the browser to replace the older content that was last received with newer content. In other browsers this isn’t possible, so the response buffer keeps on growing until there is no other choice but to close and reopen the connection to the server.
According to the WHATWG, the WebSocket protocol defines a standardized way to add realtime communication in web applications:
The WebSocket protocol enables two-way communication between a user agent running untrusted code running in a controlled environment to a remote host that has opted-in to communications from that code. The security model used for this is the Origin-based security model commonly used by Web browsers. The protocol consists of an initial handshake followed by basic message framing, layered over TCP. The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections (e.g. using XMLHttpRequest or <iframe>s and long polling).
WebSocket is among new features of HTML5. It resolves the both problems, bidirectional communication and number of requests. Because full-duplex communication cannot be achieved using HTTP, WebSocket actually defines a whole new protocol, or method of connecting to a server from a client. This is accomplished by opening an HTTP request and then asking the server to “upgrade” the connection to the WebSocket protocol.
But there is still problem with browser compatibility because old browsers do not supports HTML5.
Using Realtime Web Technologies in Your Apps Now
Although you may not be able to start relying entirely on WebSocket technology for your new web app, there are a growing number of companies and projects aiming to give you access to realtime web functionality today. Their approaches vary from using (gasp!) Flash, which has actually had socket support for years, as a fallback when WebSockets are not natively available to focusing on the HTTP-based solutions we mentioned earlier. Some of the options include Socket.io, Faye, SignalR, PubNub,Realtime.co,and Pusher.
If you like it then please share it with your friend otherwise give your valuable feedback to improve this as well as future tutorial to help other people.