What is the difference between WebSockets and HTTP long polling?
Learn how WebSockets differ from HTTP long polling — persistent full-duplex connections, lower latency, less overhead, and when to use each in real-time apps.
Expected Interview Answer
WebSockets keep a single, persistent, full-duplex TCP connection open so the server can push data to the client instantly, while HTTP long polling repeatedly opens short-lived requests that the server holds until it has data, then closes and must be reopened.
With long polling the client sends a request, the server delays the response until an update is ready (or a timeout fires), returns it, and the client immediately issues another request — every message pays the cost of new HTTP headers and connection setup. WebSockets upgrade the initial HTTP handshake once, then stream lightweight frames both ways over one connection, eliminating repeated request overhead and giving true bidirectional, low-latency messaging.
- Lower latency for server-to-client updates
- Far less overhead — no repeated HTTP headers per message
- True bidirectional communication over one connection
- Scales better for high-frequency real-time data
- Long polling still works through older proxies and firewalls
AI Mentor Explanation
Long polling is like a fielder who runs all the way to the captain, asks 'any new field change?', waits for an answer, then sprints back and immediately runs up to ask again — a fresh trip for every update. WebSockets are like a permanent walkie-talkie line between captain and fielder: instructions flow both ways the instant they are spoken, no running back and forth for each message.
Step-by-Step Explanation
Step 1
Client opens a request
In long polling the client sends an HTTP request; in WebSockets the client sends a one-time HTTP Upgrade handshake.
Step 2
Server behavior
Long polling holds the request open until data or a timeout; WebSockets switch the connection to the ws protocol and keep it open.
Step 3
Delivering updates
Long polling returns one response then the connection closes; WebSockets stream many frames both directions with no reopen.
Step 4
Reconnecting
Long polling must immediately issue a fresh request after each response; WebSockets simply keep reusing the same socket.
Step 5
Overhead comparison
Each long-poll cycle re-sends full HTTP headers; WebSocket frames add only a few bytes, cutting bandwidth dramatically.
What Interviewer Expects
- Understanding of persistent vs repeated connections
- Awareness of the WebSocket HTTP upgrade handshake
- Latency and overhead trade-offs between the two
- When long polling is still an acceptable fallback
- Grasp of full-duplex versus half-duplex messaging
Common Mistakes
- Claiming long polling keeps one connection open forever
- Thinking WebSockets do not start over HTTP at all
- Ignoring the per-request header overhead of long polling
- Assuming WebSockets are always the right choice regardless of scale or infrastructure
Best Answer (HR Friendly)
“Long polling is like repeatedly asking the server 'anything new?' and reopening the connection each time, which is slower and heavier. WebSockets open one lasting two-way connection so the server can send updates instantly, making it much better for live features like chat and notifications.”
Code Example
// WebSocket: one persistent, two-way connection
const socket = new WebSocket('wss://example.com/live')
socket.onmessage = (event) => {
console.log('Instant update:', event.data)
}
socket.onopen = () => socket.send('client ready')
// Long polling: reopen a request after every response
async function longPoll() {
const res = await fetch('/updates')
const data = await res.json()
console.log('Update:', data)
longPoll() // immediately ask again
}
longPoll()Follow-up Questions
- How does the WebSocket upgrade handshake work?
- When would you still choose long polling over WebSockets?
- How do WebSockets compare to Server-Sent Events?
- How do you scale WebSocket connections across multiple servers?
- How do you handle reconnection and missed messages with WebSockets?
MCQ Practice
1. What is the main advantage of WebSockets over HTTP long polling?
WebSockets maintain one long-lived, bidirectional connection, removing the repeated request overhead of long polling.
2. In HTTP long polling, what does the server do when it has no data yet?
The server delays the response until an update is available or a timeout occurs, then returns and the client must poll again.
3. How does a WebSocket connection begin?
A WebSocket starts as an HTTP request carrying an Upgrade header, which switches the connection to the ws/wss protocol.
Flash Cards
Is long polling full-duplex? — No — it is a repeated request/response cycle, effectively one direction at a time.
How many connections does WebSocket use? — One persistent connection reused for all messages in both directions.
What overhead does long polling add per message? — Full HTTP headers and connection setup on every poll cycle.
How does a WebSocket start? — With an HTTP Upgrade handshake that switches to the ws/wss protocol.