WebSocket
What is a WebSocket?
WebSocket is a communication protocol that opens a persistent, two-way channel between a client, usually a web browser, and a server. Once the connection is established, either side can send data at any moment without waiting for the other to ask. This is what makes live chat, multiplayer games, collaborative editing, trading dashboards and instant notifications possible on the web.
It is standardised by the IETF (RFC 6455) and supported by every modern browser through a simple JavaScript API. A WebSocket URL starts with ws://, or wss:// when the connection is encrypted with TLS, which is the form you should always use in production.
How a WebSocket connection works
A WebSocket starts life as a regular HTTP request. The client asks the server to upgrade the connection, the server agrees, and from that point the same TCP connection stops speaking HTTP and carries lightweight WebSocket frames instead. The steps are:
- Handshake: the client sends an HTTP request with an
Upgrade: websocketheader. - Upgrade: the server answers with status 101 (Switching Protocols), and the connection stays open.
- Messaging: both sides exchange text or binary frames in either direction, with very little overhead per message.
- Closing: either side sends a close frame, and the connection ends cleanly.
A minimal client looks like this:
const socket = new WebSocket('wss://example.com/live');
socket.addEventListener('open', () => socket.send('hello'));
socket.addEventListener('message', (event) => console.log(event.data));WebSocket versus HTTP and other techniques
Classic HTTP is request and response: the client asks, the server answers, and the exchange ends. To fake real time, developers used polling, where the browser asks repeatedly for news. That wastes requests and adds delay. Other options exist, and the right one depends on the direction and frequency of the data.
- Polling and long polling: simple to build, but heavy on the server and not truly instant.
- Server-Sent Events (SSE): a one-way stream from server to browser over HTTP. Ideal for notifications and live feeds where the client rarely needs to send data back.
- WebSocket: full duplex, low latency, best when both sides talk frequently, as in chat or collaboration.
- Webhooks: server-to-server callbacks triggered by an event. They are not a live connection to a browser, so they solve a different problem.
Typical use cases
- Live chat and customer support widgets.
- Collaborative tools where several users edit the same document.
- Live dashboards, price tickers and monitoring screens.
- Multiplayer games and shared whiteboards.
- Real-time notifications and presence indicators.
If data changes rarely, or the user only needs fresh content on page load, a standard REST API is simpler and cheaper to run. WebSocket earns its place when latency and two-way flow matter.
Challenges and best practices
A persistent connection brings constraints that stateless requests do not have.
- Scaling: each open connection uses server memory. Spreading clients across servers needs load balancing with sticky sessions or a shared message broker.
- Security: always use
wss://, authenticate during the handshake, validate every incoming message and check the origin to prevent cross-site hijacking. - Abuse control: apply rate limiting per connection so one client cannot flood the server.
- Reliability: connections drop on mobile networks. Add automatic reconnection with backoff, and heartbeat messages to detect dead links.
- Fallbacks: libraries such as Socket.IO add reconnection and fallbacks, and managed services like Supabase Realtime or Firebase handle much of the infrastructure for you.
WebSocket at BeBranded
At BeBranded, we reach for WebSocket, or a managed real-time layer, only when a web application truly needs live, two-way data, such as collaborative interfaces or live dashboards. For everything else we prefer simpler patterns that are cheaper to run and easier to maintain. We design the back end and the front end together so real-time features stay reliable and secure. It is part of our web apps service.