Long Polling vs Short Polling vs Keep-Alive

Short Polling

Client asks server repeatedly at fixed intervals — "anything new?"

Client --- GET /updates (t=0s)
Client <-- "nothing new"
Client --- GET /updates (t=2s)
Client <-- "nothing new"
Client --- GET /updates (t=4s)
Client <-- "here's new data!"

• Simple to implement.
• Wasteful — most requests return nothing.
• High server load, unnecessary network traffic.
• Example: Old email clients checking inbox every 30s.

Long Polling

Client asks server, server holds the request open until there's new data.

Client --- GET /updates
(server holds request open...)
(server holds request open...)
(new data arrives!)
Client <-- "here's new data!"
Client --- GET /updates (immediately reconnects)
(server holds again...)

• Much more efficient than short polling.
• Server only responds when data is available.
• Still HTTP request-response, just delayed.
• Example: Facebook notifications (old), Jira live updates.

Keep-Alive (in this context)

Not a polling technique — it's TCP connection reuse across multiple HTTP requests. Completely different concept — about saving TCP handshake overhead, not about real-time updates.

All Three Together

	Short Polling	Long Polling	Keep-Alive
What it solves	Real-time updates	Real-time updates	TCP overhead
How	Repeated requests	Hold request open	Reuse connection
Efficiency	Low	Medium	High
Latency	High (interval)	Low (instant)	N/A
Server load	High	Medium	Reduces it
Complexity	Low	Medium	None (default)

Real-Time Techniques — Full Picture

Technique	Direction	Connection	Best For
Short Polling	Client → Server	New each time	Simple, low frequency
Long Polling	Client → Server	Held open	Notifications, chat fallback
SSE	Server → Client	Persistent	Live feed, notifications
WebSocket	Both	Persistent	Chat, gaming, collaboration

When to Use What

• Short polling — update frequency is low, simplicity matters.
• Long polling — need near real-time, can't use WebSocket (firewall issues).
• SSE — server pushes only, e.g. live scores, stock ticker.
• WebSocket — full real-time, both sides send, e.g. chat, multiplayer.

Short Polling --- simple, wasteful
Long Polling  --- better, still HTTP
SSE           --- server pushes, one direction
WebSocket     --- full duplex, best for real-time

---

— End of Computer Networks Interview Notes —