HTML5 WebSocket to hasten Web app comms

Nov 01, 2011 07:21 pm | IDG News Service

WebSocket is faster than the veritable HTTP protocol, Kaazing's CTO asserts
by Joab Jackson

Thanks to its chattiness, the traditional communications protocol for shuttling data around the World Wide Web is not very efficient. Now an HTML5-related standard called WebSocket could cut some of this networking overhead, speeding responsiveness in Web applications, argued a Web app expert.

"If you were not constrained by the limitations of HTTP, what sort of truly interactive Web applications would you build?" John Fallows rhetorically asked, before a theater filled with Web developers and managers attending the HTML5 Live Conference held Tuesday in New York. Fallows is the chief technology officer and co-founder of messaging software provider Kaazing.

The use of the W3C's (World Wide Web Consortium's) WebSocket could enable a new generation of real-time, "zero-latency" Web applications whose communications requirements would be too demanding for today's HTTP protocols, Fallows argued.

As an example of Web socket speediness, Fallows showed off an implementation of the popular 1990s computer game Quake II, which Google engineers had ported to run entirely within a browser, using WebSocket to bridge the server and client. Running this game online would not have been possible through HTTP, he argued.

Fallows also demonstrated a simple stock ticker, in which the values of about 10 stocks were updated every second or so, showing a near-constant flow of ever-changing values.

Created in 1991, the HTTP (Hypertext Transfer Protocol) is now used for most all of the traffic on the Web. Because it was designed for document transfer, it really isn't well-suited for modern-day Web applications, Fallows argued.

HTTP's chief shortcoming is that it is half-duplex, meaning it can only communicate in one direction--either from the client to the server or from the server to the client--at a time. Users may not notice this because communication exchanges between the client and server can take just a few hundred milliseconds. But as Web applications increasingly receive and send more data, this back-and-forth communication will only add more noticeable latency to the application.

Another factor that makes HTTP ill-suited for the age of Web apps is that HTTP packets are loaded with large amounts of header data, which consumes bandwidth and requires more work to process. HTTP is stateless, meaning there is no dedicated bridge between the client and the server. So each packet message between the two must contain all the session information for that exchange, such as cookies.

WebSocket, when used instead of HTTP, simplifies this exchange, Fallows said. HTTP may carry anywhere from 800 bytes to a few thousand kilobytes in header information, whereas a WebSocket packet can pack the useful header information into a few bytes.

Like HTTP, WebSocket uses TCP (Transmission Control Protocol) as the underlying transport protocol. After the original handshake between the client and server, the two parties switch from HTTP into the WebSocket protocol. Because it is fully compliant with Web standards, WebSocket can traverse corporate firewalls, proxies and routers in all the ways that HTTP packets can. Developers write to WebSocket through a JavaScript API (application programming interface).