You're in a chat window. A message appears. You didn't refresh. You didn't click anything. The server just... sent you something.
Or you're watching a live stock dashboard. A number changes. Then another. The page is updating on its own.
How?
To understand why this is interesting, you need to understand what HTTP normally looks like.
The Problem With Normal HTTP
HTTP is a request-response protocol. The browser asks for something, the server responds, and that exchange is done.
Browser → Request → Server
Browser ← Response ← Server
This works fine for loading a webpage, fetching an image, submitting a form. The browser knows what it wants, it asks, it gets an answer.
But what if the server has something new to tell the browser five seconds from now? There's no open request waiting for that information. The browser already got its response and moved on.
The obvious workaround is polling: the browser just keeps asking.
Browser → "Anything new?"
Server → "No."
Browser → "Anything new?"
Server → "No."
Browser → "Anything new?"
Server → "Yes, here it is."
This works, but it's wasteful. You're making network requests constantly, most of which come back empty. And even then, there's a delay between when the server has something and when the browser happens to ask next.
Long polling and Server-Sent Events can handle server-initiated updates in different ways, but they don't provide the same general-purpose, two-way communication model as WebSockets. For use cases that need both sides to send messages freely and independently, neither fully fits.
WebSockets solve this differently.
The Connection Starts as HTTP
A WebSocket connection doesn't appear from nowhere. It starts as a normal HTTP request. The browser connects to the server and then asks to switch protocols.
GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
This is the WebSocket handshake. The browser is essentially saying: "I want to upgrade this connection from HTTP to the WebSocket protocol."
If the server supports it, it agrees:
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Status code 101 means "Switching Protocols." After this point, HTTP is done. The same underlying TCP connection is now being used for WebSocket communication, which operates under entirely different rules.
Now the Model Changes
In normal HTTP, once the server responds, the exchange is over. The browser has to initiate every interaction.
With WebSockets, the connection stays open. And both sides can send messages through it independently.
Browser
↕
WebSocket connection (persistent)
↕
Server
The conversation can look like this:
Browser → "Hello"
Server → "Hi"
Server → "New message from Bob"
Browser → "Got it"
Server → "Stock price updated"
Server → "Another message from Bob"
Neither side has to wait for the other to ask before sending something. This is called full-duplex communication: both sides can send data at any time over the same connection.
This is the actual difference. Not magic. Not a different network. Just a different communication model.
What's Keeping the Connection Open?
WebSockets run over TCP. The stack looks like this:
WebSocket protocol
↓
TCP
↓
IP
↓
Network
TCP provides a reliable, ordered byte stream between two endpoints, over which data can flow in both directions while the connection remains open. WebSockets sit on top of that and define how to structure messages over the stream.
TCP by itself just gives you bytes. WebSocket adds message boundaries. Data is exchanged in frames, where each frame carries information about the type of data it contains, whether it's part of a larger message, and how much payload is present. This is what lets both sides know where one message ends and the next begins, something TCP's raw byte stream doesn't tell you on its own.
What This Looks Like in Practice
Say Alice has a chat app open in her browser. The page loaded, and as part of that, her browser established a WebSocket connection to the server. That connection is just sitting there, open.
Bob types "Hey" and hits send.
- Bob's browser sends the message to the server over his WebSocket connection.
- The server sees that Alice is in the same chat.
- The server sends a WebSocket message through Alice's already-open connection.
- Alice's browser receives the frame.
- JavaScript reads the message and updates the UI. Alice's browser never had to ask "do I have any new messages?" The server already had a channel to reach her. When something arrived for her, it went through that channel immediately.
What WebSockets Don't Do
WebSockets don't make the network faster. There's still latency. There's still TCP, routers, congestion, and server processing time. A WebSocket message between London and New York still has to physically travel that distance.
What they change is the communication model. The server can send data to the browser without waiting for a new HTTP request. That's the entire benefit. It sounds simple because it is. The complexity is in everything the protocol had to solve to make that possible reliably.
And they're not always the right tool. If you need the browser to occasionally fetch some data on demand, plain HTTP is simpler and perfectly sufficient. WebSockets make sense when both sides genuinely need to communicate continuously and independently, like in a chat app, a live game, a collaborative editor, or a real-time dashboard.
When a message appears in your chat window without you doing anything, it feels like the server reached through the screen and updated your page.
In a way, it did. Your browser and the server had already agreed to keep a channel open between them. When the server had something to say, the channel was already there.
The page isn't repeatedly asking if anything changed. It stopped asking the moment the WebSocket connection was established. From that point on, the server can talk whenever it needs to.
Top comments (0)