HTTP vs WebSocket

HTTP and WebSocket both ride on TCP, but they solve different problems. HTTP is a stateless request/response protocol optimized for fetching resources on demand. WebSocket keeps a single TCP connection open so client and server can push frames to each other at any time. Picking the wrong one leads to wasted bandwidth, sluggish UIs, or infrastructure bills that grow with idle users.

Connection model

An HTTP call is short-lived: the client opens a connection (or reuses a keep-alive one), sends a request, receives a response, and moves on. Each interaction is independent, which makes HTTP easy to cache at CDNs, load-balance across stateless workers, and retry safely. The server never speaks unless spoken to.

WebSocket flips that. After a one-time upgrade, the socket stays open for minutes, hours, or days. Either side can send a message frame whenever it wants, with no new handshake and only a few bytes of framing overhead. That makes it ideal for pushing data the client did not explicitly ask for.

The upgrade handshake

A WebSocket connection starts life as an ordinary HTTP/1.1 GET carrying special headers:

GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

If the server accepts, it replies with 101 Switching Protocols and the same TCP socket switches from HTTP framing to WebSocket framing. From that point on, no HTTP verbs, headers, or status codes are exchanged — just lightweight binary or text frames.

When HTTP is the right answer

• REST and GraphQL APIs. Discrete operations map cleanly onto request/response.
• Documents and assets. HTML, images, and JS bundles benefit from CDN caching that WebSocket cannot use.
• Stateless horizontal scaling. Any worker can serve any request; autoscaling is trivial.
• Infrequent updates. If data changes every few minutes, a poll or refetch is cheaper than holding a socket.
• Public, cacheable data. ETags, Cache-Control, and 304 responses cost almost nothing.

When WebSocket earns its keep

• Chat and messaging. Delivery latency matters and both sides talk.
• Live cursors and collaborative editing. Dozens of tiny updates per second per user.
• Stock tickers, sports scores, order books. Server-driven streams with high fan-out.
• Multiplayer games. Sub-100ms round trips without HTTP overhead per move.
• IoT command channels. A gateway can push commands to a device already connected.

Alternatives worth knowing

Server-Sent Events (SSE) is often the sweet spot when only the server needs to push. SSE is plain HTTP: the client opens a GET with Accept: text/event-stream and the server keeps writing data: lines. Browsers auto-reconnect and expose a Last-Event-ID header for resuming. There is no framing library, no upgrade dance, and it flows through most HTTP proxies untouched. If your app is a dashboard, notification feed, or LLM token stream, SSE is usually simpler than WebSocket.

Long polling is the classic fallback: the client sends a request, the server holds it open until data is ready (or a timeout fires), then the client immediately reconnects. It works anywhere HTTP does — useful for corporate networks that block WebSocket — but each message pays a full HTTP round trip.

WebTransport is the newer contender, built on HTTP/3 and QUIC. It offers reliable streams and unreliable datagrams over a single connection, plus better recovery from packet loss and network changes. It is still experimental in some browsers and server stacks, but for latency-sensitive apps like cloud gaming and AR it is the direction the platform is heading.

Cost and operational tradeoffs

Every open WebSocket consumes state on the server, the load balancer, and any middlebox in between: file descriptors, memory buffers, and a slot in connection tables. A million idle users cost real money even if none of them are sending traffic. HTTP has no such per-user tax — workers only allocate resources during an active request.

WebSocket also complicates deployments. Rolling restarts drop live sockets, sticky sessions may be needed for room-based apps, and horizontal scaling requires a pub/sub layer (Redis, NATS, Kafka) so a message published on node A reaches subscribers on node B. Health checks, timeout tuning, and observability all need dedicated attention.

Choosing quickly

Start with HTTP. Add SSE when the server needs to push but the client mostly listens. Reach for WebSocket when latency is critical and traffic is bidirectional and the volume justifies keeping connections open. Consider WebTransport when you are already invested in HTTP/3 and need unreliable datagrams. Long polling stays in your pocket as a fallback for restrictive networks.