HTTP request-response versus WebSocket connections?
understanding request-response versus persistent bidirectional models.
HTTP is request-initiated, pull-based, client waits for response. WebSocket is persistent, bidirectional, either side sends data anytime.
Http request-response model
HTTP is stateless and request-driven. A client sends a request, the server processes it, sends a response, and the connection closes. The server cannot initiate communication; it only reacts. For live chat, the server would need to wait for the client to repeatedly ask, Is there a new message? via polling. This is inefficient and high-latency.
Websocket persistent connection
WebSocket upgrades the initial HTTP connection into a persistent bidirectional tunnel over TCP. Once established, both client and server can send data at any time without request-response framing. The connection stays open, allowing instant message delivery. The WebSocket handshake uses HTTP upgrade headers, but the protocol is completely different after that.
Why websockets for live chat
In a live chat, multiple participants send and receive messages. With HTTP, either the client polls continuously (wasteful and delayed) or the server polls client connections (impossible; server cannot initiate). WebSocket solves this: Server sees new message, immediately pushes to all clients subscribed to the chat room. Clients see messages within milliseconds, no polling delay.
Efficiency comparison
HTTP polling generates request headers and response metadata with every check, even if no new message exists. For 100 users polling every second, that is millions of headers per hour. WebSocket sends only actual data: a few bytes per message. Latency is sub-100ms for WebSocket versus seconds for polling, and server load is orders of magnitude lower.
When http is fine
HTTP is appropriate for request-response operations where the client asks for something specific. Getting user profile data, uploading a file, or paginating results fit the model. Mixed architectures use HTTP for setup and control (auth, configuration) and WebSocket for real-time data (chat, notifications, live feeds).
Interview question
Why can't a server send a chat message to a client over plain HTTP without the client asking first?
- a.HTTP is request-driven; the server has no way to initiate communication or keep a persistent connection open to push data.Correct
- b.HTTP doesn't allow multiple messages in a single connection.
- c.HTTP connections don't support binary data, only text messages.
- d.The client must close its connection after each request, preventing the server from sending responses.
Why? this is the answer
HTTP's stateless model requires client initiation. The server cannot send unsolicited data. WebSocket solves this with a persistent, bidirectional tunnel. HTTP does support binary data and multiple requests per connection. The fundamental issue is that HTTP is pull-based, not push-based.
Just read this? Test yourself on what you have been reading.
Read the original → developer.mozilla.org
- #websocket
- #http
- #real-time
- #bidirectional
- #communication
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles