After presenting to a partner of Kaazing last week I got asked what impact the emerging WebSocket standard would have on the Web, assuming we continue down the path that has already been laid out.
The impact could be the same, or even more profound, as when we were first introduced to HTTP as a means to share static documents. The difference is that this time the targeted market is already defined – it is called the Web. I have over the past several years, half jokingly and half seriously, compared the current static Web with a push to talk radio (aka Walkie Talkie) and the new living Web with a cell phone. You can get by with the WT and solve most of your problems; after all it’s been around for a while and it works. If you want to communicate with a friend in “real-time” you can solve it by getting two WTs, one to talk and one to listen. With a new Web standard, WebSocket, entering the market, Web developers now have access to the equivalent of a cellphone – one channel for “talk” and “listen”.
What would you choose if both push-to-talk and cell phone were available to you? What would developers choose if both technologies were readily available to them (e.g.: browser support)?
Well, if you are uncertain and feel like WebSocket is an unproven standard you might want to relate to this; remember the first time your friends started pushing you to buy a cellphone although you already had a stationary phone at home and one at the office that worked perfectly? Now several years later we all have at least one cell phone, each, and we can’t (at least I can’t) live without it.
This is exactly the same impact the following line of code will have on the Web in comparison with the current HTTP communication we are so used and accustomed too.
var mySocket = new WebSocket("ws://websocket.org/");
If you do understand the profound impact this one line of code will have you are in good shape and most likely are already using, extending, or pushing this new standard solution from W3C and IETF. If you are not, then let me take a short moment to explain why it is so important:
- HTTP was designed to deliver static documents, not to deliver transactional, dynamic, and real-time data updates.
- HTTP is by design stateless, so session state needs to be artificially maintained. Traditionally this is done by a legacy Web-tier solution such as an application server like Oracle WebLogic Server or IBM WebSpere.
- In every environment developers have access to a “socket” interface, which enables them to communicate using any format (read protocol) over a full-duplex connection. Not on the Web.
- Not having access to a standard, Web-friendly, socket API forces us to create transformation layers when sending data from a Web client, using HTTP, to a backend system relying on a different full-duplex TCP protocol e.g. XMPP, STOMP, AMQP.
- The above line of code opens the floodgates to use any TCP-based communication format, which in turn enables developers to freely innovate and create new types of Web applications that previously have not been feasible over the existing HTTP infrastructure.
- WebSocket offers a far better use of bandwidth by getting rid of unnecessary HTTP headers when information is shared. The improvement is at a ratio of up to 1000x.
- The latency to deliver data is greatly improved by eliminating the round trip of the HTTP request-response model, and by using the bandwidth more efficiently.
With the explosive growth of Web-enabled devices (yes, I’m thinking about the iPhone, iPad, Android, Galaxy, etc…) and the demand for more and live information, communication and distribution of data over the Web is growing exponentially. At this rate the growth of data distributed over the Web will out pace the performance principals of Moore’s Law, which we depend on to ensure that our hardware can keep up with our needs.
WebSocket traffic vs. HTTP traffic
For individuals this may not be too much of a concern, but for companies providing online services it will be, and already is, a huge and costly issue since it requires a tremendous amount of resources to deliver on the increasing demand for live information over the Web (read about Google’s move and Facebook’s move).
For example, when a user enters a single character ‘a’ in a search engine, a drop down list appears automatically showing possible search results starting with letter ‘a’. Behind the scenes an HTTP request has been issued asking the server for the information displayed in the drop down list. For every new character entered a new HTTP request is issued to the server to request for more information. The same HTTP characteristics you can find in collaborative online documents such as Google Docs, where each character entered generates a POST to ensure that users editing or looking at the same document can see each other changes in real-time.
Now, what was sent, what was received, and what was really needed?
There is a great article on websocket.org, called a “Quantum Leap in Scalability for the Web” that is outlining the difference between HTTP and WebSocket in terms of bandwidth utilization. In this article the sample application is a simple trading solution, but the math can be applied to any HTTP-based dynamic and transactional Web application.
In the article we have 0,665Gbps in header traffic to respond to 100,000 users per request.
What is the impact of using WebSocket technology? There are no sizable headers involved passing information between a client and a Websocket Gateway. Let’s apply the above math example to WebSocket technology as described by the article:
100,000 visitors receiving an update every second. (WS wireframe = 2 byte) * 100,000 * 8 = 1,600,000 bps (0.001526Gbps).
Results from this easy math:
HTTP:// = 0,665Gbps versus WS:// = 0.001526Gbps. In the above sample Websocket communication is 436 times more efficient. 436 times! We are talking about a gigantic leap of improvement, and that assuming that your cookies are not adding more data than this sample.
WebSocket is not a better Ajax!
Not only is the new standard improving bandwidth utilization it also gives us the ability to use any TCP-based high level communication format for our Web applications. This part of the HTML5 WebSocket standard has still yet to be fully appreciated. Right now most solutions and developers tinkering with the WebSocket APIs are looking at the new standard as merely a better replacement of XHR, or Ajax, when in fact it is a quantum leap forward in communicating over the Web that cannot be compared to XHR. With WebSocket we can now build client libraries in any Web technology supporting any TCP-based protocols. A simple example would be to extend the now widely used chat protocol XMPP to the Web (here is a demo site that lets you log in to Google Talk using XMPP over WebSocket) by providing a client-side implementation on top of Websocket APIs, or an advanced example would be to extend Java Message Service (JMS) over WebSocket such as the Kaazing WebSocket Gateway.
Scaling a WebSocket Solution
Web developers have been trying to work around the limitations of HTTP since the early days using techniques such as Comet, Reverse Ajax, or HTTP Streaming. With a move to persistent connections, or a stateful Web, server scalability of concurrent connections has been, and still is, a serious concern. Holding on to a thread on the server while the thread is not in use, combined with an Web-tier and infrastructure that was not designed for this, is not necessarily a scalable combination. Now, great strides have been made to ensure better scalability across technology stacks such as the use of NIO in Java.
At Kaazing we have always taken scalability and performance extremely serious and focused on making sure that our software is not in the way of scale or performance. As a matter of fact, we did a benchmark over the new year 2008/2009, to prove that scaling a WebSocket solution with persistent connections was not an issue, so we brought in a Java performance expert – Kirk Pepperdine – to help us and by the first weeks of Jan 09 we were running 1,000,000 concurrent connections on one single server. Now, is this practical? A more realistic scenario is running 1,000,000 users on a single rack or half a rack. This would enable us to have failover and high-availability, while still providing great performance and scale. So, last year we ran new tests together with DELL and Tibco to ensure not only great scale but also outstanding performance: DELL, TIBCO, and Kaazing enable ‘The Fastest Million’ to revolutionize real-time data delivery over the Web.
In Conclusion
The simplest design ideas are often the innovations with the most impact. WebSocket as an idea and design is extremely “simple” and its impact on our industry will be profound. Of course, with simple ideas you also get the “doubters”. I remember one time when my co-founder John Fallows and I met with a renowned VC in Silicon Valley and he asked us:
“If this is such a great idea why has no one come up with this idea before?”
I guess you could ask humanity a similar question about why it took several thousands of years to invent the wheel – after all it’s so obvious and simple.
What is important to understand is that we now have at our disposal a very powerful tool that will enable us to communicate securely with anything over the Web, and that it is only our own imagination that will limit our ability to fully exploit the WebSocket standard to its full potential.
If you are having performance and scalability issues with your current Web solution then it is time to look at an enterprise WebSocket platform, such as the one Kaazing provides. To round off I’m just going to ask you one short question:
If you had a choice between building a Web application using HTTP and Websocket, and both were readily available to you, which one would you choose?
Peter Moskovits (Head of Real-Time Solutions at Kaazing), Frank Salim (Software Engineer at Google), and Vanessa Wang (Manager of Technical Publications at Kaazing) will be interviewed live at GDL by Peter Lubbers (Chrome Developer Relations Program Manager at Google). You can start submitting your questions now.
