WebSocket Fundamentals — Protocol, Lifecycle and Use Cases

HTTP is a request-response protocol — the client sends a request, the server responds, the connection closes (or is reused for the next request). For real-time applications that need the server to push data to the client without a client request (chat messages, live notifications, dashboards updating as data changes), HTTP polling (repeated requests) wastes bandwidth and adds latency. The WebSocket protocol solves this by upgrading an HTTP connection to a persistent, full-duplex (bidirectional) TCP channel — the server can push messages to the client at any time, and the client can send messages to the server simultaneously.

WebSocket vs HTTP vs SSE #

WebSocket Connection Lifecycle #

1. CONNECT — Client initiates HTTP upgrade request
   Client → Server: GET /ws HTTP/1.1
                    Upgrade: websocket
                    Connection: Upgrade
                    Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==

2. HANDSHAKE — Server accepts and upgrades
   Server → Client: HTTP/1.1 101 Switching Protocols
                    Upgrade: websocket
                    Connection: Upgrade
                    Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

3. COMMUNICATE — Full-duplex bidirectional messages
   Client ← → Server: text / binary / ping / pong frames

4. CLOSE — Either side can initiate close
   One side sends: Close frame (opcode 0x8, optional status code + reason)
   Other side responds: Close frame
   TCP connection closes

Common close status codes:
  1000 — Normal closure (intentional)
  1001 — Going away (server shutdown, page navigation)
  1006 — Abnormal closure (connection lost without close frame)
  1008 — Policy violation
  1011 — Server error

Use Case Decision Guide #

Common Mistakes #

Mistake 1 — Using WebSockets when SSE or polling is sufficient #

❌ Wrong — using WebSocket for a one-way notification feed:

# Complex bidirectional WebSocket just to push notifications to browser
# SSE is simpler, works through all proxies, auto-reconnects

✅ Consider — SSE for server-to-client only streaming (covered in Lesson 5).

Mistake 2 — Not handling connection close gracefully #

❌ Wrong — ignoring WebSocketDisconnect:

@app.websocket("/ws")
async def ws(websocket: WebSocket):
    await websocket.accept()
    while True:
        msg = await websocket.receive_text()
        # If client disconnects: raises WebSocketDisconnect — uncaught exception!

✅ Correct — always catch WebSocketDisconnect in the message loop.

Mistake 3 — Storing all connections in a global dict without cleanup #

❌ Wrong — memory leak from disconnected clients staying in the dict:

connections[user_id] = websocket
# Never removed on disconnect → dict grows unbounded

✅ Correct — remove from storage in the disconnect handler or finally block.

Quick Reference #