Contents
Real-Time Communication Protocol
AJAX popularized for dynamic web apps
2005
Comet model coined
2006
WebSocket concept proposed
2008
First browser support
2009
RFC 6455 published
2011
WebSocket is a communication protocol that provides persistent, bidirectional, full-duplex communication channels over a single TCP connection. Standardized by the IETF as RFC 6455 in December 2011, WebSocket enables real-time data exchange between a client and server with minimal overhead, replacing older techniques like HTTP polling and Comet that were not designed for interactive applications 1.
Before WebSocket, building real-time web applications required workarounds using HTTP, a protocol designed for stateless request-response communication. Techniques like AJAX polling (popularized by Google in the mid-2000s for products like Gmail and Google Maps) and Comet (long polling and HTTP streaming) attempted to simulate real-time behavior, but suffered from high latency, excessive overhead from repeated HTTP headers, unreliable message ordering, and poor scalability under concurrent connections 2.
In 2008, developers Michael Carter and Ian Hickson recognized these limitations and collaborated through IRC and W3C mailing lists to design a new standard for real-time web communication. The name "WebSocket" was coined during this process, and the protocol was incorporated into the HTML5 specification 2.
The WebSocket protocol consists of two phases: an opening handshake and bidirectional data transfer 1.
A WebSocket connection begins as a standard HTTP request with an Upgrade header. The client sends an HTTP GET request including Connection: Upgrade, Upgrade: websocket, a randomly generated Sec-WebSocket-Key, and the protocol version. If the server supports WebSocket, it responds with HTTP 101 Switching Protocols and a Sec-WebSocket-Accept header derived from the client's key. After this handshake, the connection upgrades from HTTP to the WebSocket protocol 1.
Once established, the connection remains open and either party can send data independently at any time. Messages are transmitted as lightweight frames with minimal overhead — significantly smaller than HTTP request/response headers. The protocol supports both text (UTF-8) and binary data frames, as well as control frames for ping/pong heartbeats and connection closure 1.
The fundamental difference between WebSocket and HTTP lies in their communication models 3:
| Criteria | WebSocket | HTTP |
|---|---|---|
| Connection | Persistent, long-lived | Transient (request-response) |
| Communication | Full-duplex, bidirectional | Half-duplex, unidirectional |
| State | Stateful | Stateless |
| Overhead | Minimal per message after handshake | Headers on every request/response |
| Latency | Low (immediate data transfer) | Higher (connection setup, headers) |
HTTP remains the right choice for standard web browsing, REST APIs, and cacheable content. WebSocket excels when applications require low-latency, bidirectional, real-time communication 3.
WebSocket is widely used for applications that require instant, continuous communication 2:
WebSocket Secure (WSS) provides encrypted communication by layering TLS/SSL over the WebSocket protocol, analogous to HTTPS for HTTP. WSS connections use the wss:// URI scheme and typically operate over port 443. The initial handshake occurs over HTTPS, inheriting TLS certificate-based server authentication and data integrity guarantees 3.
The protocol also includes client-to-server masking of data frames to prevent cache poisoning attacks on intermediary proxies 1.
Since its standardization, WebSocket has become foundational to the real-time web. Google Chrome 4 shipped the first browser implementation in December 2009, with other browsers following over the next few years. Today, WebSocket is supported by all major browsers and platforms 2.
Popular libraries and frameworks have been built on top of the raw protocol, including Socket.IO (which adds automatic reconnection, multiplexing, and fallback to HTTP long polling) and numerous server-side implementations in every major programming language 2.
WebSocket is a communication protocol that provides persistent, bidirectional, full-duplex communication channels over a single TCP connection. Standardized by the IETF as RFC 6455 in December 2011, WebSocket enables real-time data exchange between a client and server with minimal overhead, replacing older techniques like HTTP polling and Comet that were not designed for interactive applications 1.
AJAX popularized for dynamic web apps
2005
Comet model coined
2006
WebSocket concept proposed
2008
First browser support
2009
RFC 6455 published
2011
Before WebSocket, building real-time web applications required workarounds using HTTP, a protocol designed for stateless request-response communication. Techniques like AJAX polling (popularized by Google in the mid-2000s for products like Gmail and Google Maps) and Comet (long polling and HTTP streaming) attempted to simulate real-time behavior, but suffered from high latency, excessive overhead from repeated HTTP headers, unreliable message ordering, and poor scalability under concurrent connections 2.
In 2008, developers Michael Carter and Ian Hickson recognized these limitations and collaborated through IRC and W3C mailing lists to design a new standard for real-time web communication. The name "WebSocket" was coined during this process, and the protocol was incorporated into the HTML5 specification 2.
The WebSocket protocol consists of two phases: an opening handshake and bidirectional data transfer 1.
A WebSocket connection begins as a standard HTTP request with an Upgrade header. The client sends an HTTP GET request including Connection: Upgrade, Upgrade: websocket, a randomly generated Sec-WebSocket-Key, and the protocol version. If the server supports WebSocket, it responds with HTTP 101 Switching Protocols and a Sec-WebSocket-Accept header derived from the client's key. After this handshake, the connection upgrades from HTTP to the WebSocket protocol 1.
Once established, the connection remains open and either party can send data independently at any time. Messages are transmitted as lightweight frames with minimal overhead — significantly smaller than HTTP request/response headers. The protocol supports both text (UTF-8) and binary data frames, as well as control frames for ping/pong heartbeats and connection closure 1.
The fundamental difference between WebSocket and HTTP lies in their communication models 3:
| Criteria | WebSocket | HTTP |
|---|---|---|
| Connection | Persistent, long-lived | Transient (request-response) |
| Communication | Full-duplex, bidirectional | Half-duplex, unidirectional |
| State | Stateful | Stateless |
| Overhead | Minimal per message after handshake | Headers on every request/response |
| Latency | Low (immediate data transfer) | Higher (connection setup, headers) |
HTTP remains the right choice for standard web browsing, REST APIs, and cacheable content. WebSocket excels when applications require low-latency, bidirectional, real-time communication 3.
WebSocket is widely used for applications that require instant, continuous communication 2:
WebSocket Secure (WSS) provides encrypted communication by layering TLS/SSL over the WebSocket protocol, analogous to HTTPS for HTTP. WSS connections use the wss:// URI scheme and typically operate over port 443. The initial handshake occurs over HTTPS, inheriting TLS certificate-based server authentication and data integrity guarantees 3.
The protocol also includes client-to-server masking of data frames to prevent cache poisoning attacks on intermediary proxies 1.
Since its standardization, WebSocket has become foundational to the real-time web. Google Chrome 4 shipped the first browser implementation in December 2009, with other browsers following over the next few years. Today, WebSocket is supported by all major browsers and platforms 2.
Popular libraries and frameworks have been built on top of the raw protocol, including Socket.IO (which adds automatic reconnection, multiplexing, and fallback to HTTP long polling) and numerous server-side implementations in every major programming language 2.
