HTML5 WebSocket Introduction

Editor's Notes

• #2: VNC Demo: http://vimeo.com/35557394
• #8: Three ways to request info: polling, long-polling, and streaming
• #23: http://caniuse.com/#search=WebSocket
• #26: - Former author: Ian Hickson, Google- Current authors: Ian Fette, Google and Alexey Melnikov, Isode- Former IETF HyBi Working Group co-chair - Joe Hildebrand, Cisco- Current IETF HyBi Working Group co-chairs - Salvatore Loreto, Research Scientist, Ericsson Research, Finland - Gabriel Montenegro, Microsoft- Last Call notification: http://www.ietf.org/mail-archive/web/hybi/current/msg07725.html
• #27: This is what the handshake looks like. If you use the WebSocket API, this is what happens under the covers. It's normal HTTP, and in the first part, the GET, there is an "upgrade" header asking for an upgrade to WebSocket. This header triggers a response from the server which agrees and returns a bunch of headers back to the client with the origin and information on how to establish the WebSocket connection.
• #28: Once you have this WebSocket connection setup you can start sending WebSocket frames. Again, you don't have to worry about creating these frames, you just use the WebSocket API to send your message – this is done under the covers. Your message is taken and put into a WebSocket "frame" that starts with hex-0 and ends with hex-FF bytes, and contains your data in UTF-8 format.You send this data along and effectively there's no real limit to how much data you can send. All of the chunking and lower-level stuff is done for you by the protocol. When binary support is added, the protocol will most likely add a length prefix because binary data may contain hex-0 and hex-FF bytes.
• #30: Remember when we looked at HTTP earlier and saw an example with 871 bytes of header data? For WebSocket that number is 2 bytes. It's always fixed at 2 bytes while HTTP is variable. So you're going from 871 bytes to 2, which is huge reduction in overhead.We didn't explicitly cover it before, but each HTTP message is a brand new TCP connection which comes with some overhead. WebSockets maintain the same TCP connection. So you have two nice advantage of WebSocket over HTTP.
• #31: Here is a graphical view of the data which shows the dramatic reduction in overhead relative to Ajax or Comet for any number of clients.
• #32: Additionally you have a huge latency reduction because every time, as you can see in the polling example, you have a request and response. And each time a request has to be fired from the client. In the meantime, once the WebSocket upgrade has passed and WebSocket connection is established, the server can send messages at will. It doesn't have to wait for a request from the client.So you get 3x improvement in latency with WebSocket.
• #33: Run by the Jetty folks on their optimized Comet server. Emulated a chatroom on EC2. Left: Comet implementation, 2-4ms latency for 5-50K emulated clients @ 10Kmessages/sec. Starts climbing linearly from there up to around 180ms @ 50K messages/sec, except for the 50K client case (hits an internal network limit @ Amazon.)Right: WebSocket implementation of same. 2-4ms latency for all cases _except_ a new 200K client setting that looked like it would start hitting the same internal network limit. (4x as many client, still 5-6 msec.)