The interesting part is this:
Currently, we use XHR long polling, keep alive. Basically a raw socket with some HTTP header spam mixed in.
On the plus side, we can deflate/gzip the contents (unfortunately not across messages, but still does well). But on the negative, the HTTP headers are often about the same size or larger than the contents.
So, webSocket will improve the situation, in that there won't be HTTP header spam. Also we'll be able to use a single connection instead of two (One for sends, one for recvs). On the downside, there also won't be any deflate/gzip (Unless implemented in js etc).
The other big bonus with WebSocket is you can connect to a different port. Something that's not possible (For some idiotic reason) with XHR.
It'll be interesting to see which one wins :)
Pretty cool to see this in Chrome, I thought Firefox would be first to implement it.