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.
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.