HTML 5 Web Socket
The HTML 5 specification introduces the Web Socket interface, which defines a full-duplex communications channel that operates over a single socket and is exposed via a JavaScript interface in HTML 5 compliant browsers. The bi-directional capabilities of Comet and AJAX, unlike Web Sockets, are not native to the browser, and rely on maintaining two connections - one for upstream and one for downstream - in order to stream data to and from the browser. Note, that to support streaming over HTTP, Comet requires a long-lived connection, which is often severed by proxies and firewalls. In addition, few Comet solutions support streaming over HTTP, employing a less performant technique called "long-polling" instead.

Web Sockets account for network hazards such as proxies and firewalls, making streaming possible over any connection, and with the ability to support  upstream and downstream communications over a single connection, Web Sockets place less burden on your servers, allowing existing machines to support more than twice the number of concurrent connections.

Simple Is Better
With the introduction of one succinct interface, we can now divorce ourselves from the mind-bending hacks all too often associated with Comet and focus on the task at hand, namely your application logic. Furthermore, by moving to a single, streaming channel of communications, we can overcome the inadequacies of techniques such as long-polling and "forever frames," and as a result further reduce latency.

[Constructor(in DOMString url)]
interface WebSocket {
readonly attribute DOMString URL;
// ready state
const unsigned short CONNECTING = 0;
const unsigned short OPEN = 1;
const unsigned short CLOSED = 2;
readonly attribute int readyState;
// networking
attribute EventListener onopen;
attribute EventListener onmessage;
attribute EventListener onclosed;
void postMessage(in DOMString data);
void disconnect();
};

Utilizing the Web Socket interface couldn't be simpler. To connect to an end-point, just create a new Web Socket instance, providing the new object with a URL that represents the end-point to which you wish to connect.

var myWebSocket = new WebSocket("ws://www.websocket.org");

Note that a ws:// and wss:// prefix indicate a Web Socket and a secure Web Socket connection, respectively. A Web Socket connection is established by upgrading from the HTTP protocol to the Web Socket protocol during the initial handshake between the client and the server, over the same underlying TCP/IP connection. Once established, Web Socket data frames can be sent back and forth between the client and the server in full-duplex mode. The connection itself is exposed via the onmessage and postMessage methods defined by the Web Socket interface.

Before connecting to an end-point and sending a message, you can associate a series of event listeners to handle each phase of the connection life cycle.

myWebSocket.onopen = function(evt) { alert("Connection open ..."); };
myWebSocket.onmessage = function(evt) { alert( "Received Message:  "  +  evt.data); };
myWebSocket.onclose = function(evt) { alert("Connection closed."); };

To send a message to the server, simply call postMessage and provide the content you wish to deliver. After sending the message, call disconnect to terminate the connection.

myWebSocket.postMessage("Hello Web Socket! Goodbye Comet!");
myWebSocket.disconnect();

As you can see, it really couldn't be much easier.

Firewalls and Proxies? No Problem
One of the more unique features Web Socket provides is its ability to traverse firewalls and proxies, a problem area for many Comet-enabled applications. Comet-style applications typically employ long-polling as a rudimentary line of defense against firewalls and proxies. The technique is effective, but is not well suited for applications that have sub-500 millisecond latency or high throughput requirements. Plugin-based technologies such as Adobe Flash also provide some level of socket support, but have long been burdened with the very proxy and firewall traversal problems that Web Sockets now resolve.

A Web Socket detects the presence of a proxy server and automatically sets up a tunnel to pass through the proxy. The tunnel is established by issuing an HTTP CONNECT statement to the proxy server, which requests for the proxy server to open a TCP/IP connection to a specific host and port. Once the tunnel is set up, communication can flow unimpeded through the proxy. Since HTTP/S works in a similar fashion, secure Web Sockets over SSL can leverage the same HTTP CONNECT technique. Note that Web Sockets are not natively supported by modern browsers; however, there is one vendor that provides an implementation that enables today's browsers to take advantage of this emerging technology. Kaazing and its Kaazing Enterprise Gateway offering, due for release in September 2008 as an open source initiative, will be an enterprise-grade implementation of Web Sockets.

Any RIA, Any Time
In addition, the Web Socket protocol can be used to support a diverse set of clients (e.g., JavaScript, Adobe Flex, JavaFX, Microsoft Silverlight). However, the HTML 5 specification only defines support for JavaScript, which is limited to text-based protocols. To serve other client types and support binary protocols, you will need to look to vendor offerings. Fortunately, Kaazing offers client-side libraries for other client types such as Adobe Flex and, in the future, Microsoft Silverlight that do support binary types, enabling more than text-based services to reach the browser. In addition, Kaazing's Enterprise Gateway JavaScript libraries offer binary support, which supports binary types in JavaScript via Base64 encoding.

Web Sockets vs. Comet vs. AJAX
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. Bi-directional communications are vital to develop and deliver meaningful applications that can participate in real-time conversations.

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.

AJAX: Polling
Attempting to simulate bi-directional communications with AJAX requires polling schemes, which blindly check for updates irrespective of state changes in the application. 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 applications must constantly strike a balance between shorter and longer polling intervals in an effort to improve the accuracy of individual requests. Furthermore, 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.

Web Sockets: Single Connection, Full-duplex
Though Comet and AJAX can both deliver end-user experiences that provide desktop-like functionality and low user-perceived latency, only Web Sockets live up to the promise of providing a native means to accurately and efficiently stream events to and from the browser with negligible latency. It is by far the most comprehensive solution for delivering real-time information over the Web. Not only does it provide full asynchronous duplex streaming communication with a single TCP/IP connection, but also benefits from few HTTP headers and, more important, it allows the same message format to be used by both the browser and the origin service.

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.