Websockets
A WebSocket is a persistent, two-way connection between a browser and a server over a single TCP link, letting both sides send messages to each other instantly — ideal for chat, live updates, and other real-time features.
Part of the free JavaScript course at LearnCodingFast — hands-on lessons with examples you run in your browser, plus practice exercises and a quick quiz.
WebSocket examples require a server to connect to. For the best experience: Download Node.js to run a local WebSocket server, use your browser's Developer Console (Press F12) to test the WebSocket API, or try online WebSocket testing services.
Master real-time communication: persistent connections, messaging patterns, presence, rooms, and scalable architecture.
What You'll Learn
- WebSocket connection lifecycle
- Auto-reconnection with backoff
- Heartbeat & presence systems
- Room/channel management
- Reliable delivery with ACKs
- Scaling with Pub/Sub
What WebSockets Actually Are
HTTP is request → response only. WebSockets allow persistent, two-way communication : the server can push events anytime, and the client can send events anytime — no need for repeated HTTP requests.
HTTP (Traditional)
- Request → Response → Connection closed
- Client must poll for updates
- High latency, wasted bandwidth
- Server can't push data
WebSockets
- Persistent connection stays open
- Server pushes updates instantly
- Low latency, efficient
- Perfect for real-time apps
WebSockets Power:
Chat systems • Live notifications • Real-time games • Stock tickers • Collaborative editing • Multiplayer interactions • Typing indicators • Presence systems • Live dashboards
Basic WebSocket Connection
The browser's WebSocket API is simple but powerful. Always use wss:// for secure connections.
Real-Time Messaging with JSON
WebSockets only send text or binary. Best practice is to use structured JSON messages with type fields to handle different event types.
Robust Reconnection Logic
WebSocket connections will always drop eventually (network issues, server restarts, etc.). Production apps must auto-recover with exponential backoff.
Heartbeat (Ping/Pong) System
Every WebSocket system needs a heartbeat to detect dead connections. Clients ping periodically; if no pong returns, the connection is considered dead.
Presence System (Online/Offline Tracking)
Presence tracking shows who's online. It requires careful handling because disconnects aren't always clean (network loss, device sleep, etc.).
Rooms & Channels
Real apps need grouping: chat rooms, game lobbies, per-user channels. Rooms allow targeted messaging instead of broadcasting to everyone.
Reliable Delivery with ACKs
WebSockets do NOT guarantee message delivery. For critical messages, implement ACKs (acknowledgments) and retry logic.
WebSocket Security
WebSockets must be validated like any untrusted API. Always authenticate, validate messages, sanitize input, and rate limit.
Scaling with Pub/Sub Pattern
A single server can't handle millions of users. Real systems use Redis/NATS/Kafka as a message bus to broadcast across multiple servers.
📡 WebSocket Mastery Summary
- WebSockets provide persistent, bidirectional communication
- Use wss:// for secure connections
- Structure messages with JSON and type fields
- Implement auto-reconnection with exponential backoff
- Use heartbeats to detect dead connections
- Build presence systems for online/offline tracking
- Organize users into rooms/channels
- Use ACKs and retries for reliable delivery
- Validate, sanitize, and rate-limit all messages
- Scale with Pub/Sub (Redis) across multiple servers
Practice quiz
How does a WebSocket differ from traditional HTTP?
- It only works on localhost
- It is request-response only and closes after each reply
- It provides a persistent, two-way connection where the server can push data anytime
- It cannot send text
Answer: It provides a persistent, two-way connection where the server can push data anytime. Unlike HTTP's request-then-response model, a WebSocket keeps a persistent, bidirectional connection open so both sides can send messages anytime.
Which URL scheme is used for a secure WebSocket connection?
- wss://
- https://
- ftp://
- ws-secure://
Answer: wss://. wss:// is the secure WebSocket scheme (the WebSocket equivalent of https://).
Which event fires when a WebSocket connection is successfully established?
- 'message'
- 'close'
- 'error'
- 'open'
Answer: 'open'. The 'open' event fires when the connection is established; 'message' fires for incoming data.
Where do you read the data of an incoming WebSocket message?
- event.body
- event.data
- event.payload
- event.result
Answer: event.data. In the 'message' event handler, the received data is on event.data.
In the lesson, what does socket.readyState value 1 (OPEN) mean?
- The connection is open and ready to send
- The connection is closing
- The connection is connecting
- The connection is closed
Answer: The connection is open and ready to send. readyState 1 is OPEN (0=CONNECTING, 1=OPEN, 2=CLOSING, 3=CLOSED).
Why does the reconnection example use exponential backoff?
- To send messages faster
- To encrypt the data
- To space out reconnect attempts with increasing delays instead of hammering the server
- To avoid using JSON
Answer: To space out reconnect attempts with increasing delays instead of hammering the server. Exponential backoff increases the delay between reconnect attempts, avoiding overwhelming a struggling server.
What is the purpose of a heartbeat (ping/pong) system?
- To compress messages
- To detect dead connections when no pong returns within a timeout
- To authenticate users
- To create rooms
Answer: To detect dead connections when no pong returns within a timeout. Clients ping periodically; if no pong arrives within the timeout, the connection is treated as dead.
Do WebSockets guarantee message delivery on their own?
- Yes, always
- Only over wss://
- Only for JSON messages
- No — for critical messages you implement ACKs and retries
Answer: No — for critical messages you implement ACKs and retries. WebSockets do NOT guarantee delivery, so reliable messaging adds acknowledgments (ACKs) and retry logic.
What is the role of rooms/channels in the lesson?
- To encrypt messages
- To allow targeted messaging to a group instead of broadcasting to everyone
- To reconnect faster
- To store messages on disk
Answer: To allow targeted messaging to a group instead of broadcasting to everyone. Rooms group users so messages can be sent to a targeted set instead of every connected client.
How do you scale WebSockets across multiple servers in the lesson?
- Using a single giant server
- By disabling heartbeats
- Using a Pub/Sub message bus (like Redis) to broadcast across servers
- By switching to HTTP polling
Answer: Using a Pub/Sub message bus (like Redis) to broadcast across servers. A Pub/Sub pattern (Redis/NATS/Kafka) lets a message published on one server reach clients connected to all servers.
Continue this course
- Previous: Client-Side Security
- Next: Final Project