The WebSocket Protocol, standardized as RFC 6455 in December 2011 by Ian Fette and Alexey Melnikov, defines a way for a web client and a server to hold a persistent, two-way conversation over a single TCP connection. Its abstract states the goal plainly: the protocol “enables two-way communication between a client running untrusted code in a controlled environment to a remote host that has opted-in to communications from that code.” In practice that controlled environment is the web browser, and the opted-in host is a server that has agreed to speak WebSocket.
Before WebSocket, browsers approximated real-time updates with awkward techniques such as repeated polling or long-held HTTP requests, each carrying the overhead of full HTTP headers and an inherent request-response shape. WebSocket was designed expressly to replace these workarounds with a genuine bidirectional channel, so that either side can send a message at any moment without waiting to be asked. This makes it the natural transport for chat, live dashboards, multiplayer games, collaborative editing, and trading systems.
A WebSocket connection begins life as an ordinary HTTP request. The client sends an HTTP GET carrying an Upgrade header and a randomly generated key; if the server agrees, it responds with a 101 Switching Protocols status and a value derived from that key, completing the handshake. After this upgrade, the same TCP connection stops speaking HTTP and starts exchanging WebSocket frames. Reusing the HTTP handshake lets the protocol traverse the existing web infrastructure of ports 80 and 443, proxies, and firewalls.
Once established, data travels in lightweight frames rather than as a sequence of separate HTTP messages. Frames carry either text (UTF-8) or binary payloads, along with control frames for closing the connection and for ping and pong keepalives. The framing overhead is small compared with HTTP headers, and because the connection stays open, there is no per-message handshake cost. Frames sent from client to server are masked with a key to defend intermediary infrastructure against certain cache-poisoning attacks, a detail the RFC specifies in careful security-minded language.
WebSocket sits alongside Server-Sent Events as one of the two standard answers to the push problem: SSE offers a simpler one-way server-to-client stream over plain HTTP, while WebSocket offers full duplex at the cost of a distinct protocol. Supported by every major browser and a deep ecosystem of server libraries, RFC 6455 became the foundation for real-time interactivity on the web and a building block for many event-driven systems.