Client-Server Communication Patterns
Overview
Every time you check your email, watch a live stream, or collaborate in Google Docs, your device needs to communicate with a server. But how does it get updates? The method chosen determines whether you see changes instantly or with a frustrating delay—and whether your battery drains in minutes or lasts all day.
There are three fundamental approaches: Short Polling (asking repeatedly), Long Polling (asking and waiting), and WebSockets (keeping a line open). Each represents a different philosophy about how clients and servers should talk to each other.
Communication Protocols in Action
SELECT PROTOCOL TO VISUALIZE
Protocol Characteristics
| Aspect | Short Polling | Long Polling | WebSocket |
|---|---|---|---|
| latency | Up to interval | Near zero | Milliseconds |
| bandwidth | High | Medium | Low |
| complexity | Simple | Medium | Complex |
| server Load | High | Medium | Low |
Key Concepts
Client
Your device (browser, mobile app) that needs information from somewhere else. It initiates the conversation.
Server
A remote machine that stores data, processes requests, and sends responses. It holds the information you want.
Request/Response
The fundamental pattern—client asks a question, server provides an answer. HTTP is built entirely on this model.
Connection
The 'pipe' between client and server. Creating a new one takes time (TCP handshake), which is why reusing connections matters.
Latency
The time delay from sending a request to receiving a response. Real-time apps fight to minimize this.
Overhead
Extra data sent beyond your actual message—HTTP headers, connection setup, acknowledgments. This 'tax' adds up fast.
The Evolution of Real-Time Communication
Modern web applications evolved from static pages that only updated when you clicked "refresh." Today's users expect instant updates—new messages should appear now, not when you remember to check. This expectation drove the evolution from polling to WebSockets.
Short Polling: The Impatient Child
Imagine a child on a road trip repeatedly asking "Are we there yet?" every 30 seconds. The parent must stop and respond each time, even when the answer is always "no." Both parties waste energy on these pointless check-ins.
How it works:
Short polling is the simplest approach: the client sends a request at fixed intervals (every 3 seconds, every 10 seconds), and the server immediately responds with whatever data is currently available.
- Client sends: "Do you have new data?"
- Server immediately responds: "No" (or "Yes, here it is")
- Client waits for the interval to pass
- Client asks again
The fundamental problem:
Most responses contain no new data. If updates happen once per minute on average, but you poll every 3 seconds, roughly 95% of your requests are wasted. That's:
- Wasted bandwidth on HTTP headers (typically 700-1000 bytes per request)
- Wasted server CPU processing identical requests
- Wasted battery keeping the radio active
- Guaranteed latency up to your polling interval
At a 3-second polling interval over 1 hour:
| Metric | Value |
|---|---|
| Total requests | 1,200 |
| HTTP header overhead | ~1.2 MB |
| Actual useful data (assuming 100 events) | ~10 KB |
| Efficiency | Less than 1% |
You're shipping 100× more data than necessary.
When short polling makes sense:
Despite its inefficiency, short polling has advantages: it's dead simple to implement, works through every firewall and proxy, and responses can be CDN-cached. For data that genuinely changes slowly (weather, daily reports), this simplicity wins.
Long Polling: The Patient Listener
Instead of asking repeatedly, the child asks once: "Tell me when we're almost there." The parent says "I'll let you know," and the child waits in silence. Communication only happens when there's actually something to say.
How it works:
Long polling flips the model: instead of responding immediately, the server holds the connection open until it has something meaningful to send.
- Client sends: "Do you have new data? I'll wait."
- Server receives request... and doesn't respond yet
- Server waits (up to 30 seconds) for new data to arrive
- When data arrives, server responds: "Yes, here it is"
- Client immediately sends a new request (back to step 1)
The key insight:
By holding connections open, the server eliminates empty responses. Data arrives at the client almost instantly after it's available on the server—you get near real-time behavior using standard HTTP.
Long polling reduces overhead by 70-80% in typical scenarios. Instead of 1,200 requests per hour, you might send only 100-200 (one per actual event, plus occasional timeout reconnections).
The complexity trade-off:
Long polling introduces challenges:
- Timeout handling: What happens when the server holds a connection for 30 seconds with no data? The client needs to reconnect cleanly.
- Connection limits: Browsers limit concurrent connections to ~6 per domain. One held connection means fewer available for other requests.
- Proxy interference: Some proxies may close connections that appear "idle" even though they're waiting intentionally.
- Server resources: Holding thousands of open connections requires careful resource management.
Real-world usage:
Long polling powered Facebook notifications, early Slack, and Gmail for years. It's the practical choice when you need real-time behavior but can't use WebSockets (corporate firewalls, older infrastructure, simpler deployment).
WebSocket: The Open Phone Line
Instead of calling and hanging up repeatedly, you establish a phone call and leave the line open. Either party can speak at any time without dialing again. The connection stays live for hours or days, with communication flowing freely in both directions.
How it works:
WebSocket starts as HTTP, then "upgrades" to a different protocol entirely:
- Client sends HTTP request with special headers asking to upgrade
- Server responds: "OK, let's switch protocols"
- The TCP connection transforms—it's no longer HTTP
- Both client and server can send messages at any time
- Connection stays open until someone explicitly closes it
Why this is revolutionary:
- True bidirectional: The server can push data without the client asking. No more "polling" at all.
- Minimal overhead: After the initial handshake, messages need only 2-14 bytes of framing (vs. 700+ bytes for HTTP headers)
- Persistent connection: No repeated TCP handshakes, DNS lookups, or TLS negotiations
Sending 100 messages over 1 hour:
| Protocol | Requests | Header Overhead | Data | Total |
|---|---|---|---|---|
| Short Polling | 1,200 | 1.2 MB | 10 KB | 1.21 MB |
| Long Polling | 100 | 100 KB | 10 KB | 110 KB |
| WebSocket | 1 | 1 KB | 10 KB | 11 KB |
WebSocket uses 99% less bandwidth than short polling.
The complexity trade-off:
WebSocket's power comes with operational challenges:
- Special server support: You can't use standard web servers; you need WebSocket-capable infrastructure
- Load balancer complexity: Sticky sessions or WebSocket-aware load balancers required
- Scaling difficulty: 100,000 persistent connections need different architecture than 100,000 stateless requests
- Debugging challenges: Standard HTTP tools don't work; you need WebSocket-specific monitoring
- Firewall issues: Some corporate firewalls block WebSocket connections
When to Use What
Don't choose WebSocket just because it's "better." A dashboard that refreshes every 30 seconds doesn't need a persistent connection. Match the tool to the problem—premature optimization here adds complexity without benefit.
Choose Short Polling when:
- Updates are genuinely infrequent (weather, daily reports)
- Simplicity matters more than efficiency
- Content can be CDN-cached
- You're building a quick prototype
Choose Long Polling when:
- You need near real-time but can't use WebSocket
- Corporate firewalls might block WebSocket
- You want HTTP-only infrastructure (simpler deployment)
- Moderate message frequency (1-10 events per minute)
Choose WebSocket when:
- Milliseconds matter (trading, gaming, collaboration)
- Server needs to push data without client asking
- High message frequency (multiple events per second)
- Bidirectional communication is essential
Real-World Applications
Short Polling
Weather updates, email inbox checks, dashboard metrics that change slowly
Long Polling
Social media notifications, chat applications, Gmail's web interface
WebSocket
Stock trading platforms, multiplayer games, Google Docs collaboration, live sports scores
Real-World Examples
| Service | Protocol | Why This Choice |
|---|---|---|
| Gmail | Long Polling | Works through corporate firewalls; doesn't need sub-second latency |
| Slack | WebSocket + fallback | Real-time chat needs low latency; falls back to polling when blocked |
| Stock Tickers | WebSocket | Millisecond updates matter for trading decisions |
| Weather Apps | Short Polling | Data genuinely changes every 15+ minutes; simplicity wins |
| Google Docs | WebSocket | Collaborative editing requires instant sync between users |
| Twitter Feed | Short Polling + Push | Timeline can tolerate delay; critical alerts use push notifications |
Advantages & Limitations
Advantages
- ✓Short Polling: Dead simple to implement and debug
- ✓Short Polling: Works everywhere, CDN-cacheable, firewall-friendly
- ✓Long Polling: Near real-time without WebSocket complexity
- ✓Long Polling: Uses standard HTTP infrastructure
- ✓WebSocket: Minimal latency and bandwidth overhead
- ✓WebSocket: True bidirectional server push
Limitations
- ×Short Polling: Wastes bandwidth, server resources, and battery
- ×Short Polling: Latency limited to polling interval
- ×Long Polling: Complex timeout handling and reconnection logic
- ×Long Polling: Still fundamentally one-way (client initiates)
- ×WebSocket: Requires specialized server infrastructure
- ×WebSocket: Harder to scale, debug, and operate
Best Practices
- Start Simple: Begin with polling, upgrade to WebSocket only when you prove you need it
- Exponential Backoff: After connection failures, wait longer before retrying (1s, 2s, 4s, 8s...) to avoid overwhelming servers
- Heartbeats: Send periodic 'ping' messages to detect dead connections before users notice
- Graceful Fallback: WebSocket-first apps should fall back to Long Polling → Short Polling automatically
- Connection Limits: Remember browsers allow only 6 HTTP connections per domain; use connection pooling wisely
- Compression: Enable gzip/deflate for message payloads to reduce bandwidth further
The Decision Framework
"What happens if the user sees data 5 seconds late?"
- "Nothing, they won't notice" → Short Polling
- "Annoying, but functional" → Long Polling
- "They lose money or the experience breaks" → WebSocket
The right choice depends on your actual requirements, not theoretical ideals. A weather app with WebSocket is over-engineered. A trading platform with 30-second polling is broken. Know your latency budget, then choose the simplest solution that meets it.