One of the interesting features in the developing HTML5 spec is WebSockets . WebSockets are intended to be exactly what they sound like: TCP-like sockets for use in web applications. (For a more detailed description, read WebSocket is neither Web nor Socket ).
What does a socket-like communication protocol give you that the current HTTP protocol can’t?
The answer: Full-duplex communication.
That is actually only half true. After all, plenty of web applications appear to get asynchronous notifications from the server today. This is commonly referred to as Comet (in keeping with Ajax’s household cleaner theme), real-time web, or reverse-Ajax. Some of the current methods to do this are:
High Frequency Polling – The browser makes repeated, quick HTTP requests to check if new data is available. The server responds immediately with all available data. The whole cycle repeats itself after a short delay. This method provides the illusion of data being “pushed”, but at the expense of being ‘chatty’.
Long Poll – The browser makes a long-lived HTTP request, but the server defers responding until it has data. Once data is available, the server responds and the cycle starts again. This method is not as ‘chatty’ at the previous one, but in runs into another problem. The current HTML spec only allows browsers to maintain two connections back to the server. The result is you can only have one long-poll in each browser window (unless you do your own multiplexing strategy).
Streaming – The browser makes an HTTP requests, but the server does not close the connection after responding. Instead, it leaves it open indefinitely as a pipe that it can stream data into. However, the pipe is only unidirectional. If the browser wants send data to the server it will need to break the pipe.
In contrast, WebSockets would be appear as proper full-duplex communication pipes that break the current request-response cycle inherent to all HTTP communication (however, under the covers they may still use HTTP). This seems to me to be a natural progression of the web. In considering the early “static content” days of web, the HTTP’s request-reponse cycle made sense. Of course non-browser applications at that time made heavy use TCP sockets because they give an application so much flexibility.
Since it would seem that “browsers are the new desktop”, it makes sense to bring this (decades-old) full-duplex communication protocol to the browser. However the more interesting question is what exactly will developers do with it? After all, the internet is moving more and more towards stateless, RESTful communications which would seem to be at odds with stateful socket-like communication. For one interesting opinion on this, take a look at HTML5 WebSocket and WebJneering.