PHASE 1 — Topic 2: WebSockets Explained in Simple Words

In the last post, we saw why plain HTTP is not good enough for real-time apps. Now let's understand the technology that actually solves this problem: WebSockets.

What Is a WebSocket?

A WebSocket is a communication protocol that creates one single connection between the browser and the server, and keeps that connection open for as long as needed. Once this connection is open, both the client and the server can send messages to each other at any time, without asking permission first.

Think of the difference like this:

• HTTP is like sending letters back and forth. You send a letter, wait for a reply, and then the conversation pauses until you send another letter.
• WebSocket is like being on a phone call. Once the call connects, both people can speak whenever they want, without hanging up and redialing every time.

Full-Duplex Communication

The most important word to understand here is full-duplex. It means data can travel in both directions at the same time, independently.

• The client can send a message while the server is also sending one, at the exact same moment.
• Neither side has to wait for the other to finish before sending something.

This is very different from HTTP, where only the client is allowed to start a conversation. With WebSockets, the server can push data to the client whenever it wants, without the client asking for it.

How a WebSocket Connection Starts: The Handshake

A WebSocket connection does not begin as something completely new. It actually starts as a normal HTTP request. This is called the handshake.

Here is what happens step by step:

1. The client sends a normal-looking HTTP request to the server, but with a special header: Upgrade: websocket
2. The client also sends a Sec-WebSocket-Key, which is a random value used to confirm the server understands the WebSocket protocol
3. If the server supports WebSockets, it replies with a special response: 101 Switching Protocols
4. Once this response is received, the connection is officially "upgraded" from HTTP to WebSocket
5. The same underlying TCP connection stays open, but now it follows WebSocket rules instead of HTTP rules

After this handshake, no more HTTP requests are needed for the rest of the conversation. The connection simply stays open.

Why Does WebSocket Start as HTTP?

This might feel like an odd design choice, so here is the reason: firewalls, proxies, and corporate networks are built around HTTP traffic on ports 80 and 443. If WebSocket used a completely different, unfamiliar connection method, it would get blocked by a lot of networks.

By starting the connection as a normal-looking HTTP request, WebSocket traffic is able to pass through the same infrastructure that already supports the web, and then quietly switches over to its own lightweight protocol.

Messages Are Sent as Frames

Once the connection is open, data is not sent using full HTTP requests anymore. Instead, it is sent using small units called frames.

Frames are important because:

• They carry a very small header, often just a few bytes, compared to full HTTP headers which can be hundreds of bytes
• They can carry text data (like JSON) or binary data (like images or files)
• Multiple frames can combine to form one complete message

This is one of the biggest reasons WebSockets are so efficient. You are no longer repeating heavy HTTP headers every single time you want to send a small piece of data.

Keeping the Connection Alive

Since a WebSocket connection can stay open for a long time, both sides need a way to check if the other side is still there. This is done using small control messages, often called ping and pong.

• The server (or client) sends a small "ping" frame
• The other side replies with a "pong" frame
• If no pong comes back within a certain time, the connection is treated as dead, and it gets closed

This heartbeat mechanism helps detect broken connections early, instead of waiting for something to fail unexpectedly.

What WebSocket Solves From Our Previous Problems

Going back to the problems we discussed with HTTP:

Problem with HTTP	How WebSocket Solves It
Server cannot talk first	Server can send data anytime after the connection is open
Polling wastes resources	No repeated requests are needed at all
Delay is unavoidable	Data is pushed instantly, the moment it is available
Every request carries heavy headers	Frames carry minimal overhead after the handshake

Is WebSocket the Final Answer?

WebSocket solves the core real-time problem very well, but using raw WebSockets directly in a real project comes with its own challenges:

• If the connection drops, you have to manually write logic to reconnect
• If WebSocket is blocked by a network or firewall, there is no automatic fallback
• There is no built-in way to group users into rooms or separate parts of your app
• You have to build your own system for organizing different types of messages

This is exactly where Socket.IO comes in. It is built on top of WebSockets, but it adds all these missing pieces so you do not have to build them yourself.

Summary

• A WebSocket is a full-duplex, persistent connection between client and server
• It starts as a normal HTTP request, then upgrades to the WebSocket protocol using a handshake
• Once connected, data moves in small, lightweight frames instead of full HTTP requests
• Ping/pong messages keep the connection alive and detect dead connections
• WebSocket solves HTTP's real-time problems, but still leaves gaps like reconnection handling and message organization, which Socket.IO fills

In the next post, we will look at what Socket.IO actually is, and why it is used instead of plain WebSockets.