WebSockets Explained

Table of Contents +

Picture this:

You’re chatting with your friend Alex on WhatsApp Web in your browser.
Alex types a message, and a second later it just pops up on your screen.
You didn’t refresh the page. You didn’t click anything. It just appeared on its own.

So how does that work? Your browser somehow knew a new message arrived without you asking for it. That’s the trick we’re going to unpack today, and the thing that makes it possible is called a WebSocket.

By the end, you’ll be able to explain how real-time apps work, and why plain old HTTP can’t do this on its own.

🎯 The Problem

To see why WebSockets exist, you first have to see what’s broken without them. Here’s the thing about normal web traffic:

The web mostly runs on HTTP, and HTTP works in a request-response style. (HTTP is the language browsers and servers use to talk.)
That means your browser asks for something, the server answers, and then the conversation is over.
The big catch is this: the server can’t speak first. It can only reply when you ask. It has no way to tap you on the shoulder and say “hey, new message.”

So imagine you’re waiting for a chat message with only HTTP. How would you ever find out a message came in? You’d have to keep asking. And that’s exactly what people used to do, with a trick called polling.

Polling means your browser keeps asking the server “anything new yet?” over and over, every couple of seconds.
Most of the time the answer is “nope, nothing.” So you made a whole request and got nothing useful back.
That’s a lot of wasted trips. Wasted network traffic, wasted server work, and you still find out a bit late.

See the problem? Every loop opens a fresh connection, asks, gets nothing, and closes. To get faster updates you’d poll more often, which just wastes even more. There has to be a better way, and there is.

🔌 What is a WebSocket

A WebSocket fixes the whole “server can’t speak first” problem. Here’s the simple definition:

A WebSocket is a persistent, two-way connection between your browser and the server that stays open. (Persistent just means it stays open instead of closing after one reply.)
“Two-way” means both sides can send messages whenever they want. The fancy word for this is full-duplex, which just means traffic flows both directions at the same time, like a phone call.
So once the connection is open, the server can push a message to you the instant something happens, and you can send one back, with no need to ask first.

Think of the difference like this:

HTTP is like sending letters. You mail a question, you wait, a reply comes back, done. To ask again, you mail another letter.
A WebSocket is like keeping a phone call open. Nobody hangs up. Either person can just start talking the moment they have something to say.

That single open line is the heart of it. No re-asking, no closing, no waiting around.

🤝 How It Starts

Here’s a neat part that surprises people: a WebSocket doesn’t start as something totally separate. It actually begins life as a normal HTTP request.

Your browser sends a regular HTTP request, but with a special header that says “hey, I’d like to upgrade this to a WebSocket.” (A header is just a bit of extra info attached to the request.)
If the server supports it, it replies “sure, upgrading.” This little agreement is called the WebSocket handshake.
After that, the connection switches over. It stops behaving like request-response and stays open as a two-way WebSocket.

So the flow is: start as HTTP, do the upgrade handshake, then keep the line open for as long as both sides want.

It rides on one TCP connection

Inside, a WebSocket runs over a single TCP connection that stays open the whole time. TCP is the reliable connection layer that makes sure data arrives in order and nothing gets lost. So you set up that one connection once, and then reuse it for every message instead of opening a new one each time.

⚖️ HTTP Polling vs WebSockets

Now let’s put the two approaches side by side so the trade-offs are clear.

Aspect	HTTP Polling	WebSockets
Connection	Opens and closes for every check	One connection stays open
Direction	One-way: client must always ask first	Two-way: either side can send anytime
Latency	Higher: you find out on the next poll	Lower: server pushes the instant it happens
Overhead	High: many wasted requests and headers	Low: connect once, then small messages
Best for	Rare or slow updates, simple apps	Constant real-time updates

The short version: polling is simple but wasteful, and WebSockets are leaner when updates come often and need to feel instant.

🧩 Where WebSockets Are Used

Once you get the idea, you start spotting WebSockets everywhere. Anytime something on a screen updates live without you refreshing, there’s a good chance a WebSocket is behind it.

Chat apps. WhatsApp Web, Slack, and Discord all push new messages to you the moment they arrive.
Live notifications. That little bell that lights up the second someone likes your post.
Multiplayer games. Every player’s move has to reach everyone else right away, so the game stays in sync.
Live dashboards. Things like server monitoring or analytics screens that update numbers in real time.
Collaborative editing. Google Docs, where you see your teammate’s cursor and edits as they type.
Stock tickers. Trading apps where prices flicker and change every second.

Notice the common thread: updates that need to feel instant and can come at any moment. That’s the sweet spot for WebSockets.

📈 Things to Know at Scale

WebSockets sound great, and they are, but keeping all those connections open isn’t free. When you’re serving lots of users, a few things start to matter a lot.

Each open connection uses server memory. One stays-open line per user means a server holding a million chats is juggling a million live connections at once.
Because the connections stay open, you need many connection servers and a way to spread users across them. One machine can only hold so many.
WebSockets are stateful, which means the server remembers who’s connected on which line. That’s different from plain HTTP, where each request stands alone and the server can forget you right after.
Since Alex might be connected to one server and you to another, you need a way to route a message from Alex’s server to yours. Big systems use a message broker or a pub/sub layer for this. (Pub/sub is just a system where one place publishes a message and everyone subscribed to it gets a copy.)

So the cost isn’t sending messages, it’s holding millions of doors open at the same time and routing between them. That’s the real engineering challenge.

⚠️ Common Mistakes and Misconceptions

A few ideas trip people up early on. Let’s clear them out:

“Use WebSockets for everything.” No. If your page just loads data once or updates rarely, plain HTTP is simpler and cheaper. WebSockets shine only when you need constant, instant, two-way updates.
“Polling is fine for real-time.” It can sort of fake it, but you’re always a little late and burning lots of wasted requests. For true real-time, server push wins.
“WebSockets are free to keep open.” They’re not. Every open connection holds server memory and resources, even when nobody’s sending anything. At scale that adds up fast.
“They’re totally separate from HTTP.” Actually they start as an HTTP request that upgrades. They reuse that doorway and then keep it open.

🛠️ Design Challenge

Try this one yourself to test the idea.

You’re building a live sports score app. Thousands of fans want the score to update the instant a goal is scored. Think through:

Would you use polling or WebSockets here, and why?
If a goal happens on one server but fans are spread across ten servers, how would you get the update to everyone?
What happens to all those open connections when a match ends and everyone leaves at once?

There’s no single right answer. The goal is to reason about real-time delivery and the cost of holding many connections open, exactly how you’d think in an interview.

🧩 What You’ve Learned

You can now explain how real-time apps actually talk. Here’s what you’ve picked up.

✅ Plain HTTP is request-response, so the server can’t push to you on its own.
✅ Polling fakes real-time by asking over and over, but it’s wasteful and a little late.
✅ A WebSocket is a persistent, two-way connection that stays open so either side can send anytime.
✅ It starts as an HTTP request that upgrades via a handshake, then keeps one TCP connection open.
✅ WebSockets power chat, live notifications, games, dashboards, collaborative editing, and stock tickers.
✅ At scale, open connections cost memory and are stateful, so you need many servers and a way to route messages.

Check Your Knowledge

Test what you learned. Pick an answer for each question, then click Check.

🚀 What’s Next?

You now understand the connection that powers real-time apps. Next, put it to work and see what sits underneath it.

Design a Chat Application shows how WebSockets fit into a full real-time system, from messages to delivery.
TCP vs UDP goes one layer down to the connections that everything, including WebSockets, is built on.

Previous gRPC Basics Next Long Polling & Server-Sent Events

Share & Connect

Share on LinkedIn