In the world of web applications, where interactivity and instant data exchange have become the norm, the WebSocket protocol has emerged as a key component of real‑time architecture. In this article we will examine WebSocket history, from the earliest concepts, through standardization, to modern use cases. This will help you understand how WebSocket works, its advantages, and when it makes sense to choose it over traditional HTTP.
Origins: from Comet to WebSocket
In the mid‑2000s developers were looking for a way to keep an open connection between the browser and the server. Techniques such as long‑polling or Comet allowed simulation of bidirectional communication, but required repeated HTTP connections, which generated significant load and latency.
In 2008 the IETF working group IETF WebSocket Working Group was formed with the goal of creating a lightweight, full‑featured application‑layer protocol running over TCP. In 2011 RFC 6455 was published – the official WebSocket standard.
The basic idea was simple: after the initial handshake, which uses the existing HTTP mechanism, the connection switches to a binary mode, enabling the exchange of small data frames in both directions without additional HTTP headers.
How does WebSocket work under the hood?
Communication starts with a handshake – the client sends a GET /chat HTTP/1.1 request with the header Upgrade: websocket and Sec-WebSocket-Key. The server replies with a 101 Switching Protocols status and returns Sec-WebSocket-Accept, calculated as the SHA‑1 of the key plus a constant string, then Base64‑encoded. After a successful handshake the connection is “upgraded” to WebSocket.
In practice data is exchanged as frames. Each frame consists of several bytes: control flags, opcode (text, binary, ping, pong, close), payload length, and the payload itself. This makes sending small messages (e.g., a chat message) extremely efficient – there is no need to repeat full HTTP headers with every packet.
The connection remains open until closed by one of the parties, allowing immediate notifications (e.g., price updates, game status) without additional delays.
Differences between WebSocket and HTTP
- Communication model: HTTP is a request‑response protocol, WebSocket provides full duplex.
- Overhead: every HTTP request carries a full set of headers, WebSocket needs them only during the handshake, and thereafter data is exchanged in lightweight frames.
- Connection state: HTTP is stateless, WebSocket maintains a connection state, simplifying session implementation.
In practice this means that applications requiring frequent, small updates (chat, games, monitoring) use WebSocket to avoid the cost of repeatedly opening connections.
WebSocket vs Server‑Sent Events
Server‑Sent Events (SSE) are another push technology, based solely on streaming data from server to client. SSE runs over a regular HTTP connection and is simpler to implement, but it is limited to one‑way communication.
WebSocket provides bidirectionality, making it more versatile. However, SSE includes built‑in automatic reconnection and reconnection handling, which can be an advantage in some scenarios, such as simple notifications.
“Choosing between WebSocket and SSE is not a matter of ‘better/ worse’, but of matching the tool to the specific communication problem.”
WebSocket use cases in real‑time applications
The most recognizable use cases are:
- Chat platforms and messengers (e.g., Slack, Discord) – instant message exchange.
- Browser games – real‑time game state synchronization.
- Monitoring dashboards – charts and metrics updated on the fly.
- FinTech: stock quotes, currency rate changes.
In each of these examples low latency and the ability to maintain a persistent connection with minimal overhead are critical.
WebSocket connection security
Just like HTTP, WebSocket can use TLS (referred to as wss://). This provides data encryption and protection against eavesdropping. It is important, however, for the server to verify the Origin header – this protects against Cross‑Site WebSocket Hijacking attacks.
In practice you should also apply authentication mechanisms (JWT tokens, sessions) already during the handshake to reject unauthorized connections. Some libraries allow adding a firewall layer, limiting the number of concurrent connections per IP.
Practical example: a simple WebSocket server and client
Below you will find minimal Node.js code using the ws library. The server listens on port 8080 and echoes every received message with the prefix Echo:.
const WebSocket = require('ws');
const wss = new WebSocket.Server({ port: 8080 });
wss.on('connection', ws => {
console.log('Nowe połączenie');
ws.on('message', msg => {
console.log('Otrzymano:', msg);
ws.send(`Echo: ${msg}`);
});
ws.on('close', () => console.log('Połączenie zamknięte'));
});
A browser client can connect as follows:
const socket = new WebSocket('ws://localhost:8080');
socket.addEventListener('open', () => socket.send('Hello server!'));
socket.addEventListener('message', e => console.log('Serwer:', e.data));
This example shows how little code is needed to achieve real‑time bidirectional communication.
Checklist: what to verify before deploying WebSocket
- Protocol choice:
wss://for production to provide TLS. - Authorization mechanism during the handshake (token, cookie).
- Limit of concurrent connections and scaling strategy (e.g., Node cluster, load balancer handling upgrades).
- Monitoring: number of open connections, ping/pong keep‑alive, timeouts.
- Fallback: does the application have an alternative (SSE or long‑polling) for browsers that do not support WebSocket?
Common pitfalls and trade‑offs
One of the most frequent issues is improper server resource management – each open connection consumes memory and a network socket. Without proper limiting, resource exhaustion (so‑called socket exhaustion) can occur.
Another trap is the lack of ping/pong handling. Without keep‑alive, some load balancers close connections after a few minutes, leading to unexpected disconnects.
It is also important to remember the protocol version – not all browsers support the latest extensions (e.g., permessage‑deflate). Therefore, compatibility testing is essential.
In summary, WebSocket history is a story about the need for efficient, bidirectional communication on the web. Understanding how WebSocket works, its differences from HTTP and alternatives like SSE, as well as awareness of risks and best practices, enables building solid, scalable real‑time applications. If you want to implement WebSocket in your project or need an architecture that meets the demands of modern interfaces, contact the Coderia.it team – we’ll help turn your idea into an efficient solution.
