Makoto Inoue raised a good point about my recent post related to WebSocket speed versus XHR:
“The reason Websocket version is way faster than XHR is because the Websocket example uses HTTP pipelining while the XHR example does not. XHR pipelining was disabled, because it is is not supported on Google Chrome. If you disable the use of pipelining and run the WebSocket version, it would actually be slow. The author (Kensaku Komatsu) put the new example where you can disable pipelining on Chrome.”
Before we jump to any conclusions though, let’s review the use of pipelining in the examples and how it relates to Web Sockets.
HTTP pipelining is disabled in Chrome (and other browsers) because it is generally unsafe for the web. It is difficult to control, can interact dangerously with proxies, and is not widely implemented. The Wikipedia article about HTTP pipelining shows that even in most browsers that have implemented it, pipelining is intentionally disabled!
The demo uses pipelining but it is not HTTP pipelining. The network traffic is made up of WebSocket frames and not HTTP requests and responses. It is explicitly controlled by the application author and is not subject to the problems of HTTP/1.1 pipelining. Because WebSockets can send and receive at any time, are directly controlled by the programmer, and are not subject to proxy interference, the pipelining ability is safe and should not be disabled. There is a practical reason why pipelining is disabled in HTTP in Chrome, but there is no reason to give yourself the same limitation when you control the protocol using WebSockets.
An example where this pattern would be extremely useful is in an interactive application like Google Wave. Wave sends character by character updates. With XHR, you must wait for responses to return in order to send additional data to the server. With WebSocket, since you can send at any time, there is no reason to wait.
I hope that clears things up a bit. Special thanks to Kaazing’s Frank Salim for the thorough explanation!