WebSockets

Definition

Think about how traditional web communication works: your browser sends a request, waits for a response, gets it, and the connection closes. It’s like sending a text message - you send one, wait for a reply, and each message is a separate transaction. But what if you want to have a phone call instead, where both parties can speak at any time without hanging up between sentences? That’s what WebSockets enable.

WebSockets provide a persistent, two-way communication channel between a client and server. Instead of the constant back-and-forth of “request-response-close, request-response-close,” WebSockets establish a single connection that stays open. Either side can send a message at any time without waiting for the other. This makes them perfect for real-time applications where you need instant updates - chat apps, live sports scores, collaborative documents, stock tickers, multiplayer games.

Here’s how it works: the connection starts as a regular HTTP request that says “Hey, let’s upgrade to WebSockets.” If the server agrees, the connection transforms into a WebSocket connection and stays open. From that point on, messages can flow freely in both directions with minimal overhead. No more repeated handshakes, no more headers on every message - just pure, fast, real-time communication.

Example

Slack and Discord: When your coworker sends a message in Slack, it appears on your screen instantly. That’s WebSockets. The app maintains a persistent connection to Slack’s servers. When anyone in your workspace sends a message, the server pushes it to everyone’s open connections immediately - no need to refresh or poll for updates.

Google Docs Collaborative Editing: When multiple people edit the same document, everyone sees everyone else’s changes in real-time. Each keystroke is sent through a WebSocket connection and broadcast to all collaborators. Without WebSockets, you’d have to constantly refresh to see others’ changes.

Live Sports Scores: Apps like ESPN push score updates the instant they happen. When a touchdown is scored, the server sends a message through thousands of open WebSocket connections, and fans see the update within milliseconds. Traditional HTTP would require each app to constantly ask “any updates yet?” over and over.

Stock Trading Platforms: When you’re watching stock prices, those numbers are changing in real-time through WebSockets. The server pushes price updates as they happen rather than your browser having to ask for new prices every second. For traders, those milliseconds matter.

Multiplayer Online Games: When you’re playing a game with others, your position updates need to reach other players instantly. WebSockets enable this real-time synchronization - every player’s movements are broadcast to everyone else through persistent connections.

Analogy

Phone Call vs. Text Messages: Regular HTTP is like texting - you send a message, wait for a reply, and each exchange is independent. WebSockets are like a phone call - once connected, both parties can speak whenever they want, the line stays open, and there’s no delay between “transactions.” You don’t have to dial again for each sentence.

The Open Office Door: Imagine an office where normally you have to knock, wait to be acknowledged, deliver your message, and leave before coming back with another message. With WebSockets, it’s like having an open-door policy where you can walk in and out freely, and the person inside can call out to you anytime. Communication flows naturally in both directions without ceremony.

Walkie-Talkies vs. Memos: Traditional HTTP is like sending memos - you write one, send it, wait for a response memo, repeat. WebSockets are like walkie-talkies where you hold down the button and communicate back and forth in real-time. “Roger that, moving to position.” “Copy, we see you.” Instant, ongoing communication.

The Live Concert vs. YouTube Videos: Watching YouTube is like traditional HTTP - you request a video, it loads, done. Watching a live concert stream is like WebSockets - there’s a persistent connection, and the audio/video flows continuously to you in real-time. You don’t have to click “play” every few seconds; the content just keeps coming.

Diagram

sequenceDiagram
    participant C as Client
    participant S as Server

    Note over C,S: HTTP Upgrade Handshake
    C->>S: GET /chat HTTP/1.1
Upgrade: websocket
Connection: Upgrade
    S->>C: HTTP/1.1 101 Switching Protocols
Upgrade: websocket

    Note over C,S: Persistent Bidirectional Connection

    rect rgb(200, 230, 200)
        C->>S: Message: "Hello"
        S->>C: Message: "Hi there!"
        S->>C: Message: "New notification"
        C->>S: Message: "Got it"
        S->>C: Message: "User joined"
    end

    Note over C,S: Either side can close
    C->>S: Close Frame
    S->>C: Close Frame (ACK)

Code Example

// Client-side WebSocket
const ws = new WebSocket('wss://api.example.com/stream');

ws.onopen = () => {
  console.log('Connected');
  ws.send(JSON.stringify({ type: 'subscribe', channel: 'updates' }));
};

ws.onmessage = (event) => {
  const data = JSON.parse(event.data);
  console.log('Received:', data);
};

ws.onerror = (error) => console.error('WebSocket error:', error);
ws.onclose = () => console.log('Connection closed');

// Server-side (Node.js with ws library)
const WebSocket = require('ws');
const wss = new WebSocket.Server({ port: 8080 });

wss.on('connection', (ws) => {
  ws.on('message', (message) => {
    // Broadcast to all clients
    wss.clients.forEach((client) => {
      if (client.readyState === WebSocket.OPEN) {
        client.send(message);
      }
    });
  });
});

Security Notes

Standards & RFCs