What Are WebSockets?
How a WebSocket Connection Works
What are WebSockets? They are a protocol that keeps a single connection open between a client, usually a web browser, and a server, so that both sides can send messages at any time. Connections use ws:// or, when encrypted, wss://, the WebSocket equivalent of HTTPS.
A WebSocket connection starts as an ordinary HTTP request that asks to switch protocols. If the server agrees, the connection changes to WebSocket messaging and stays open. A standard HTTP exchange works more like a letter: the client sends a request, the server sends one response, and the exchange ends. Any further message needs a new request.
Because the connection stays open, the server can push a message the moment something changes, such as a new chat message or a status update on an order. The client does not need to ask again. Ordinary API calls remain the norm for requests made on demand.
WebSockets Compared With Polling and Server-Sent Events
Before WebSockets were widely supported, developers used long polling, where the server holds a request open until it has something to send and the client immediately makes a new one. Server-Sent Events (SSE) is a standard in which the server streams updates to the browser over a single HTTP response. SSE is simpler but one-directional: the browser receives messages, and anything it sends travels through separate requests.
WebSockets allow two-way traffic on one connection, which suits interactive applications such as chat, collaborative editing and multiplayer games. For a dashboard that only displays live numbers, SSE is often enough. For data that changes rarely, plain polling may be the simplest choice.
Between backend services, continuous exchanges are often handled by streaming in gRPC, while event notifications between systems are usually sent as webhooks.
Hosting Considerations for Long-Lived Connections
A WebSocket connection can last minutes or hours rather than milliseconds, and this changes what the hosting environment must support. Every open connection uses memory and a network socket on the server, so an application with many simultaneous users needs capacity planned around open connections, not only around requests per second.
Intermediaries matter too. Reverse proxies and load balancers must pass the upgrade request through and must not close idle connections too early. Shared hosting plans often limit how long a process can run and how many connections it can hold, so real-time features may need a plan or service designed for persistent connections.
A Live Order Status Example
An online store wants customers to see an order move from packed to shipped without refreshing the page. With WebSockets, the store's server pushes each status change to the open page as soon as it arrives. With polling, the page would ask the server every few seconds and usually receive nothing new. Often the two are combined: a shipping provider sends a webhook when a parcel is scanned, the store's server records the change, and the open connection delivers it to the customer's browser.
Frequently asked questions
Are WebSockets the same as HTTP?
No. A WebSocket connection begins with an HTTP handshake, but then it switches to its own message-based protocol. Ordinary HTTP is request and response, always started by the client, while a WebSocket lets either side send messages once the connection is open.
Do WebSockets work in all browsers?
Modern browsers support WebSockets widely, so browser support is rarely the obstacle today. The more common problems are network infrastructure, such as proxies that block or time out idle connections, and the need for application code to reconnect after a dropped connection.