Taking a Quantum Leap with Html 5 WebSocket

  • 3,925 views
Uploaded on

Taking bi-directional communication on the web to the next level - HTML 5 WebSockets in Theory and Practice. …

Taking bi-directional communication on the web to the next level - HTML 5 WebSockets in Theory and Practice.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
3,925
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
74
Comments
0
Likes
3

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • With streaming, the browser sends a complete request, but the server sends and maintains an open response that is continuously updated and kept open indefinitely (or for a set period of time). The response is then updated whenever a message is ready to be sent, but the server never signals to complete the response, thus keeping the connection open to deliver future messages. However, since streaming is still encapsulated in HTTP, intervening firewalls and proxy servers may choose to buffer the response, increasing the latency of the message delivery. Therefore, many streaming Comet solutions fall back to long-polling in case a buffering proxy server is detected. Alternatively, TLS (SSL) connections can be used to shield the response from being buffered, but in that case the setup and tear down of each connection taxes the available server resources more heavily.
  • With streaming, the browser sends a complete request, but the server sends and maintains an open response that is continuously updated and kept open indefinitely (or for a set period of time). The response is then updated whenever a message is ready to be sent, but the server never signals to complete the response, thus keeping the connection open to deliver future messages. However, since streaming is still encapsulated in HTTP, intervening firewalls and proxy servers may choose to buffer the response, increasing the latency of the message delivery. Therefore, many streaming Comet solutions fall back to long-polling in case a buffering proxy server is detected. Alternatively, TLS (SSL) connections can be used to shield the response from being buffered, but in that case the setup and tear down of each connection taxes the available server resources more heavily.
  • WebSocket is text-only
  • HTTP used for handshake onlyOperates over a single socketTraverses firewalls and routers seamlesslyAllows authorized cross-site communicationCookie-based authenticationExisting HTTP load balancersNavigates proxies using HTTP CONNECT, same technique as https, but without the encryption
  • Text type requires high-order bit setBinary type requires high-order bit _not_ setThere is no defined maximum size. However, the protocol allows either side (browser or server) to terminate the connection if it cannot receive a large frame. So far, the definition of too large is left up to the implementation.If the user agent is faced with content that is too large to behandled appropriately, then it must fail the Web Socket connection.There is probably a practical maximum, but we have not discovered it as far as I know.You can't have four gigabytes of data in JavaScript, so the practical max is <4GB for the JavaScript implementation.
  • 150 ms (TCP round trip to set up the connection plus a packet for the message)50 ms (just the packet for the message)
  • 150 ms (TCP round trip to set up the connection plus a packet for the message)50 ms (just the packet for the message)

