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.