WebSocket Connection Flow: Mermaid Sequence Diagram

WebSocket Connection Flow sequence diagram

About Source

WebSocket is a full-duplex communication protocol (RFC 6455) that upgrades an HTTP connection into a persistent, bidirectional channel, enabling either the client or server to push messages at any time without polling.

Traditional HTTP is request/response: the client must initiate every exchange. WebSocket removes this constraint, making it the standard choice for real-time features like chat, live notifications, collaborative editing, and financial data feeds.

HTTP Upgrade Handshake: WebSocket begins as a standard HTTP/1.1 request. The client sends an Upgrade: websocket header along with Connection: Upgrade, a Sec-WebSocket-Key (a base64-encoded random value), and the protocol version. This reuses the existing TCP (and optionally TLS) connection — no new transport-layer handshake is needed.

101 Switching Protocols: The server accepts the upgrade by responding with HTTP 101 Switching Protocols, Upgrade: websocket, and a Sec-WebSocket-Accept value derived from the client's key via SHA-1. This handshake serves as a proof-of-intent, preventing non-WebSocket servers from accidentally accepting WebSocket connections.

Full-Duplex Messaging: Once upgraded, the connection is no longer HTTP. Framed WebSocket messages flow in both directions independently. Each frame has a 2-14 byte header containing an opcode (text, binary, ping, pong, close), payload length, and masking key (client-to-server frames must be masked per RFC to prevent cache poisoning by proxies).

Ping/Pong Keep-Alive: Either side can send a ping frame; the other must respond with a pong. This keeps the connection alive through NAT timeouts and detects broken connections.

Close Handshake: Either side initiates closure with a close frame containing an optional status code and reason. The other side echoes the close frame, and both sides close the TCP connection.

Compare with SSE for server-to-client-only streams that work over standard HTTP/2.

Frequently asked questions

WebSocket (RFC 6455) is a full-duplex communication protocol that upgrades an HTTP connection into a persistent, bidirectional channel. Once established, either the client or the server can push messages at any time without polling — making it the standard choice for real-time features like chat, live notifications, collaborative editing, and financial data feeds.

The client sends a standard HTTP/1.1 GET request with `Upgrade: websocket`, `Connection: Upgrade`, and a base64-encoded random `Sec-WebSocket-Key`. The server responds with `101 Switching Protocols` and a `Sec-WebSocket-Accept` value derived from the client's key via SHA-1. This proof-of-intent prevents non-WebSocket HTTP servers from accidentally accepting WebSocket connections.

After the upgrade, communication switches to the WebSocket framing protocol. Each message frame has a 2–14 byte header containing an opcode (text, binary, ping, pong, close), payload length, and a masking key. Client-to-server frames must be masked to prevent cache poisoning by HTTP proxies. Frames from both sides flow independently without waiting for a response.

WebSockets provide full-duplex communication — both client and server can send messages independently at any time. SSE is strictly server-to-client: the client opens one HTTP request and the server streams events, but the client cannot send messages over the same connection. SSE is simpler, works over HTTP/2, and is better suited for one-directional feeds like live updates or AI response streaming. WebSockets are necessary when the client also needs to push data.

mermaid

sequenceDiagram
    participant Client
    participant Server

    note">Note over Client,Server: TCP + TLS already established
    Client->&gt;Server: GET /chat HTTP/1.1\nUpgrade: websocket\nConnection: Upgrade\nSec-WebSocket-Key: dGhlIHNhbXBsZQ==\nSec-WebSocket-Version: 13

    Server-->&gt;Client: HTTP/1.1 101 Switching Protocols\nUpgrade: websocket\nConnection: Upgrade\nSec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

    note">Note over Client,Server: HTTP protocol replaced by WebSocket framing

    Server-->&gt;Client: Text frame: {"type":"connected","id":"abc"}
    Client->&gt;Server: Text frame: {"type":"message","text":"Hello"}
    Server-->&gt;Client: Text frame: {"type":"message","text":"Hello","from":"user1"}
    Server-->&gt;Client: Text frame: {"type":"message","text":"World","from":"user2"}

    note">Note over Client,Server: Keep-alive
    Client->&gt;Server: Ping frame
    Server-->&gt;Client: Pong frame

    note">Note over Client,Server: Close handshake
    Client->&gt;Server: Close frame (1000 Normal Closure)
    Server-->&gt;Client: Close frame (1000 Normal Closure)