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).
Another advantage to WebSocket is that it is a more natural match to back-end, full-duplex, TCP-based messaging systems, such as RMI (Remote Method Invocation), JMS (Java Message Service) and XMPP (Extensible Messaging and Presence Protocol), used for Internet chat. Bridging HTTP to these protocols “led to a mismatch that many companies have spent a lot of time trying to overcome,” Fallows said.
The current versions of most Web browsers, including Chrome, Safari, Firefox and Opera, support WebSocket. Microsoft has built in WebSocket support for Internet Explorer version 10, still under development. To support older versions, Kaazing offers enterprises server software that emulates WebSocket functionality.
Fallows warned that WebSocket is not designed to replace HTTP, but instead would be used for specific high-traffic, low-latency needs that HTTP is ill-suited for, such as messaging, transactions, and frequently updated publish and subscribe-styled applications.
One audience attendee, a developer for a brokerage firm, said his organization is investigating WebSocket as a way to speed customer updates. He was aware of WebSocket’s putative benefits but was pleasantly surprised to learn that WebSocket could be easily used with enterprise messaging protocols such as JMS.
Joab Jackson covers enterprise software and general technology breaking news for The IDG News Service. Follow Joab on Twitter at @Joab_Jackson. Joab’s e-mail address is Joab_Jackson@idg.com