Transcript

  • 1. Taking a Quantum Leap with Html 5 WebSocket:
    Taking bi-directional communication on the web to the next level
    Comet Never More!
    (HTML 5 WebSockets in Theory and Practice)
    Shahriar Hyder
    Kaz Software Ltd.
    WebSockets == “TCP for the Web”
  • 2. Complexity does not scale
  • 3. Push technologies
    Flash sockets
    Silverlight duplex services
    Comet
    WebSockets
  • 4. Client-server Communication
    AJAX
    WebSockets
    Comet
  • 5. HTTP Is Not Full Duplex
    Source: http://www.slideshare.net/peterlubbers/html5-web-workersunleashed
  • 6. Half-Duplex Architecture
    Source: http://www.slideshare.net/peterlubbers/html5-web-workersunleashed
  • 7. Polling, Long-Polling, Streaming … Comet — Headache 2.0
    Use Comet to spellCOMplExiTy…
    Source: http://www.slideshare.net/peterlubbers/html5-web-workersunleashed
  • 8. AJAX: Polling
    Attempting to simulate bi-directional communications with AJAX requires polling schemes, which blindly check for updates irrespective of state changes in the app. The result is poor resource utilization on both the client and server, since CPU-cycles and memory are needlessly allocated to prematurely or belatedly detect updates on the server.
    Consequently, depending on the rate in which events are published on the server, traditional AJAX apps must constantly strike a balance between shorter and longer polling intervals in an effort to improve the accuracy of individual requests.
  • 9. AJAX: Polling
    High polling frequencies result in increased network traffic and server demands, while low polling frequencies result in missed updates and the delivery of stale information. In either case, some added latency is incurred.
    In low-message-rate situations, many connections are opened and closed needlessly.
    There are two types of polling, short polling and long polling.
  • 10. Short polling
    Short polling is implemented by making a request to the web server every few seconds or so to see if data has changed. If it has, the web server will respond with the new data. Otherwise, it will respond with a blank message. The drawback to this technique, however, is both a surplus in server requests and an overhead in CPU usage on the web server to constantly check if an update to the data has been made.
  • 11. Long Polling
    Also known as asynchronous-polling
    Browser sends a request to the server and the server keeps the request open for a set period
    If a notification is received within that period, a response containing the message is sent to the client. If a notification is not received within the set time period, the server sends a response to terminate the open request.
    HTTP headers, present in both long-polling and polling often account for most of the network traffic
    In high-message rate situations, long-polling results in a continuous loop of immediate polls
    The drawback to this technique, like short polling, is that the web server still has to check if the data has changed every few seconds or so, creating an overhead in CPU usage.
  • 12. Streaming
    With streaming, the browser sends a complete request, but the server sends and maintains an open response that is continuously updated and kept open indefinitely (or for a set period of time). The response is then updated whenever a message is ready to be sent, but the server never signals to complete the response, thus keeping the connection open to deliver future messages.
    However, since streaming is still encapsulated in HTTP, intervening firewalls and proxy servers may choose to buffer the response, increasing the latency of the message delivery. Therefore, many streaming Comet solutions fall back to long-polling in case a buffering proxy server is detected. Alternatively, TLS (SSL) connections can be used to shield the response from being buffered, but in that case the setup and tear down of each connection taxes the available server resources more heavily.
  • 13. Streaming
    More efficient, but sometimes problematic
    Possible complications:
    o Proxies and firewalls
    o Response builds up and must be flushed periodically
    o Cross-domain issues to do with browser connection limits
  • 14. Streaming
    One benefit of streaming is reduced network traffic, which is the result of sending packets that only contain data rather than packets that contain both data and HTTP headers. The downside of streaming is that it is still encapsulated in HTTP, so intervening HTTP proxies may choose to buffer the response, increasing the latency of the message delivery.
  • 15. Callback-Polling or JSONP-Polling
    Long-polling, but works cross-domain
    Relies on JSONP technique for establishing trust
    <script> blocks instead of XHR
  • 16. Comet
    Comet is known by several other names, including Ajax Push, Reverse Ajax, Two-way-web, HTTP Streaming, and HTTP server push among others.
    The Comet model for communications was a departure from that found in the classical web model, in which events are client initiated. The most obvious benefit of Comet's model is the server's ability to send information to the browser without prompting from a client. However, this "push" style of communications has limited uses.
  • 17. Comet: Two Connections, Bi-directional
    Comet attempted to deliver bi-directional communications by maintaining a persistent connection and a long-lived HTTP request on which server-side events could be sent to the browser, and making upstream requests to the server on a newly opened connection. The maintenance of these two connections introduces significant overhead in terms of resource consumption, which translates into added latency for sites under peak load.
    In addition, Comet solutions that employ a long-polling technique send undue HTTP request/response headers. Each time an event is sent by the server, the server severs its connection with the client browser, forcing the browser to reestablish its connection with the server. This action causes another client request and server response to be sent across the wire. Neither HTTP streaming nor Web Socket incur this network overhead.
  • 18. Comet: Two Connections, Bi-directional
    Most Comet implementations rely on the Bayeux protocol. The use of this protocol requires messages from the origin services to be transformed from the messages' initial format to conform to the Bayeux protocol. This transformation introduces unnecessary complexity in your system, requiring developers to manipulate one message format on the server (e.g., JMS, IMAP, XMPP, etc.) and a second message format (e.g., Bayeux and JSON) on the client. Moreover, the transformation code used to bridge your origin protocol to Bayeux introduces an unnecessary performance overhead into your system by forcing a message to be interpreted and processed prior to being sent over the wire. With Web Sockets, the message sent by the server is the same message delivered to the browser, eliminating the complexity and performance concerns introduced by transformation code.
  • 19. Solutions or Hacks?
    But if you think about it, these techniques are just hacks, tricks used to simulate a technology that doesn’t exist: server-sent events. If the server could actually start the communication, none of these ugly tricks would be needed.
  • 20. HTTP Request Headers
    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
    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;
  • 21. HTTP Response Headers
    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 (unnecessary) HTTP request and response header information overhead: 871 bytes (example)
    • 22. Overhead can be as much as 2000 bytes
    • 23. Does not scale!
  • Enter HTML5 WebSocket!
    Source: http://www.slideshare.net/peterlubbers/html5-web-workersunleashed
  • 24. Specification Stage
  • 25. Yawn…
    … so why do we need WebSockets?
    Source: http://www.slideshare.net/goberoi/intro-to-websockets
  • 26. 2 good reasons
    Source: http://www.slideshare.net/goberoi/intro-to-websockets
  • 27. Desire for real-time
    Want low latency 2-way communication for:
    Multiplayer online games (pong)
    Collaboration (live wikis)
    Dashboards (financial apps)
    Tracking (watch user actions)
    Presence (chat with customer support)
    Live sports ticker
    Updating social streams / Social Networking (Twitter Feed)
    Smart power grid
    More!
    Source: http://www.slideshare.net/goberoi/intro-to-websockets
  • 28. HTTP doesn’t deliver
    People hack around this (see “Comet”)
    Polling, long-polling, stream via hidden iframe
    BUT these are slow, complex, and bulky
    Or rely on plugins:
    Flash, SilverLight, Java applets
    BUT these don’t work everywhere (phones)
    Source: http://www.slideshare.net/goberoi/intro-to-websockets
  • 29. Damn, this is hairy:
    Source: http://www.slideshare.net/ismasan/websockets-and-ruby-eventmachine
  • 30. Vs. HTTP hacks, WebSockets provide:
    Lower latency: no new TCP connections for each HTTP request
    Lower overhead: for each message sent(2 bytes vs. lines of HTTP header junk)
    Less traffic: since clients don’t need to poll, messages only sent when we have data
    Source: http://www.slideshare.net/goberoi/intro-to-websockets
  • 31. What are WebSockets?
    +
    = ?
    Source: http://www.slideshare.net/goberoi/intro-to-websockets
  • 32. Definition
    The WebSocket specification—developed as part of the HTML5 initiative—introduced the WebSocket JavaScript interface, which defines a full-duplex, bi-directional communication channel over a single TCP socket over which messages can be sent between client and server. The WebSocket standard simplifies much of the complexity around bi-directional web communication and connection management.
    This allows web developers to establish real time two way communications with a server using simple JavaScript without resorting to Flash, Java, Ajax long polling, comet, forever iframe, or other current workarounds.
  • 33. HTML5 WebSocket
    • W3C API and IETF Protocol
    • 34. Full-duplex, single socket
    • 35. Enables web pages to communicate with a remote host
    • 36. Traverses firewalls, proxies, and routers seamlessly
    • 37. Leverages Cross-Origin Resource Sharing (CORS)
    • 38. Share port with existing HTTP content
    • 39. Dramatic overhead reduction
    Source: http://www.slideshare.net/peterlubbers/html5-web-workersunleashed
  • 40. HTML5 WebSocket Schemes
  • 41. HTML5 WebSocket Schemes
    • WebSocket
    ws://www.websocket.org/text
    • WebSocket Secure
    wss://www.websocket.org/encrypted-text
    Source: http://www.slideshare.net/peterlubbers/html5-web-workersunleashed
  • 42. Possible WebSocket Architecture
    Source: http://www.slideshare.net/peterlubbers/html5-web-workersunleashed
  • 43. HTML5 WebSocket
    • Connection established by upgrading from the HTTP protocol to the WebSocket protocol using the same TCP connection
    • 44. Once upgraded, WebSocket data frames can be sent back and forth between the client and the server in full-duplex mode
    Source: http://www.slideshare.net/peterlubbers/html5-web-workersunleashed
  • 45. HTML5 WebSocket Handshake
    Client
    GET /text HTTP/1.1Upgrade: WebSocketConnection: UpgradeHost: www.example.com
    Origin: http://example.com
    WebSocket-Protocol: sample…rn
    Server
    HTTP/1.1 101 WebSocket Protocol HandshakeUpgrade: WebSocketConnection: Upgrade
    WebSocket-Origin: http://example.com
    WebSocket-Location: ws://example.com/demo
    WebSocket-Protocol: sample…rn
    Source: http://www.slideshare.net/peterlubbers/html5-web-workersunleashed
  • 46. HTML5 WebSocket Frames
    • Frames can be sent full-duplex, in either direction at the same time
    • 47. Each frame of data:
    • 48. Starts with a 0x00 byte
    • 49. Ends with a 0xFF byte
    • 50. Contains UTF-8 data in between
    Source: http://www.slideshare.net/peterlubbers/html5-web-workersunleashed
  • 51. Example
    • x00Hello, WebSocket0xff
    • 52. There is no defined maximum size
    o If the user agent has content that is too large to be handled, it must fail the Web Socket connection
    o JavaScript does not allow >4GB of data, so that is a practical maximum
    Source: http://www.slideshare.net/peterlubbers/html5-web-workersunleashed
  • 53. Dramatic Reduction in Network Traffic
    • With WebSocket, each frame has only 2 bytes of packaging (a 500:1 or even 1000:1 reduction)
    • 54. No latency involved in establishing new TCP connections for each HTTP message
    • 55. Dramatic reduction in unnecessary network traffic and latency
    • 56. Remember the Polling HTTP header traffic?
    Source: http://www.slideshare.net/peterlubbers/html5-web-workersunleashed
  • 57. Latency Reduction
    Source: http://www.slideshare.net/peterlubbers/html5-web-workersunleashed
  • 58. 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)
    Source: http://www.slideshare.net/peterlubbers/html5-web-workersunleashed
  • 59. Using the WebSocket API
  • 60. JavaScript
    //Checking for browser support
    if (window.WebSocket) {
    document.getElementById("support").innerHTML = "HTML5 WebSocket is supported";
    } else {
    document.getElementById("support").innerHTML = "HTML5 WebSocket is not supported";
    }
    Source: http://www.slideshare.net/peterlubbers/html5-web-workersunleashed
  • 61. JavaScript
    //Create new WebSocket
    var mySocket = new WebSocket(“ws://www.websocket.org”);
    // Associate listeners
    mySocket.onopen = function(evt) {
    alert(“Connection open…”);
    };
    mySocket.onmessage = function(evt) {
    alert(“Received message: “ + evt.data);
    };
    mySocket.onclose = function(evt) {
    alert(“Connection closed…”);
    };
    Source: http://www.slideshare.net/peterlubbers/html5-web-workersunleashed
  • 62. JavaScript
    // Sending data
    mySocket.send(“HTML5 WebSocket Rocks!”);
    //Close WebSocket
    mySocket.close();
    Source: http://www.slideshare.net/peterlubbers/html5-web-workersunleashed
  • 63. Extending WebSocket
    • Once you have WebSocket, you can communicate with WebSocket Servers and back-end servers and directly with message brokers
    • 64. You can extend client-server protocols to the web:
    • 65. XMPP, Jabber
    • 66. Pub/Sub (Stomp/AMQP)
    • 67. Gaming protocols
    • 68. Any TCP-based protocol
    • 69. Browser becomes a first-class network communication citizen
    Source: http://www.slideshare.net/peterlubbers/html5-web-workersunleashed
  • 70. WebSocket Server Support
    • Socket.IO (server side implementations for Java and node.js)
    • 71. node-websocket-server
    • 72. Jetty WebSocketServlet(Java)
    • 73. Ruby: Event Machine + em-websocket
    • 74. Python: Twisted + txWebSocket
    • 75. JavaScript: Node.js + WebSocket module
    • 76. Kaazing WebSocket Gateway (production since April 2009)
    • 77. phpwebsockets
    • 78. web-socket-ruby
    • 79. Apache mod-pywebsocket
    • 80. JWebSocket
    • 81. Yaws (Erlang)
  • Browser Support
    Emulation available through Kaazing WebSocket Gateway
    Source: http://www.slideshare.net/peterlubbers/html5-web-workersunleashed
  • 85. DEMO TIME!
    Source: http://www.slideshare.net/peterlubbers/html5-web-workersunleashed
  • 86. Quake II Gamehttp://code.google.com/p/quake2-gwt-port
    Source: http://www.slideshare.net/peterlubbers/html5-web-workersunleashed
  • 87. Proxy Servers
    Source: http://www.slideshare.net/peterlubbers/html5-web-workersunleashed
  • 88. Proxy server traversal decision tree
    Source: http://www.slideshare.net/peterlubbers/html5-web-workersunleashed
  • 89. Summary
    Low latency is the mother of interactivity, and in no place is this more apparent than on the Web. Every slip of a millisecond equates to a slower end-user experience, which in turn translates into elevated risk that a user's eyes will avert elsewhere. Both AJAX and Comet attempt to obscure latency problems, and certainly address the issue of user-perceived latency. However, Web Socket removes the need to obscure such problems and introduces a real solution, one that does not play tricks on the perception of our end users, but delivers content in real time with real results.
    HTML5 Web Socket provides an enormous step forward in the scalability of the real-time web. As you have seen here, HTML5 Web Sockets can provide a 500:1 or - depending on the size of the HTTP headers - even a 1000:1 reduction in unnecessary HTTP header traffic and 3:1 reduction in latency. That is not just an incremental improvement; that is a revolutionary jump - a quantum leap.
  • 90. Concluding statement
    If HTTP did not restrict your creativity,what Web application would YOU create?