What is a WebSocket and when you really need one
Published on 2026-09-12 by frfrand
Una conexión que queda abierta en las dos direcciones. Cómo empieza siendo HTTP y deja de serlo, qué cuesta mantenerla, y por qué muchas veces alcanza con algo más simple.
HTTP has a property that defines almost all web development: the client asks and the server responds. The server never speaks first.
For a content website that is perfect. For a chat, a live dashboard or collaborative editing, it is a problem: the server knows something new and has no way to notify you.
WebSockets solve exactly that.
How it starts
The interesting thing is that it starts as a normal HTTP request, with a special header:
GET /ws HTTP/1.1 Upgrade: websocket Connection: Upgrade
If the server accepts, it responds with an uncommon code:
HTTP/1.1 101 Switching Protocols
From that moment on that TCP connection stops speaking HTTP. It stays open, and both sides can send messages whenever they want, without asking permission.
That design (starting as HTTP and then switching) is not a whim: it is what allows it to work through proxies and firewalls that only expect web traffic. It uses the same ports 80 and 443.
What it costs
One open connection per client. One thousand connected users are one thousand live connections, each occupying memory and a file descriptor. It is manageable, but it must be sized on purpose: the default open descriptor limits are reached sooner than one expects.
The state is no longer trivial. With HTTP you can put ten servers behind a load balancer and each request goes to any of them. With WebSockets, the client is tied to a specific server. If you want a message to reach a user connected to another server, you need something in the middle to distribute it (typically Redis).
Reconnection is yours. Connections drop: switching from Wi-Fi to data, the phone goes to sleep, a proxy cuts due to inactivity. The browser does not reconnect on its own. You must implement retries with increasing wait times and, above all, recover what happened while you were disconnected. That second point is the most forgotten and the one that produces hard-to-find bugs.
Intermediaries cut. Many proxies close inactive connections after one or five minutes. That's why a periodic ping is sent, not by the protocol but so that no one thinks it's dead.
When it's worth it and when it's not
It's worth it when the server has to speak first, followed: chat, instant notifications, live quotes, collaborative editing, games, panels that update themselves.
It's not worth it when the event is infrequent or when the client can ask without cost. Maintaining a thousand open connections to notify something that happens three times a day is a waste with maintenance included.
The forgotten alternatives
Poll every now and then. It sounds primitive and often it is the right answer. If the data changes every few minutes and the application does not need to react instantly, periodic polling is infinitely simpler to operate.
Server-Sent Events. An open connection where only the server sends, over normal HTTP. The browser reconnects on its own, which eliminates the most annoying part. If you only need to receive (notifications, task progress, a panel that updates), this is usually better than a WebSocket and almost no one considers it.
The question that orders the decision: do I need to send data from the client to the server through that same channel, and very often? If the answer is no, you probably do not need a WebSocket.
A note about the proxy
If you put nginx in front, you need to configure it so it does not break the protocol upgrade:
location /ws { proxy_pass http://127.0.0.1:3000; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_read_timeout 3600s; }
Without those lines the connection is established and cuts off after a minute, which is one of the most frustrating errors to diagnose because "it works locally".