HTTP is by design an asymmetric protocol: clients can contact the server whenever they want (without the user having to issue a command, thanks to Ajax requests). The server instead cannot normally send updates at the client at the time of its choosing.
Connections are made as HTTP requests, GET or POST in nearly all web browsers, from the client to the server, and never the opposite. This mechanism simplifies the protocol in many ways, but raises issues whenever a real-time interaction is desiderable. How to implement a chat in a browser?
There are some work arounds but...
The simplest solution is polling the server continuously: every 5 seconds we send a request, and the server tells us which messages are arrived in the chat room. However this raises the load on the server, which must manage a huge number of new connections at the same time.
A slightly better model is long polling (and other similar techniques which collectively go under the name of Comet), where each connection made by the client is kept open until there are some data to return to the client. The connection may also have a timeout, but it's very simple to just restart one after a 60-second timeout has expired.
The problem with both styles is that they are not really scalable with the current HTTP servers. Apache dedicates one process to each connection - if you have to keep open a process for every user in a chat, the server will quickly halt. There are however different HTTP servers, like CouchDB and Node.js, which do not allocate multiple processes and are capable of handling this large number of simultaneous open connections.
WebSockets
Since we already have to change some server-side infrastructure to support the server pushing to the client on certain events, let's do it with a standard protocol. HTML 5 WebSockets promise a bidirectional full-duplex connection, which is not closed after the first data returned by the server along with headers, but remains open like any TCP connection.
Technically speaking in fact, WebSockets are a mechanism for tunneling a TCP connection over HTTP: you can send whatever you want in the communication channel, but the communication is wrapped into a text stream with HTTP headers such as Host and Origin.
Read more: WebBuilder home