Web Sockets and their ilk

John Kemp, 15th September 2009

Introduction

• HTTP protocol is a client-server protocol, with connections initiated only by the client
• HTTP is not well-suited to the asynchronous delivery of messages to the client
• There are several general use-cases for which these restrictions are onerous:
  • Instant Messaging
  • Multiplayer gaming
  • Streaming data (stock ticker)

People use HTTP to do this anyway...

• "COMET" - combinations of HTTP "long polling" and "response streaming"

  • Bayeux
  • BOSH

Long Polling

+-----------+                    +-----------+
|  Client   |                    |  Server   |
+-----------+                    +-----------+
      |                                |
      +------------------------------->|
      |        1. Connect              |
      |                                +---+
      |                                |   | Make
      |                                |<--+ response
      |<-------------------------------+
      |        2. Response             |
      +------------------------------->|
      |        3. New connection       |
      |                                |

Streaming

+-----------+                    +-----------+
|  Client   |                    |  Server   |
+-----------+                    +-----------+
      |                                |
      +------------------------------->|
      |        1. Connect              |
      |                                +---+
      |                                |   | Make
      |                                |<--+ response
      |<-------------------------------+
      |        2. Partial response     |
      |<-------------------------------+
      |        3. Partial response     |
      |                                |

Issues Remain

• HTTP documented '2-connection limit' [RFC2616]
• Firewalls and transparent proxies
  • UPGRADE header not passed along
  • Some proxies do not send the response until ALL of it is available
• IETF HyBi established to
  • document best practices for existing use
  • discuss proposals for new protocols

Possible Requirements [HyBi]

• "Bidirectionality" over a single socket
• HTTP-style framing (textual headers + arbitrary entity body)
• Multiple channels over a single socket
• Interleaving of messages
• Multiple request/response patterns
• Fallback and capability negotiation

Web Sockets Protocol [WSProtocol]

• Negotiation between client/server via UPGRADE header
• Data is UTF-8 encoded, framed with 0x00 and 0xFF byes
• "Application" responsible for assembling datagrams, metadata and determining framing

Web Sockets API [WSAPI]

• Provides a scripted DOM eventing interface to the WebSocket protocol
  • Open a URL connection to a WebSocket server
  • Fire DOM events for actions such as "onmessage", "onopen" and "onclose"
  • Send messages via objects which implement the interface

The ws:, wss: URI scheme(s)

• wss for TLS-secured connections
• Intended to appear in WebSocket API calls
• Allows proxy auto-configuration identification (page 11 of [WSProtocol])

References

• Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP [BestPractice]
  • http://www.ietf.org/id/draft-loreto-http-bidirectional-00.txt
• The Web Socket Protocol [WSProtocol]
  • http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol
• The Web Sockets API [WSAPI]
  • http://dev.w3.org/html5/websockets/
• Bi-directional Communication for Hypertext [HyBi]
  • http://trac.tools.ietf.org/bof/trac/wiki/HyBi
• HTTP [RFC2616]
  • http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.1.4