Are HTML5 WebSockets the Panacea for Real-Time Data Push?

As consumers expect more from their websites and apps, a majority of newer sites and mobile apps are adding features that require publish-subscribe. Everything from financial apps, business collaboration, realtime social sharing and newsfeeds, to multiplayer games, chat, and voting apps all require publishing data to devices with sub-second latencies.

WebSockets is a relatively new API supported by some of the latest browsers that attempt to offer a one-size-fits-all solution for pushing data to browsers. WebSockets is new, but it’s not alone. Over the last 15 years, a large number of other APIs, protocols, and methodologies have also been created to support large-scale data push. So, how does WebSockets stack up? What protocol should you use when building your next data push application?

A Little WebSockets Background

WebSockets exists as one approach to circumvent the original design of HTTP, the standard web protocol. The HTTP protocol, used by websites and many mobile apps today was originally designed to work in a request / response model.  To create the illusion of realtime data push, many websites and apps have used “polling”, i.e. they make quick, repeated requests back to the server to check for updates.  A surprising number of websites continue to use this technique, even though this hack doesn’t deliver true “realtime” updates, and at scale, the bandwidth and server costs required to handle the repeated, redundant polling become prohibitive.

Many other viable techniques exist for data push.  Large-scale websites have been deployed using lots of other methods, including Comet, Bayeux, BOSH, “Long polling” variations, Pushlets, XMLSockets, and hidden iFrames, to name a few. So, how does WebSockets compare to these approaches, and how do you ensure you’re using the right technique for your next app or website?

WebSocket: A Deeper Dive

At first glance, WebSockets looks like the obvious choice.   The API is designed to provide a bi-directional communication channel between browser and server over a single TCP socket.  It’s been standardized by the IETF, and the latest Chrome, Firefox, IE, and Opera browsers support WebSockets.  It’s designed to minimize bandwidth overhead by reducing HTTP message overhead.  So, what’s not to like?

Like any perceived silver bullet, things are not always what they seem.  Lots of problems exist:

Browser Support: As of June 2012, only 47.64% of browsers currently in use actually support WebSockets (https://caniuse.com/websockets).   That means, no matter how good WebSockets appears, you still need a second “fallback” solution to support the majority of Internet users.   And since most “fallback” solutions involve Flash, you’re still out of luck on iOS and other mobile devices.

Bypassing Proxy servers: Many proxy servers do not properly route WebSockets traffic.  In fact, Peter Lubbers from InfoQ says that WebSockets are “…likely to fail in all but the simplest network topologies.” (https://www.infoq.com/articles/Web-Sockets-Proxy-Servers) This problem alone unfortunately rules out the use of WebSockets within most large corporate networks.

Detecting Dropped Connections: In WebSockets implementations, a common problem is accurately detecting dropped connections.  WebSocket developers often use a browser API called “window.navigator.onLine” to determine connection status, but unfortunately, this API is poorly implemented on many browsers and often doesn’t work at all (especially on some mobile devices).  This means it’s common to be pushing data to a device that’s no longer listening, while the device doesn’t realize it’s been disconnected.

Supporting Heterogeneous Environments: Desktop and native mobile apps are not hindered by the limitations of HTTP, since they can create TCP and UDP connections. Yet in a WebSockets-only server configuration, these native apps would need to emulate WebSockets.  Instead, the ideal data push technique in heterogeneous environments (web, native apps, and desktop), is to use the most optimal protocol for each environment, rather than trying to force WebSockets across all devices.  This magnifies complexity in your server-side code, which now has to support a multitude of environment-specific protocols.

So, What’s the Right Solution?

If WebSockets is limited, what are the alternatives?  Each of the other protocols and techniques mentioned above also have their limitations.  To further complicate the choice, the landscape of browsers, mobile devices, and protocols is changing rapidly. SPDY and WebRTC are emerging as new protocols, and APNS, C2DM, and GCM muddy the waters for some mobile use cases.

The answer is to choose a solution that shields the developer from the ever-changing set of protocols, techniques, and environments. 

That’s where PubNub comes in.  PubNub is a protocol-independent data push solution: as a cloud service, we handle the proper protocols automatically depending on your environment.  As new standards like WebSockets emerge and mature, we implement them into our client libraries, and your apps will get the benefit of always using the latest, most stable standards.  Because PubNub supports over 30 different programming environments, PubNub always ensures you’re using the most optimal, reliable, and high-performing technique available for your specific deployment.

Ease of Use

Developers only need 2 APIs in order to Publish and Subscribe:

Sign up for your free account and see how easy it is to get started.

PubNub is designed as a protocol-independent way of delivering realtime bi-directional data push.  As a hosted service, PubNub also handles the server scaling and performance challenges with a purpose-built architecture entirely in C, distributed in 10 data centers worldwide.  Learn more about how PubNub works.

Get Started
Sign up for free and use PubNub to supercharge WebSockets!