The WebSocket protocol enables full-duplex interaction between a web browser (or other client application) and a web server with lower overhead than half-duplex alternatives such as HTTP polling, facilitating real-time data transfer from and to the server.
Similar two-way browser–server communications have been achieved in non-standardized ways using stopgap technologies such as Comet or Adobe Flash Player.
[4] Most browsers support the protocol, including Google Chrome, Firefox, Microsoft Edge, Internet Explorer, Safari and Opera.
[8] In June 2008, a series of discussions were led by Michael Carter that resulted in the first version of the protocol known as WebSocket.
In December 2009, Google Chrome 4 was the first browser to ship full support for the standard, with WebSocket enabled by default.
[11] Development of the WebSocket protocol was subsequently moved from the W3C and WHATWG group to the IETF in February 2010, and authored for two revisions under Ian Hickson.
[12] After the protocol was shipped and enabled by default in multiple browsers, the RFC 6455 was finalized under Ian Fette in December 2011.
Sec-WebSocket-Key and Sec-WebSocket-Accept are intended to prevent a caching proxy from re-sending a previous WebSocket conversation,[39] and does not provide any authentication, privacy, or integrity.
[40] It also enables multiplexing several streams simultaneously (e.g. to avoid monopolizing a socket for a single large payload).
[41] Web API [54] A secure version of the WebSocket protocol is implemented in Firefox 6,[55] Safari 6, Google Chrome 14,[56] Opera 12.10 and Internet Explorer 10.
Therefore, WebSocket servers must validate the "Origin" header against the expected origins during connection establishment, to avoid cross-site WebSocket hijacking attacks (similar to cross-site request forgery), which might be possible when the connection is authenticated with cookies or HTTP authentication.
In some cases, additional proxy-server configuration may be required, and certain proxy servers may need to be upgraded to support WebSocket.
Using encryption is not free of resource cost, but often provides the highest success rate, since it would be travelling through a secure tunnel.