How Fat-Pipe Connectivity over the Web Changes Everything
We are our choices.
Jean-Paul Sartre
As a child my family’s menu consisted of two choices: take it or leave it.
Buddy Hackett
Giant Steps
We all know about the hip HTML5 apps and ritzy sites out there. There are a lot of swell and keen web applications that leverage the mind-blowing array of new functionality being added to the web tool chest. I’ll level with you, it’s amazing for me as a long time tech cat to watch the back seat bingo, handcuff and tying of the knot of Hypertext to the Internet. They just got goofy and now the combination is just nifty. Back in the 80’s, Hypertext needed the Internet and the Internet wanted Hypertext. The two just jammed, natch. And after 25 plus years, the Web is hip to the jive and is just smokin.
During the courtship, Sir Tim (“TBL” to those who know him well) decided on using a simplified document-sharing distributed computing protocol that is known and loved/liked/sorta-liked as HTTP. For the kiddies out there, HTTP is HyperText Transfer Protocol, btw, note the historic “hypertext” connection (for extra credit Google “Vannevar Bush”, “Ted Nelson” and “Douglas Engelbart” and take notice of their visionary contributions to our everyday lives). For the past two-plus decades, the World Wide Web has been primarily based on a synchronous (make a request and wait for a response regardless of how long it takes), document-centric sharing application protocol designed in 1989. Yep, the same year as Lotus Notes was launched, the 25MHz Intel 80486 with 1.2 million transistors came out and when Baywatch was on TV (sigh… they don’t make quality programs like that anymore).
Technology state of the art when HTTP was invented.
All Blues
As more and more users of the web demanded more interactivity, some de facto and rather loose standards started to emerge. DHMTL or Dynamic HTML (hey… don’t blame me for the name) was an inconsistent collection of technologies introduced by Microsoft in the late 90’s in an attempt to create customized or interactive web sites. And in an attempt to add more functionality between Internet Explorer and Outlook, Microsoft added XMLHTTPRequest (XHR for the hipsters) to improve the communication between client and server. As the memetic evolution to increase the bandwidth for more user interactivity continued, other technologies such as AJAX, Asynchronous JavaScript And XML (which doesn’t have to be asynchronous, nor JavaScript nor XML btw) and Comet or “reverse-AJAX” (server push to the browser) appeared moving all of us towards a more dynamic world at the expense of more complexity. After all the very essence of the web (as with most hypertext systems) was not focused on interactivity, just document sharing.
As is the case with increasing complexity in any dynamic system, there becomes a point where chaos gets out of control and the need for stability becomes critical for evolution and continued existence. With its lack of standards… heck, lack of a real definition, DHTMTL and related technologies created a morass for all the web developers on the planet.
You guessed it. A morass.
In addition, simulating real-time interactivity using HTTP-centric tools such as AJAX and Comet is clumsy and heavyweight. These workarounds used HTTP in a way that it was never intended. Our hats are off to the developers who originated these hacks since there was no good alternative, but they are indeed hacks for missing functionality.
In other words, when the Hack Quotient (or chaos index) is high, the time is ripe for innovation. Now that I think about it, this is a corollary of [enable canyon echo] Greco’s Law of Scalability (hey if Gordon Moore can call his thing a law and not an observation, why not me?).
I apply this heuristic (ok, at least I’m humble) to complex distributed systems, but it seems to apply to innovation as well. When growing complexity, perhaps from hacks and workarounds, overwhelms a system’s ability to grow, its time for a major overhaul, i.e., what’s known in the industry as a “do-over”.
Unforgettable
For the web, this do-over was the HTML5 initiative. HTML5 gives us a renewed focus on standardized APIs, enhanced graphics, offline capabilities, and enhanced browser security. However the early HTML5 specification continued to only use HTTP as the communications protocol. Yes, the same synchronous, request-response distributed computing model used in the late 70’s and 80’s which was proven to be brittle, difficult to manage and clumsy to scale for many use cases. I can’t even mutter the word “CORBA” or else I’ll get nauseous.
About 10 years ago, there started a spirited discussion on a new lower-latency communication model for the web within the HTML5, IETF and WHATWG standards communities. Google’s Ian Hickson, the HTML5 specification lead, had a personal interest in such a model. Ian is a model train aficionado and was quite interested in controlling his model trains through a browser. Simulating real-time control by tricking out HTTP was just not cutting the mustard for Ian. He thought saving milliseconds of latency when two locomotives were speeding at each other could be considered quite valuable.
Several proposals for a more modern communications substrate were submitted. One proposal was to have a real TCP connection that used ports other than 80 or 443 and was known blandly as “TCPConnection”. Another proposal came from Kaazing’s co-founder (and current CTO) John Fallows along with another Kaazing colleague. They submitted a proposal for a modern communications technology called “WebSocket” that recommended the initial connection be made via HTTP on a standard port and then request the server to upgrade the protocol to WebSocket on the same port. This clever scheme guaranteed every web server on the planet was capable in the future of speaking WebSocket. The majority of the Fallows proposal is now part of the official WebSocket specification.
So What
So we now have an official, standards-blessed, browser-enabled, web-friendly mechanism for a “TCP for the Web” (yes, we all know physically HTTP runs over TCP as does WebSocket). WebSocket is something we’ve wanted ever since the dawn of the web. We can now perform enterprise-style distributed computing in a web-safe manner. We don’t need the browser to poll for data, use hanging-GETs, forever frames, HTTP streaming or even need to have the web server to poll for data from another service to eventually relay to the browser (using another poll).
Most of these techniques have high overhead due to the nature of HTTP meta-data which is sent for every HTTP call. For document-centric applications, where the data to meta-data ratio is relatively large, this is usually acceptable. For event-based messaging applications such as in finance, enterprise infrastructure and now with IoT, this data/non-data ratio is very small; additionally much of the time the meta-data is as redundant as hitting the elevator button multiple times.
For these use cases, there’s clearly a high price to pay by using HTTP as the underlying protocol. To make it worse, you’re polling which in of itself is resource-intensive. WebSocket does not have the same HTTP meta-data overhead so it’s very lightweight. And since its lightweight and simple, it can be quite fast and scalable. For critical event-based applications, WebSocket is the obvious technology of choice. But note it’s not a replacement for HTTP, which is great network plumbing for synchronous communications especially those that serve lots of static elements and have caching requirements.
The W3C has standardized the WebSocket JavaScript API, so there is an official JavaScript API. This API has been mimicked in other languages such as Java, Ruby and C#, but only the JavaScript API is formally standardized. We’ll review the API in a future blog and how to handle legacy or minimal browsers that do not have WebSocket capability.
How High the Moon
As we’ve discussed, HTTP has been used by a browser to have a conversation with a webserver to get and put full documents or parts of documents. It’s a useful and network friendly protocol that allows people to extend the reach of their documents beyond the corporate firewall. This type of access is exceptionally valuable for offering request/response services. The vast majority of all such (non-video) web usage is hidden via these synchronous (request and wait for a response) APIs.
The programmatic web is hidden underneath the viewable web
There’s no surprise the popular REST API architecture for accessing these services uses HTTP. Because of the ubiquity and language neutrality of HTTP, these services can be reachable by any client application regardless of programming language or operating system.
But think about WebSocket. The IETF standardized the WebSocket protocol as an independent application protocol based on TCP. As an efficient network substrate, it is designed to support any other application protocol that typically would use TCP. There is even a mechanism in the specification (“sub-protocols”) that can be used to allow the client to identify the higher order protocol to the server so the server can manage that protocol conversation effectively and efficiently. For many use cases, WebSocket is more appropriate than using REST, particularly for streaming, persistent connections or event-based applications.
What a Wonderful World
By implementing well-known TCP-based application protocols over WebSocket, many applications can subsequently traverse the web as easily as HTTP. Most importantly the protocols remain unchanged avoiding any semantic loss in translating to extremely coarse-grained HTTP semantics. This implies messaging and datastore systems, notification mechanisms, monitoring frameworks, hybrid cloud dynamic connectivity, IoT aggregation, risk management, trading systems, logistics architectures, etc., can now all traverse the web, on-demand and in real-time with no polling.
Pretty cool Daddy-o. Now fix me a drink.
Btw, if anyone is attending AWS re:Invent, please stop by the Kaazing booth (#K24) to say hello, ask some WebSocket questions, talk about the future of hybrid clouds and containers, see some cool KWIC demos and all that jazz.