Learn WebSocket - The WebSocket Protocol: Concepts & Standard

#Introduction

After seeing the evolution of the real-time web in episode 1, it is time to dissect the WebSocket protocol itself. In this episode you will understand the standard that underpins every implementation: RFC 6455.

WebSocket is a communication protocol that provides full-duplex — both sides can send data simultaneously over a single persistent TCP connection. Unlike HTTP, where every message carries full headers, WebSocket sends data directly after the handshake with very minimal overhead.

#The RFC 6455 Standard and Basic Concepts

#One Protocol, Many Implementations

RFC 6455 was ratified in 2011 and defines the WebSocket protocol completely: handshake, framing, masking, control frames, and closing procedures. Because it is a standard, all implementations — ws in Node.js, gorilla/websocket in Go, websockets in Python — can interoperate.

The most prominent characteristics of this protocol:

• Full-duplex: the server and client send at any time, not alternately.
• Single TCP connection: no new connection needed per message.
• Small overhead: after the handshake, each frame has only a header of a few bytes.
• Two data types: text and binary, controlled via the opcode inside the frame.

npx wscat -c ws://echo.websocket.events

The command npx wscat -c ws://echo.websocket.events connects you to a public echo server. Type anything and the server will mirror the same message back — the fastest way to feel full-duplex without writing code.

#The ws:// and wss:// Schemes

Just as HTTP has http:// and https://, WebSocket has two schemes:

• ws:// — unencrypted, used in development or trusted networks.
• wss:// — WebSocket over TLS, mandatory in production.

ws://host:port/path
wss://host:port/path

The ws://host:port/path format above shows that the port and path are optional — just like HTTP URLs, including the query string for carrying parameters.

#WebSocket vs Other Alternatives

#WebSocket vs HTTP Polling

Polling (episode 1) keeps doing repeated request-response with full headers every time. WebSocket sends a handshake once, then talks directly with lightweight frames. For frequent updates, WebSocket wins hands down; for rare, one-shot requests, HTTP polling is actually simpler.

#WebSocket vs Server-Sent Events

SSE is a one-way long-lived HTTP connection with automatic reconnection. WebSocket is two-way and supports binary. The choice is simple:

• SSE for notifications and live feeds that only need the server-to-client direction.
• WebSocket for chat, games, and collaboration that need two-way traffic.

#WebSocket vs HTTP/2 Server Push

HTTP/2 Server Push lets the server send resources before they are requested, but it is designed for asset caching, not for ongoing two-way communication. WebSocket remains the primary choice for interactive real-time messaging.

#WebSocket vs HTTP/3 (QUIC)

HTTP/3 is built on QUIC, which is faster than TCP for multiplexing. However, HTTP/3 is still request-response; for pure bidirectional streams, a future technology called WebTransport is more relevant — we will discuss it in a later episode.

#When to Use WebSocket

#Suitable Use Cases

WebSocket excels in scenarios demanding continuous data exchange:

• Chat and instant messaging.
• Real-time notifications and live dashboards.
• Document collaboration like Google Docs.
• Multiplayer games and trading platforms.
• IoT device communication and location tracking.
• Video conference signaling.

#When Not to Use WebSocket

WebSocket is not the answer to everything. Avoid it when:

• Updates are rare — polling or SSE is more economical.
• Only one direction is needed — SSE is simpler.
• Each request needs its own state — stateless REST is a better fit.
• Compatibility with legacy proxies that do not support upgrades is required.

#WebSocket Connection Architecture

#Two Main Phases

Every WebSocket connection goes through two major phases:

1. Handshake: an HTTP request requesting an upgrade, answered with status 101.
2. Data transfer: the exchange of text or binary frames until one side closes.

We will dissect the handshake phase in detail in the next episode. For now, the key thing to understand: this phase happens only once, and after it the connection "transforms" from HTTP into WebSocket.

#Three Communication Scenarios

An established connection can be used in several patterns:

• Unicast: a message from the server to one specific client.
• Broadcast: the server sends to all clients.
• Relay: client A sends a message that the server forwards to client B.

These patterns are the foundation of applications like chat. We will practice implementing them from episode 5 onward and in depth in a later episode.

#Closing

Episode 2 gives you a conceptual map of the WebSocket protocol: the RFC 6455 standard, the ws and wss schemes, and a comparison with polling, SSE, and HTTP/2 Server Push. You also now know when to use WebSocket and when not to.

Key takeaways:

• WebSocket is full-duplex over a single persistent TCP connection.
• Its standard is RFC 6455, so all implementations can talk to each other.
• wss:// is mandatory for production because it uses TLS.
• WebSocket excels for frequent two-way updates; SSE for one-way.
• Use WebSocket with a reason, not because it is "cool".
• The unicast, broadcast, and relay architectures underpin every application.

In the next episode we will dissect the handshake and connection lifecycle — the Upgrade and Sec-WebSocket-Key headers, the Sec-WebSocket-Accept calculation, the four connection states, the frame structure, and the heartbeat ping and pong mechanism. This is the technical core that makes the protocol work.