How does the HTML5 Web Sockets Interface work?

Question

I heard about the Web Sockets Interface in the HTML file specification from a relevant question here.
It sounds very promising!
I don't understand how it works does it still use the HTTP protocol and works-around it or does it work something like TCP sockets?

Answer 1

The Web Socket protocol is a TCP based protocol, but it is design to downgrade to HTTP. There is also an HTTP handshake that asks the server to upgrade to the Web Sockets protocol. So if the server supports it, then a duplexed TCP connection will be used, otherwise resort to HTTP and the Comet hacks for that.

Answer 2

In a way, it is both an HTTP request and a regular TCP socket.

A websocket connection is requested using a normal HTTP request over TCP. There are some headers sent that indicate to the webserver that it is a websocket that is being requested and not a normal page, but fundamentally it is just an HTTP request.

After the response is sent from the server, the connection is upgraded. That is, the TCP connection that was being used for HTTP is hijacked for a higher calling: bidirectional, realtime data transfer.

Once you have the ability to communicate bidirectionally and efficiently (which is the major win over comet), the horizons of developers is greatly increased. Suddenly, things like MMO games and realtime collaboration, that weren't possible using just web technologies, become possible.

Answer 3

It is not HTTP, nor is it plain TCP sockets. It is designed to get the low overhead of regular socket connections (AJAX/COMET are very high overhead), but without sacrificing some of the browser security principles that have been developed over the past few years.

The initial WebSockets handshake looks a lot like HTTP. This will make it easier for existing HTTP proxies and web server to support incoming WebSockets connections and do the right thing with them (i.e. forwarding them on to the real handler). But after a successful handshake (which includes exchange and validation of origin information), the connection stays open and becomes bidirectional.

Each packet of data (whether sent from server or from the client) begins with a '\x00' (zero byte), is followed by UTF-8 encoded data and ends with a '\xff' (all ones byte).

The current draft standard is here: http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-76

You also might find the wsproxy included in noVNC to be useful as a reference. wsproxy is a generic WebSockets to TCP socket proxy. There is both a C and python version of wsproxy included with noVNC.

http://github.com/kanaka/noVNC/tree/master/utils/

Answer 4

In such a situation the role of server comes when :

In HTML 5,WebSocket like a fone(2-way comm.) not walky-talky. HTTP protocol upgraded to websocket protocol.(wss:// from ws://) SERVER should be able to open duplex channel and hence AGREE with duplex communication. Please also go through this link : http://www.html5rocks.com/en/tutorials/websockets/basics/

Thanks.