How a WebSocket turns a request into an open line
A browser normally uses HTTP in a request-and-response pattern: it asks a server for something, and the server replies. That works well when the browser can predict what it needs, but it is awkward for chat. If the server has a new message, it cannot simply send it over an ordinary HTTP request that has already finished.
A WebSocket begins with an HTTP request, then asks to switch protocols. If the server agrees, the connection stays open and becomes a two-way channel. Either side can send data over that same connection without waiting for the other to start a new request.
Why that matters in a chat
Without a persistent channel, an app might repeatedly ask the server whether anything has changed. This technique, called polling, creates many small requests—even when there is no new message. With a WebSocket, the server can send an update when it arrives, while the user’s device can send a reply through the same open line.
That reduces the back-and-forth needed to deliver updates and can make a chat feel more immediate. It does not eliminate network delay: a message still has to travel across the internet, and the server must process it. The advantage is that neither side has to wait for a fresh request cycle just to begin sending.
An open connection has a cost
Keeping a channel available means the server and device must track it, and networks can sometimes interrupt idle connections. Applications may use lightweight keepalive messages to check that the line is still working, and reconnect if it breaks. So WebSockets trade the overhead of repeated requests for the work of maintaining open connections—a useful exchange when updates need to flow in both directions.
