The HTML5 WebSocket API
83 likes29,298 views
The HTML5 WebSocket API allows for true full-duplex communication between a client and server. It uses the WebSocket protocol which provides a standardized way for the client to "upgrade" an HTTP connection to a WebSocket connection, allowing for messages to be sent in either direction at any time with very little overhead. This enables real-time applications that were previously difficult to achieve with traditional HTTP requests. Common server implementations include Kaazing WebSocket Gateway, Jetty, and Node.js. The JavaScript API provides an easy way for clients to connect, send, and receive messages via a WebSocket connection.
![What? Header traffic analysis
Example network throughput for WebSocket req/res
headers:
Use case A: 10,000 frames every 60 seconds
Network throughput is (2 x 10,000)/60 = 333 bytes = 2,664 bits
per second (2.6 Kbps) [was 1.1 Mbps]
Use case B: 10,000 frames every second
Network throughput is (2 x 100,000)/1 = 20,000 bytes = 160,000
bits per second (156 Kbps) [was 66 Mbps]
Use case C: 100,000 frames every 10 seconds:
Network throughput is (2 x 100,000)/10 = 20,000 bytes = 160,000
bits per second (156 Kbps) [was 66 Mbps]
(example statistics from Kaazing)
17](https://image.slidesharecdn.com/davidlindkvistwebsocketapisthlmwebmonkeyscopy-100421141801-phpapp02/85/The-HTML5-WebSocket-API-17-320.jpg)
![How? The WebSocket interface
[Constructor(in DOMString url, in optional DOMString protocol)]
interface WebSocket {
readonly attribute DOMString URL;
// ready state
const unsigned short CONNECTING = 0;
const unsigned short OPEN = 1;
const unsigned short CLOSING = 2;
const unsigned short CLOSED = 3;
readonly attribute unsigned short readyState;
readonly attribute unsigned long bufferedAmount;
// networking
attribute Function onopen;
attribute Function onmessage;
attribute Function onerror;
attribute Function onclose;
boolean send(in DOMString data);
void close();
};
WebSocket implements EventTarget;
20](https://image.slidesharecdn.com/davidlindkvistwebsocketapisthlmwebmonkeyscopy-100421141801-phpapp02/85/The-HTML5-WebSocket-API-20-320.jpg)
The HTML5 WebSocket API
- 1. The HTML5 WebSocket API Stockholm Web Monkeys
- 2. $ whoami David Lindkvist kontain.com/david-lindkvist twitter.com/ffdead Application Developer @F_i Web development is my passion! Drummer myspace.com/vildhjarta myspace.com/terminalfunction 2
- 3. Agenda Why do we need WebSockets? What is it? How does it work? When can we use it? 3
- 4. Why? 4
- 5. Why? Today’s web apps demand reliable event-driven communications “Real-time” (minimal latency) Full duplex Examples: Social networking Online games Collaborative platforms Financial applications etc... 5
- 6. Why? Problems with HTTP... It’s hard to achieve real-time apps, primarily due to the limitations of HTTP HTTP is half-duplex (traffic flows in only one direction at a time) HTTP adds latency and message overhead 6
- 7. Why? Simulate real-time? Polling (AJAX) Poll server for updates, wait at client Long polling (Comet) Poll server for updates, wait at the server; uses two connections and requires unnecessary complexity Used in Ajax applications to simulate real-time Leads to poor resource utilization... 7
- 8. Why? Polling #$%%&'()*+,-&./,.0+/ !""#$%&"'()'"'$*+&,!&')- (picture from Kaazing) !"#$"%$!$ 1)233")4 5667&'()8$+9$+6.&$' !"#$"%$!$ !" !" 8
- 9. Why? Long Polling #$%&'($))*%&+,-./*01.02-1 (picture from Kaazing) !"#$"%$!$ 3+!""4+5 6778*%&+9$-:$-70*$% !"#$"%$!$ !" !" 9
- 10. Why? HTTP req/res overhead GET /PollingStock//PollingStock HTTP/1.1 Host: localhost:8080 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 691 chars Connection: keep-alive Referer: http://localhost:8080/PollingStock/ Cookie: showInheritedConstant=false; showInheritedProtectedConstant=false; showInheritedProperty=false; showInheritedProtectedProperty=false; showInheritedMethod=false; showInheritedProtectedMethod=false; showInheritedEvent=false; showInheritedStyle=false; showInheritedEffect=false HTTP/1.x 200 OK X-Powered-By: Servlet/2.5 Server: Sun Java System Application Server 9.1_02 Content-Type: text/html;charset=UTF-8 Content-Length: 321 Date: Sat, 07 Nov 2009 00:32:46 GMT Total 871 chars (example from Kaazing) 10
- 11. Why? Header traffic analysis Example network throughput for Polling HTTP req/resp headers: Use case A: 10,000 clients polling every 60 seconds Network throughput is (871 x 10,000)/60 = 145,166 bytes = 1,161,328 bits per second (1.1 Mbps) Use case B: 10,000 clients polling every second Network throughput is (871 x 10,000)/1 = 8,710,000 bytes = 69,680,000 bits per second (66 Mbps) Use case C: 100,000 clients polling every 10 seconds Network throughput is (871 x 100,000)/10 = 8,710,000 bytes = 69,680,000 bits per second (66 Mbps) (example statistics from Kaazing) 11
- 12. What? 12
- 13. What is a WebSocket? W3C/IETF Standard Uses the WebSocket protocol instead of HTTP True full-duplex communication channel Both UTF-8 strings and binary frames can be sent in any direction at the same time It’s not a raw TCP socket 13
- 14. What is a WebSocket? Connection established by “upgrading” from HTTP to WebSocket protocol Runs via port 80/443 - Proxy/Firewall friendly HTTP-compatible handshake Integrates with Cookie based authentication WebSockets and Secure WebSockets ws:// wss:// 14
- 15. What? Upgrade handshake // browser request to the server GET /demo HTTP/1.1 Upgrade: WebSocket Connection: Upgrade Host: example.com Origin: http://example.com WebSocket-Protocol: sample // server response HTTP/1.1 101 Web Socket Protocol Handshake Upgrade: WebSocket Connection: Upgrade WebSocket-Origin: http://example.com WebSocket-Location: ws://example.com/demo WebSocket-Protocol: sample 15
- 16. What? Reduces Network Traffic Each message (“frame”) has only 2 bytes of overhead No latency from establishing new TCP connections for each HTTP message No polling overhead - only sends messages when there is something to send 16
- 17. What? Header traffic analysis Example network throughput for WebSocket req/res headers: Use case A: 10,000 frames every 60 seconds Network throughput is (2 x 10,000)/60 = 333 bytes = 2,664 bits per second (2.6 Kbps) [was 1.1 Mbps] Use case B: 10,000 frames every second Network throughput is (2 x 100,000)/1 = 20,000 bytes = 160,000 bits per second (156 Kbps) [was 66 Mbps] Use case C: 100,000 frames every 10 seconds: Network throughput is (2 x 100,000)/10 = 20,000 bytes = 160,000 bits per second (156 Kbps) [was 66 Mbps] (example statistics from Kaazing) 17
- 18. What? Overheard "Reducing kilobytes of data to 2 bytes...and reducing latency from 150ms to 50ms is far more than marginal. In fact, these two factors alone are enough to make WebSocket seriously interesting to Google.“ - Ian Hickson (Google, HTML5 spec lead) 18
- 19. How? 19
- 20. How? The WebSocket interface [Constructor(in DOMString url, in optional DOMString protocol)] interface WebSocket { readonly attribute DOMString URL; // ready state const unsigned short CONNECTING = 0; const unsigned short OPEN = 1; const unsigned short CLOSING = 2; const unsigned short CLOSED = 3; readonly attribute unsigned short readyState; readonly attribute unsigned long bufferedAmount; // networking attribute Function onopen; attribute Function onmessage; attribute Function onerror; attribute Function onclose; boolean send(in DOMString data); void close(); }; WebSocket implements EventTarget; 20
- 21. How? The Javascript client connect: function () { try { this.ws = new WebSocket(’ws://www.example.com’); this.ws.onopen = function (event) {/*...*/}; this.ws.onclose = function (event) {/*...*/}; this.ws.onmessage = messageListener; } catch(exception) {} }, messageListener: function (event) { alert(’New message: ’ + event.data) }, send: function (message) { if (this.ws) { this.ws.send(message); } }, 21
- 22. How? The server Server implementations (mostly experimental): Kaazing WebSocket Gateway (production since april 2009) phpwebsockets web-socket-ruby mod_pywebsocket JWebSocket Jetty WebSocketServlet and many more... 22
- 23. How? Jetty server example public class MyServlet extends HttpServlet implements Servlet { // trigger on HTTP GET request public void doGet(HttpServletRequest req, HttpServletResponse res) {} // trigger on HTTP POST request public void doPost(HttpServletRequest req, HttpServletResponse res) {} // doWebSocket() ??? } 23
- 24. How? Jetty server example public class ChatServiceServlet extends WebSocketServlet implements Servlet { public void doGet(HttpServletRequest req, HttpServletResponse res) {} public void doPost(HttpServletRequest req, HttpServletResponse res) {} // trigger on request to upgrade to WebSocket connection protected WebSocket doWebSocketConnect(HttpServletRequest req, String arg) { return new ChatWebSocket(); } // shared resource - needs to be thread safe! Set<ChatWebSocket> clients = new CopyOnWriteArraySet<ChatWebSocket>(); class ChatWebSocket implements WebSocket { /* impl on next slide... */ } } 24
- 25. How? Jetty server example class ChatWebSocket implements WebSocket { Outbound outbound; public void onConnect(Outbound outbound) { this.outbound = outbound; clients.add(this); } public void onMessage(byte frame, String data) { for (ChatWebSocket socket : clients) { try { socket.outbound.sendMessage(frame, data); } catch(IOException e) {} } } public void onDisconnect() { clients.remove(this); } } 25
- 26. How? It’s not a silver bullet How should we handle the “close” event? Application must be prepared to reopen connection if close event was triggered unexpectedly Idle timeout Network errors 26
- 27. How? It’s not a silver bullet Keep-alives Sending keep-alive messages to prevent closing due to an idle timeout No timeout discovery available on the WebSocket Keep-alives don’t avoid the need for handling “close” events WiFi connections and mobile devices 27
- 28. How? It’s not a silver bullet Queues Buffer messages that failed to send due to a transient network problem Resend queue when connection is restored Important for both server and client 28
- 29. How? It’s not a silver bullet Timeouts Not all network problems are transient Can’t allow queues to grow for ever Applications need a timeout when user is considered to be disconnected Need to implement an explicit close message for application to distinguish between network failures and an orderly close 29
- 30. How? It’s not a silver bullet Message Retries Even with queues we can’t know for sure messages are delivered due to race condition If close event is triggered soon after a message was sent? For quality of service to be guaranteed an acknowledge message would have to be sent for each message Ideally a future version of WebSockets would support an orderly close event 30
- 31. How? It’s not a silver bullet onclose handing, keep-alives, message queues, timeouts and retries, introduce more problems: If server goes down client will loop trying to reconnect Needs a retry backoff algorithm to reduce retries over time Message size can cause connection to die if it exceeds some resource limit on client or server Looks like a transient network error... Connection is restored and retries to send same message from queue... Infinite loop! 31
- 32. When? 32
- 33. When? Current browser support: CHROME 33
- 34. When? Browser support Status of native WebSocket support for other browsers (2010-04-11): Firefox - targeted for the v3.7 release but not yet in 3.7a4pre Safari - announced for 4.x but no target date yet Opera - 10.x already 95% HTML5 compatible but WebSockets missing IE 8.x - 9.x unknown (reference: jWebSocket project) 34
- 35. When? Graceful degradation for the next ~10 years.... Realtime apps: Java Applet TCP Socket Flash XMLSockets over TCP Long polling over HTTP Not so realtime apps: Polling using periodical pulls over HTTP 35
- 36. When? Providing fallbacks mean more work. More works sucks.. Solution: Look for a client library which implements the WebSocket interface! Kaazing jWebSocket Users will be able to take advantage of true WebSockets when their browser supports it 36
- 37. When? Or... roll your own! Introducing the Graceful WebSocket: A jQuery plugin implementing the WebSocket interface One interface = one implementation Uses the native WebSocket if available Automatic fallback on HTTP polling 37
- 38. Get involved? Visit the Graceful WebSocket project over at Google Code: http://code.google.com/p/jquery-graceful-websocket/ 38
- 39. Summary Allows us to write real-time, event driven applications Better resource utilization, less latency, less network overhead Browser support so far is poor Specification is not finalized 39
- 40. References? W3C The WebSocket API HTML5 Communications - Frank Greco (Kaazing) jfokus 2010 http://en.wikipedia.org/wiki/Web_Sockets Greg Wilkins Jetty WebSocket Server Greg Wilkins Websocket Chat http://jwebsocket.org/ 40
- 41. Thanks! oh... and we are hiring! http://www.f-i.com/careers 41