Today, I’m revisiting client-server communication mechanisms. The main methods are outlined in the table below for easier understanding.
| Mechanism | Based on | Direction | Pros | Cons | Typical Use Cases |
| Polling | HTTP/1.x | Client → Server | • Very simple to implement • Works everywhere | • High latency (depends on interval) • High overhead (many HTTP headers & TCP handshakes) • Wastes resources | Periodic updates, legacy apps |
| Long Polling | HTTP/1.x | Pseudo Client ⇄ Server | • Lower latency than polling • Compatible with firewalls/proxies • Easy fallback when WebSocket is blocked | • Still request/response per message • Server must manage many hanging connections • Not truly bidirectional | Early chat apps, push notifications |
| SSE | HTTP/1.x (text/event-stream) | Server → Client | • True server push • Auto-reconnect & last-event-id support • Lightweight over HTTP • Easy to use (EventSource API) | • One-way only (server → client) • Limited binary support • No IE support | News feeds, stock tickers, real-time dashboards |
| WebSocket | TCP + HTTP upgrade | Server ⇄ Client | • Full duplex (true bidirectional) • Low latency, small header overhead • Good for interactive apps | • More complex to implement • Needs heartbeat/keep-alive • Might be blocked by some proxies/firewalls | Chat, online gaming, collaborative apps |
| QUIC / HTTP/3 | UDP + TLS (IETF QUIC) | Server ⇄ Client | • Multiplexing without head-of-line blocking • 0-RTT connection setup • Built-in encryption • Mobile friendly (connection survives IP/port change) | • More CPU usage (UDP + TLS overhead) • Middlebox/proxy compatibility issues (still evolving) | Modern web (HTTP/3), video streaming, mobile apps |