Intro to WebSockets
The Persistent Conversation
In the early days of the web, the internet was a formal, polite place. Your browser would request a page, the server would deliver it, and they would promptly hang up on each other. This is the Request-Response cycle of HTTP—a model that works perfectly for reading news or buying a book, but falls apart when the digital world needs to move at the speed of thought.
Enter WebSockets: the technology that transformed the web from a series of static snapshots into a living, breathing, real-time experience.
The “Polling” Problem. Asking “Are We There Yet?”
Before WebSockets became a standard, developers had to “fake” real-time updates. The most common technique was Short Polling, where the browser would ping the server every few seconds to see if anything had changed.
Imagine sitting in a car and asking, “Are we there yet?” every five seconds. It’s exhausting for you (the client) and annoying for the driver (the server). In technical terms, this created massive overhead. Every single “Are we there yet?” required a full HTTP header—hundreds of bytes of metadata—just to receive a “No” in response.
Then came Long Polling, a slightly more sophisticated hack where the server would hold the request open until it actually had news to share. While more efficient, it still required re-establishing a connection every time data was finally delivered. The web was begging for a permanent “open line.”
The WebSocket Handshake. Upgrading the Conversation
The genius of the WebSocket protocol (defined as RFC 6455) is that it doesn’t reinvent the wheel; it upgrades it. A WebSocket connection begins as a standard HTTP request, ensuring it can pass through most firewalls and proxies without being blocked.
The process follows a specific dance:
The Request. The client sends an HTTP GET request with a special header:
Upgrade: websocket.The Agreement. If the server speaks WebSocket, it responds with a
101 Switching Protocolsstatus code.
The Transformation: At that moment, the “handshake” is complete. The HTTP protocol is discarded, and the underlying TCP connection is repurposed into a persistent, bi-directional tunnel.
𝐋𝐞𝐚𝐫𝐧 𝐭𝐨 𝐛𝐮𝐢𝐥𝐝 𝐆𝐢𝐭, 𝐃𝐨𝐜𝐤𝐞𝐫, 𝐑𝐞𝐝𝐢𝐬, 𝐇𝐓𝐓𝐏 𝐬𝐞𝐫𝐯𝐞𝐫𝐬, 𝐚𝐧𝐝 𝐜𝐨𝐦𝐩𝐢𝐥𝐞𝐫𝐬, 𝐟𝐫𝐨𝐦 𝐬𝐜𝐫𝐚𝐭𝐜𝐡. Get 40% OFF CodeCrafters: https://app.codecrafters.io/join?via=the-coding-gopher
Characteristics
Full-Duplex. Unlike HTTP, where only one side can “talk” at a time, WebSockets allow the client and server to send data simultaneously.
Minimal Framing. Once the connection is open, the metadata required to send a message drops from several hundred bytes to as little as 2 bytes. This is the difference between sending a formal letter in an envelope and sending a quick text message.
Stateful. The server knows exactly who you are without you having to send a session cookie or authentication token with every single packet of data. The “context” of the conversation is preserved.
When Real-Time is Non-Negotiable
WebSockets are the engine under the hood of the modern interactive web. If you see a “typing...” indicator in a chat app, or a stock price flickering red and green, you are likely looking at a WebSocket in action.
Primary Use Cases
Collaborative Tools. Platforms like Google Docs or Figma rely on WebSockets to sync cursor movements and keystrokes across thousands of miles in milliseconds.
Financial Ecosystems. High-frequency trading and crypto tickers require updates the instant a trade occurs. A delay of 200ms isn’t just a nuisance; it’s a financial loss.
Gaming. Multiplayer web games require instantaneous synchronization of player positions and actions to ensure the “game state” is identical for everyone.
Live Sports & Media. Score updates and live commentary that push to your screen the second a goal is scored, often beating the delay of a digital cable broadcast.
The Operational Trade-Offs
While WebSockets sound like the ultimate solution, they come with a “tax” on infrastructure. Because the connection stays open, it consumes server memory (RAM).
A traditional web server can handle a million “passing through” HTTP requests because it forgets about the user the moment the page is sent. However, maintaining a million active “phone calls” requires significant infrastructure. Developers must implement Heartbeats (Ping/Pong frames) to ensure the connection hasn’t died silently, and they must handle complex Load Balancing to ensure a user stays connected to the same server or that the servers can share the state.
Additionally, WebSockets don’t handle caching well. Browsers can’t “save” a WebSocket response the way they can a JPEG or an HTML file, making them unsuitable for static content.
The Future. WebSockets vs. HTTP/3 and WebTransport
As we move into 2026 and beyond, the landscape is shifting. While WebSockets remain the gold standard, newer technologies like WebTransport (built on top of HTTP/3 and QUIC) are beginning to emerge.
WebTransport offers even faster speeds by using UDP instead of TCP, avoiding “Head-of-Line Blocking”—a technical hiccup where one lost packet of data can delay all the packets behind it. However, for the vast majority of real-time needs, the WebSocket remains the most reliable, widely supported, and battle-tested tool in a developer’s kit.
Great! Thank u. Now waiting for the WebTransport (with QUIC+HTTP/3) article 🥹
been waiting on this one since forever!