Websocket - Learning Module

Loading content...

0/228

Comparison with Polling

The Evolution of Real-Time Web Communication

WebSocket didn't emerge in a vacuum. Before its standardization in 2011, web developers had devised ingenious—if sometimes hacky—techniques to simulate real-time communication within HTTP's constraints. Understanding these techniques illuminates why WebSocket was needed and helps you make informed decisions in scenarios where WebSocket might be overkill or unavailable.

Each approach represents a different tradeoff between simplicity, efficiency, latency, and compatibility. There's no universally 'best' solution; the optimal choice depends on your specific requirements for update frequency, latency tolerance, bidirectionality needs, and infrastructure constraints.

This page provides a rigorous technical comparison, moving beyond marketing claims to understand the actual performance characteristics, resource consumption, and implementation complexity of each approach.

What You Will Learn

By the end of this page, you will understand the technical differences between traditional polling, long-polling, Server-Sent Events (SSE), and WebSocket. You'll be equipped to analyze requirements and select the appropriate technology, avoiding both over-engineering (WebSocket where simpler suffices) and under-engineering (polling where real-time is essential).

Traditional Polling: The Naive Approach

Traditional polling (also called short polling) is the most straightforward approach to checking for updates: the client periodically asks the server 'anything new?' at fixed intervals.

How It Works:

Client sets a timer (e.g., every 5 seconds)
When timer fires, client sends HTTP request to check for updates
Server responds immediately with current data (or 'no updates')
Client processes response, resets timer, waits for next interval
Repeat indefinitely

Implementation Example:

Traditional Polling Implementation
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
// Traditional polling - client side
function startPolling(interval = 5000) {
    async function poll() {
        try {
            const response = await fetch('/api/notifications?since=' + lastSeenId);
            const data = await response.json();
            
            if (data.notifications.length > 0) {
                data.notifications.forEach(processNotification);
                lastSeenId = data.lastId;
            }
        } catch (error) {
            console.error('Polling error:', error);
        }
        
        // Schedule next poll (even on error)
        setTimeout(poll, interval);
    }
    
    poll(); // Start polling
}
 
startPolling(5000); // Poll every 5 seconds

Advantages of Traditional Polling:

Simplicity: Easy to implement, debug, and understand
Stateless Server: No connection state to manage; each request is independent
Infrastructure Compatibility: Works with any HTTP infrastructure—CDNs, load balancers, proxies
Predictable Load: Regular, spaced requests create steady server load
Easy Recovery: If a poll fails, just try again next interval

Disadvantages of Traditional Polling:

Latency: Average delay is half the polling interval; 5-second poll means 2.5-second average wait
Wasted Requests: Most polls return 'nothing new,' consuming resources for no purpose
Scalability: Request count scales linearly with users AND polling frequency
Bandwidth: Each request includes full HTTP headers, consuming ~500-800 bytes minimum
Battery/Mobile: Frequent network requests drain mobile device batteries

Polling Overhead Analysis (10,000 users)
Polling Interval	Requests/Second	Daily Requests	Header Bandwidth/Day
1 second	10,000	864 million	~600 GB
5 seconds	2,000	173 million	~120 GB
30 seconds	333	29 million	~20 GB
1 minute	167	14 million	~10 GB

When Traditional Polling Makes Sense

Polling is appropriate when: update frequency is inherently low (checking daily prices), latency tolerance is high (background sync every few minutes), the system is simple and doesn't justify WebSocket complexity, or when clients are behind restrictive firewalls that block WebSocket. The key is aligning polling interval with actual update frequency.

Long Polling: Holding the Line

Long polling (also called Comet or hanging GET) inverts traditional polling's approach: instead of the server responding immediately, it holds the connection open until new data is available.

How It Works:

Client sends HTTP request asking for updates
If no updates are available, server holds the request open (doesn't respond)
Server waits until: (a) new data arrives, OR (b) timeout occurs (typically 30-60 seconds)
Server responds with data (or empty response on timeout)
Client immediately sends another request, and the cycle repeats

Implementation Example:

Long Polling Implementation
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
// Long polling - client side
async function longPoll() {
    try {
        const controller = new AbortController();
        const timeoutId = setTimeout(() => controller.abort(), 65000); // Client timeout
        
        const response = await fetch('/api/long-poll?since=' + lastSeenId, {
            signal: controller.signal
        });
        clearTimeout(timeoutId);
        
        if (response.ok) {
            const data = await response.json();
            if (data.notifications.length > 0) {
                data.notifications.forEach(processNotification);
                lastSeenId = data.lastId;
            }
        }
    } catch (error) {
        if (error.name === 'AbortError') {
            console.log('Long poll timeout - reconnecting');
        } else {
            console.error('Long poll error:', error);
            await sleep(1000); // Brief delay on error before retry
        }
    }
    
    // Immediately reconnect for next long poll
    longPoll();
}
 
longPoll(); // Start long-polling loop

Advantages of Long Polling:

Lower Latency: Events delivered as soon as they occur (no polling interval delay)
Fewer Wasted Requests: Only returns when there's data (or timeout)
HTTP Compatible: Works with most HTTP infrastructure (with caveats)
Fallback Option: Can serve as WebSocket fallback in restrictive environments

Disadvantages of Long Polling:

Connection Holding: Server must maintain open connections for all waiting clients
Complexity: More complex than simple polling; timeout handling, reconnection logic
One-Way Latency: Delivering data to server still requires separate HTTP requests
Proxy Issues: Some proxies (corporate, CDN) timeout long-held connections aggressively
Resource Consumption: Each waiting request consumes a server thread/connection slot

Long Polling vs. Traditional Polling (10,000 users)
Metric	Traditional (5s)	Long Polling (60s timeout)
Requests when idle	2,000/second	~167/second (timeouts)
Latency when event occurs	~2.5 seconds average	~0 (immediate)
Held connections	0	~10,000 (all users)
Bandwidth (idle)	~120 GB/day	~10 GB/day
Server threads needed	Few (quick responses)	Many (waiting)

The Thread Problem

Long polling's critical limitation is server architecture. With traditional synchronous servers (Apache, older Java servlets), each held connection consumes a thread. 10,000 concurrent users means 10,000 threads—typically impossible. Long polling requires async server architectures (Node.js, asyncio, Netty) that handle thousands of connections with few threads. Without async, long polling doesn't scale.

Server-Sent Events: One-Way Streaming

Server-Sent Events (SSE) is a standardized API and protocol for server-to-client streaming over HTTP. Unlike polling or long-polling, SSE maintains a persistent connection where the server can push multiple messages over time.

How It Works:

Client opens connection to SSE endpoint using EventSource API
Server responds with Content-Type: text/event-stream and keeps connection open
Server sends events as they occur using a simple text format
Browser parses events and fires JavaScript callbacks
Connection stays open indefinitely; browser auto-reconnects on failure

The SSE Wire Format:

SSE Implementation
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
// SSE - client side
const eventSource = new EventSource('/api/events');
 
// Default event type
eventSource.onmessage = (event) => {
    const data = JSON.parse(event.data);
    console.log('Received:', data);
};
 
// Named event types
eventSource.addEventListener('notification', (event) => {
    const notification = JSON.parse(event.data);
    showNotification(notification);
});
 
eventSource.addEventListener('price-update', (event) => {
    const update = JSON.parse(event.data);
    updatePrice(update.symbol, update.price);
});
 
// Connection management
eventSource.onopen = () => console.log('SSE connected');
eventSource.onerror = (error) => {
    console.error('SSE error:', error);
    // Browser auto-reconnects; we just log
};
 
// To close explicitly
// eventSource.close();

SSE Wire Format Specification:

event: — Event type (defaults to 'message')
data: — Event payload (multiple data lines concatenated with newlines)
id: — Event ID for resumption after reconnect (browser sends Last-Event-ID header)
retry: — Reconnection delay in milliseconds
: — Comment (ignored; often used for keepalive)
Events separated by blank lines (\n\n)

Advantages of Server-Sent Events:

Built-in Reconnection: Browser automatically reconnects on failure
Event IDs and Resumption: Server can resume from where client left off
Simple Protocol: Text-based, debuggable with curl
HTTP/2 Friendly: Multiplexes well with other HTTP/2 streams
Named Events: Multiple event types over single connection

Disadvantages of Server-Sent Events:

Server-to-Client Only: No client-to-server data over SSE (requires separate HTTP requests)
Connection Limits: Browsers limit SSE connections per domain (typically 6 in HTTP/1.1)
Text Only: Binary data requires base64 encoding (inefficient)
No Binary Framing: Less efficient than WebSocket for high-frequency data

SSE's Sweet Spot

SSE excels when: you only need server-to-client push (not bidirectional), you want simple implementation and debugging, you're already using HTTP/2 (solves connection limit), you need automatic reconnection with event resumption, or you're building a system that naturally separates reads (SSE) from writes (regular HTTP). News feeds, stock tickers, and notification streams are ideal SSE use cases.

WebSocket: The Full-Duplex Solution

Now let's explicitly position WebSocket against all three alternatives we've examined. WebSocket's core differentiator is full duplex over a single connection with minimal overhead.

Comprehensive Comparison
Aspect	Traditional Polling	Long Polling	SSE	WebSocket
Connection type	New per request	New per update cycle	Persistent (one-way)	Persistent (bidirectional)
Directionality	Client-initiated only	Client-initiated only	Server → Client	Full duplex
Latency (server → client)	Half polling interval	Near-zero	Near-zero	Near-zero
Latency (client → server)	Zero (sends anytime)	HTTP request time	HTTP request time	Near-zero
Per-message overhead	500-800 bytes headers	500-800 bytes headers	~50-100 bytes	2-14 bytes
Binary data	Base64 encoded	Base64 encoded	Base64 encoded	Native binary frames
Auto-reconnection	Manual	Manual	Built-in	Manual
Browser support	Universal	Universal	All modern	All modern
HTTP/2 benefits	Yes (multiplexing)	Limited	Yes	No (separate protocol)

Choose WebSocket When

•Bidirectional data flow is essential
•Sub-100ms latency in both directions
•High-frequency updates (multiple per second)
•Binary data is significant
•Single connection simplicity preferred
•Custom protocol/framing needed

Prefer Alternatives When

•Server-push only (no client streaming) → SSE
•Updates are infrequent (< 1/minute) → Polling
•HTTP/2 already deployed → SSE
•Infrastructure doesn't support WebSocket → Long Polling
•Simpler debugging/monitoring needed → SSE or Polling
•Event resumption after reconnect → SSE

The Real Decision Factor

The single most important question: Do you need significant client-to-server data flow over the persistent connection? If yes, WebSocket. If the client only sends occasional actions and the main flow is server-to-client, SSE with regular HTTP requests for actions is often simpler and equally effective.

Performance Deep Dive: Quantitative Analysis

Let's move beyond qualitative comparison to concrete performance analysis. We'll model a real-time notification system serving 100,000 concurrent users, with average of 10 notifications per user per hour.

System Parameters:

100,000 concurrent users
10 notifications/user/hour = ~278 notifications/second system-wide
Each notification: ~500 bytes of actual data
Acceptable latency: <1 second for 95% of notifications

Resource Consumption Comparison
Metric	Polling (5s)	Long Polling	SSE	WebSocket
Total requests/second	20,000	~850*	1 initial	1 initial
Concurrent connections	~varies	~100,000	~100,000	~100,000
Notification latency (avg)	2,500ms	<50ms	<50ms	<50ms
Header overhead/day	~1.2 TB	~60 GB	~2 GB	~20 MB
Data bandwidth/day	~4 GB	~4 GB	~4 GB	~4 GB
Server CPU (relative)	1x	0.5x	0.3x	0.2x
Memory per user	0 (stateless)	~10KB	~5KB	~5KB

Analysis Notes:

Long polling requests = (timeouts) + (actual events) + (reconnects) ≈ 100,000/60s + 278 + margin ≈ 2,000/s in steady state

Why WebSocket Wins on Overhead:

The header overhead difference is staggering:

Polling: Each of 20,000 requests/second includes ~600 bytes of headers = 12 MB/second = 1 TB/day
WebSocket: After handshake, each notification is ~502 bytes (500 data + 2 frame header) = 150 KB/second = 13 GB/day

And that's just headers! The actual notification data is identical (500 bytes × 1M notifications/day = 4 GB/day).

The Memory Tradeoff:

Persistent connections (Long Polling, SSE, WebSocket) require memory per connection. With efficient implementations:

Per-connection overhead: 2-10 KB depending on platform
For 100,000 users: 200 MB - 1 GB of RAM

This is the price of real-time: exchanging request overhead for connection memory.

The Crossover Point

For low-activity users (receiving < 1 message/minute), polling's per-request overhead may be less than WebSocket's persistent connection overhead. The crossover point depends on polling interval, message frequency, and server architecture. For active users (multiple messages/minute), WebSocket is almost always more efficient.

Infrastructure Considerations

Different technologies interact differently with web infrastructure. These practical considerations often influence technology choice more than theoretical performance.

Load Balancers:

Load Balancer Compatibility
Technology	L4 (TCP) LB	L7 (HTTP) LB	Session Affinity	Health Checks
Polling	Works	Works	Not needed	Standard HTTP
Long Polling	Works	Needs timeout config	Optional	Standard HTTP
SSE	Works	Needs timeout/buffering config	Required*	Tricky
WebSocket	Works	Needs explicit support	Required*	Custom

*Session affinity required if server maintains per-connection state that isn't replicated.

CDNs and Caching:

Polling: Can be cached for appropriate TTL (if responses are cacheable)
Long Polling: Generally not cacheable (personalized, time-sensitive)
SSE: Not cacheable (streaming response)
WebSocket: Passes through (not cacheable; many CDNs proxy it)

Corporate Firewalls and Proxies:

Some corporate networks aggressively filter or block WebSocket:

Deep packet inspection may not recognize WebSocket framing
Proxy servers may buffer indefinitely (breaking streaming)
Some proxies drop idle connections quickly
HTTPS helps but doesn't guarantee WebSocket will work

Mitigation Strategies:

Always use WSS (WebSocket over TLS)—harder to inspect/block
Implement fallback to SSE or long polling for hostile environments
Send periodic pings to prevent idle connection termination
Use HTTP/2-compatible proxy configurations for SSE

The Real World is Messy

In production, 1-5% of users may be behind infrastructure that breaks WebSocket despite your best efforts. Socket.IO and similar libraries gained popularity precisely because they automatically fall back through Long Polling when WebSocket fails. Consider your audience: enterprise B2B software faces more restrictive networks than consumer mobile apps.

Fallback Strategies and Progressive Enhancement

Given the reality that some users can't use WebSocket, robust applications implement fallback strategies. The goal: best experience when possible, working experience always.

The Fallback Chain:

WebSocket (best) → SSE → Long Polling → Traditional Polling (worst)

Implementation Approach:

Attempt WebSocket: Try to establish WebSocket connection
Quick Failure Detection: If WebSocket fails within 5 seconds, move to fallback
Try SSE: If server supports it, try EventSource
Fall Back to Long Polling: If SSE fails or isn't supported
Last Resort Polling: If all else fails, use traditional polling

Libraries That Handle This:

Real-Time Communication Libraries
Library	Primary Transport	Fallbacks	Notes
Socket.IO	WebSocket	Long Polling, SSE (v4+)	Most popular; rooms, namespaces built-in
SockJS	WebSocket	XHR streaming, iframe, etc.	Wide fallback support
SignalR	WebSocket	SSE, Long Polling	Microsoft ecosystem; .NET optimized
Pusher/Ably	WebSocket	Fallback included	Managed services
Phoenix Channels	WebSocket	Long Polling	Elixir/Phoenix; excellent scaling
ActionCable	WebSocket	Long Polling (via adapter)	Ruby on Rails built-in

Manual Fallback Implementation
JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
class RealtimeConnection {
    constructor(url, options = {}) {
        this.url = url;
        this.options = options;
        this.transport = null;
        this.listeners = new Map();
    }
    
    async connect() {
        // Try WebSocket first
        if (await this.tryWebSocket()) return;
        
        // Fall back to SSE
        if (await this.trySSE()) return;
        
        // Fall back to Long Polling
        if (await this.tryLongPolling()) return;
        
        // Last resort: Traditional Polling
        this.startPolling();
    }
    
    async tryWebSocket() {
        return new Promise((resolve) => {
            const ws = new WebSocket(this.url.replace('http', 'ws'));
            const timeout = setTimeout(() => {
                ws.close();
                resolve(false);
            }, 5000);
            
            ws.onopen = () => {
                clearTimeout(timeout);
                this.transport = { type: 'websocket', connection: ws };
                ws.onmessage = (e) => this.emit('message', JSON.parse(e.data));
                resolve(true);
            };
            
            ws.onerror = () => {
                clearTimeout(timeout);
                resolve(false);
            };
        });
    }
    
    async trySSE() {
        if (!window.EventSource) return false;
        
        return new Promise((resolve) => {
            const es = new EventSource(this.url + '/sse');
            const timeout = setTimeout(() => {
                es.close();
                resolve(false);
            }, 5000);
            
            es.onopen = () => {
                clearTimeout(timeout);
                this.transport = { type: 'sse', connection: es };
                es.onmessage = (e) => this.emit('message', JSON.parse(e.data));
                resolve(true);
            };
            
            es.onerror = () => {
                clearTimeout(timeout);
                resolve(false);
            };
        });
    }
    
    // ... tryLongPolling() and startPolling() implementations
}

When to Implement Fallback

For consumer web apps with diverse user bases, fallback is essential. For enterprise software where you control the network, or mobile apps (which don't have proxy issues), fallback adds complexity without benefit. Evaluate your audience and their network environments before investing in fallback infrastructure.

Summary: Choosing the Right Tool

We've conducted a rigorous comparison of real-time communication approaches. Let's consolidate the decision framework:

Key Decision Criteria

•Traditional Polling suits low-frequency, latency-tolerant scenarios with simple infrastructure requirements
•Long Polling provides lower latency than polling but requires async server architecture and careful proxy configuration
•SSE excels for server-push-only scenarios with built-in reconnection, event IDs, and HTTP/2 compatibility
•WebSocket is optimal for bidirectional, high-frequency, low-latency communication with minimal overhead
•Overhead comparison: WebSocket frame headers (2-14 bytes) vs. HTTP headers (500-800 bytes) is a 50-100x reduction
•Infrastructure reality: Some users are behind networks that block WebSocket; fallback strategies ensure universal reach
•The bidirectionality question is the key decision factor: if client streaming is needed, WebSocket; if server-push only, consider SSE

Quick Decision Guide:

Your Situation	Recommended Approach
Infrequent updates, high latency OK	Traditional Polling
Server push only, HTTP/2 available	SSE
Server push, needs wide compatibility	Long Polling (or SSE with fallback)
Bidirectional, real-time gaming/chat	WebSocket
Enterprise with proxy concerns	WebSocket with fallback chain
Maximum reach, variable environments	Library like Socket.IO

What's Next:

With a thorough understanding of WebSocket's position in the real-time landscape, the final page explores modern WebSocket applications: JavaScript examples, popular libraries, integration patterns, and emerging trends like WebTransport.

Page Complete

You now understand the tradeoffs between polling, long polling, SSE, and WebSocket. More importantly, you have the analytical framework to evaluate these technologies against your specific requirements. Remember: the best technology is the simplest one that meets your needs—don't use WebSocket where polling suffices, but don't use polling where real-time matters.

Comparison with Polling

The Evolution of Real-Time Web Communication

What You Will Learn

Traditional Polling: The Naive Approach

Traditional polling (also called short polling) is the most straightforward approach to checking for updates: the client periodically asks the server 'anything new?' at fixed intervals.

How It Works:

Client sets a timer (e.g., every 5 seconds)
When timer fires, client sends HTTP request to check for updates
Server responds immediately with current data (or 'no updates')
Client processes response, resets timer, waits for next interval
Repeat indefinitely

Implementation Example:

Traditional Polling Implementation
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
// Traditional polling - client side
function startPolling(interval = 5000) {
    async function poll() {
        try {
            const response = await fetch('/api/notifications?since=' + lastSeenId);
            const data = await response.json();
            
            if (data.notifications.length > 0) {
                data.notifications.forEach(processNotification);
                lastSeenId = data.lastId;
            }
        } catch (error) {
            console.error('Polling error:', error);
        }
        
        // Schedule next poll (even on error)
        setTimeout(poll, interval);
    }
    
    poll(); // Start polling
}
 
startPolling(5000); // Poll every 5 seconds

Advantages of Traditional Polling:

Simplicity: Easy to implement, debug, and understand
Stateless Server: No connection state to manage; each request is independent
Infrastructure Compatibility: Works with any HTTP infrastructure—CDNs, load balancers, proxies
Predictable Load: Regular, spaced requests create steady server load
Easy Recovery: If a poll fails, just try again next interval

Disadvantages of Traditional Polling:

Latency: Average delay is half the polling interval; 5-second poll means 2.5-second average wait
Wasted Requests: Most polls return 'nothing new,' consuming resources for no purpose
Scalability: Request count scales linearly with users AND polling frequency
Bandwidth: Each request includes full HTTP headers, consuming ~500-800 bytes minimum
Battery/Mobile: Frequent network requests drain mobile device batteries

Polling Overhead Analysis (10,000 users)
Polling Interval	Requests/Second	Daily Requests	Header Bandwidth/Day
1 second	10,000	864 million	~600 GB
5 seconds	2,000	173 million	~120 GB
30 seconds	333	29 million	~20 GB
1 minute	167	14 million	~10 GB

When Traditional Polling Makes Sense

Long Polling: Holding the Line

How It Works:

Client sends HTTP request asking for updates
If no updates are available, server holds the request open (doesn't respond)
Server waits until: (a) new data arrives, OR (b) timeout occurs (typically 30-60 seconds)
Server responds with data (or empty response on timeout)
Client immediately sends another request, and the cycle repeats

Implementation Example:

Long Polling Implementation
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
// Long polling - client side
async function longPoll() {
    try {
        const controller = new AbortController();
        const timeoutId = setTimeout(() => controller.abort(), 65000); // Client timeout
        
        const response = await fetch('/api/long-poll?since=' + lastSeenId, {
            signal: controller.signal
        });
        clearTimeout(timeoutId);
        
        if (response.ok) {
            const data = await response.json();
            if (data.notifications.length > 0) {
                data.notifications.forEach(processNotification);
                lastSeenId = data.lastId;
            }
        }
    } catch (error) {
        if (error.name === 'AbortError') {
            console.log('Long poll timeout - reconnecting');
        } else {
            console.error('Long poll error:', error);
            await sleep(1000); // Brief delay on error before retry
        }
    }
    
    // Immediately reconnect for next long poll
    longPoll();
}
 
longPoll(); // Start long-polling loop

Advantages of Long Polling:

Lower Latency: Events delivered as soon as they occur (no polling interval delay)
Fewer Wasted Requests: Only returns when there's data (or timeout)
HTTP Compatible: Works with most HTTP infrastructure (with caveats)
Fallback Option: Can serve as WebSocket fallback in restrictive environments

Disadvantages of Long Polling:

Connection Holding: Server must maintain open connections for all waiting clients
Complexity: More complex than simple polling; timeout handling, reconnection logic
One-Way Latency: Delivering data to server still requires separate HTTP requests
Proxy Issues: Some proxies (corporate, CDN) timeout long-held connections aggressively
Resource Consumption: Each waiting request consumes a server thread/connection slot

Long Polling vs. Traditional Polling (10,000 users)
Metric	Traditional (5s)	Long Polling (60s timeout)
Requests when idle	2,000/second	~167/second (timeouts)
Latency when event occurs	~2.5 seconds average	~0 (immediate)
Held connections	0	~10,000 (all users)
Bandwidth (idle)	~120 GB/day	~10 GB/day
Server threads needed	Few (quick responses)	Many (waiting)

The Thread Problem

Server-Sent Events: One-Way Streaming

How It Works:

Client opens connection to SSE endpoint using EventSource API
Server responds with Content-Type: text/event-stream and keeps connection open
Server sends events as they occur using a simple text format
Browser parses events and fires JavaScript callbacks
Connection stays open indefinitely; browser auto-reconnects on failure

The SSE Wire Format:

SSE Implementation
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
// SSE - client side
const eventSource = new EventSource('/api/events');
 
// Default event type
eventSource.onmessage = (event) => {
    const data = JSON.parse(event.data);
    console.log('Received:', data);
};
 
// Named event types
eventSource.addEventListener('notification', (event) => {
    const notification = JSON.parse(event.data);
    showNotification(notification);
});
 
eventSource.addEventListener('price-update', (event) => {
    const update = JSON.parse(event.data);
    updatePrice(update.symbol, update.price);
});
 
// Connection management
eventSource.onopen = () => console.log('SSE connected');
eventSource.onerror = (error) => {
    console.error('SSE error:', error);
    // Browser auto-reconnects; we just log
};
 
// To close explicitly
// eventSource.close();

SSE Wire Format Specification:

event: — Event type (defaults to 'message')
data: — Event payload (multiple data lines concatenated with newlines)
id: — Event ID for resumption after reconnect (browser sends Last-Event-ID header)
retry: — Reconnection delay in milliseconds
: — Comment (ignored; often used for keepalive)
Events separated by blank lines (\n\n)

Advantages of Server-Sent Events:

Built-in Reconnection: Browser automatically reconnects on failure
Event IDs and Resumption: Server can resume from where client left off
Simple Protocol: Text-based, debuggable with curl
HTTP/2 Friendly: Multiplexes well with other HTTP/2 streams
Named Events: Multiple event types over single connection

Disadvantages of Server-Sent Events:

Server-to-Client Only: No client-to-server data over SSE (requires separate HTTP requests)
Connection Limits: Browsers limit SSE connections per domain (typically 6 in HTTP/1.1)
Text Only: Binary data requires base64 encoding (inefficient)
No Binary Framing: Less efficient than WebSocket for high-frequency data

SSE's Sweet Spot

WebSocket: The Full-Duplex Solution

Now let's explicitly position WebSocket against all three alternatives we've examined. WebSocket's core differentiator is full duplex over a single connection with minimal overhead.

Comprehensive Comparison
Aspect	Traditional Polling	Long Polling	SSE	WebSocket
Connection type	New per request	New per update cycle	Persistent (one-way)	Persistent (bidirectional)
Directionality	Client-initiated only	Client-initiated only	Server → Client	Full duplex
Latency (server → client)	Half polling interval	Near-zero	Near-zero	Near-zero
Latency (client → server)	Zero (sends anytime)	HTTP request time	HTTP request time	Near-zero
Per-message overhead	500-800 bytes headers	500-800 bytes headers	~50-100 bytes	2-14 bytes
Binary data	Base64 encoded	Base64 encoded	Base64 encoded	Native binary frames
Auto-reconnection	Manual	Manual	Built-in	Manual
Browser support	Universal	Universal	All modern	All modern
HTTP/2 benefits	Yes (multiplexing)	Limited	Yes	No (separate protocol)

Choose WebSocket When

•Bidirectional data flow is essential
•Sub-100ms latency in both directions
•High-frequency updates (multiple per second)
•Binary data is significant
•Single connection simplicity preferred
•Custom protocol/framing needed

Prefer Alternatives When

•Server-push only (no client streaming) → SSE
•Updates are infrequent (< 1/minute) → Polling
•HTTP/2 already deployed → SSE
•Infrastructure doesn't support WebSocket → Long Polling
•Simpler debugging/monitoring needed → SSE or Polling
•Event resumption after reconnect → SSE

The Real Decision Factor

Performance Deep Dive: Quantitative Analysis

System Parameters:

100,000 concurrent users
10 notifications/user/hour = ~278 notifications/second system-wide
Each notification: ~500 bytes of actual data
Acceptable latency: <1 second for 95% of notifications

Resource Consumption Comparison
Metric	Polling (5s)	Long Polling	SSE	WebSocket
Total requests/second	20,000	~850*	1 initial	1 initial
Concurrent connections	~varies	~100,000	~100,000	~100,000
Notification latency (avg)	2,500ms	<50ms	<50ms	<50ms
Header overhead/day	~1.2 TB	~60 GB	~2 GB	~20 MB
Data bandwidth/day	~4 GB	~4 GB	~4 GB	~4 GB
Server CPU (relative)	1x	0.5x	0.3x	0.2x
Memory per user	0 (stateless)	~10KB	~5KB	~5KB

Analysis Notes:

Long polling requests = (timeouts) + (actual events) + (reconnects) ≈ 100,000/60s + 278 + margin ≈ 2,000/s in steady state

Why WebSocket Wins on Overhead:

The header overhead difference is staggering:

Polling: Each of 20,000 requests/second includes ~600 bytes of headers = 12 MB/second = 1 TB/day
WebSocket: After handshake, each notification is ~502 bytes (500 data + 2 frame header) = 150 KB/second = 13 GB/day

And that's just headers! The actual notification data is identical (500 bytes × 1M notifications/day = 4 GB/day).

The Memory Tradeoff:

Persistent connections (Long Polling, SSE, WebSocket) require memory per connection. With efficient implementations:

Per-connection overhead: 2-10 KB depending on platform
For 100,000 users: 200 MB - 1 GB of RAM

This is the price of real-time: exchanging request overhead for connection memory.

The Crossover Point

Infrastructure Considerations

Different technologies interact differently with web infrastructure. These practical considerations often influence technology choice more than theoretical performance.

Load Balancers:

Load Balancer Compatibility
Technology	L4 (TCP) LB	L7 (HTTP) LB	Session Affinity	Health Checks
Polling	Works	Works	Not needed	Standard HTTP
Long Polling	Works	Needs timeout config	Optional	Standard HTTP
SSE	Works	Needs timeout/buffering config	Required*	Tricky
WebSocket	Works	Needs explicit support	Required*	Custom

*Session affinity required if server maintains per-connection state that isn't replicated.

CDNs and Caching:

Polling: Can be cached for appropriate TTL (if responses are cacheable)
Long Polling: Generally not cacheable (personalized, time-sensitive)
SSE: Not cacheable (streaming response)
WebSocket: Passes through (not cacheable; many CDNs proxy it)

Corporate Firewalls and Proxies:

Some corporate networks aggressively filter or block WebSocket:

Deep packet inspection may not recognize WebSocket framing
Proxy servers may buffer indefinitely (breaking streaming)
Some proxies drop idle connections quickly
HTTPS helps but doesn't guarantee WebSocket will work

Mitigation Strategies:

Always use WSS (WebSocket over TLS)—harder to inspect/block
Implement fallback to SSE or long polling for hostile environments
Send periodic pings to prevent idle connection termination
Use HTTP/2-compatible proxy configurations for SSE

The Real World is Messy

Fallback Strategies and Progressive Enhancement

Given the reality that some users can't use WebSocket, robust applications implement fallback strategies. The goal: best experience when possible, working experience always.

The Fallback Chain:

WebSocket (best) → SSE → Long Polling → Traditional Polling (worst)

Implementation Approach:

Attempt WebSocket: Try to establish WebSocket connection
Quick Failure Detection: If WebSocket fails within 5 seconds, move to fallback
Try SSE: If server supports it, try EventSource
Fall Back to Long Polling: If SSE fails or isn't supported
Last Resort Polling: If all else fails, use traditional polling

Libraries That Handle This:

Real-Time Communication Libraries
Library	Primary Transport	Fallbacks	Notes
Socket.IO	WebSocket	Long Polling, SSE (v4+)	Most popular; rooms, namespaces built-in
SockJS	WebSocket	XHR streaming, iframe, etc.	Wide fallback support
SignalR	WebSocket	SSE, Long Polling	Microsoft ecosystem; .NET optimized
Pusher/Ably	WebSocket	Fallback included	Managed services
Phoenix Channels	WebSocket	Long Polling	Elixir/Phoenix; excellent scaling
ActionCable	WebSocket	Long Polling (via adapter)	Ruby on Rails built-in

Manual Fallback Implementation
JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
class RealtimeConnection {
    constructor(url, options = {}) {
        this.url = url;
        this.options = options;
        this.transport = null;
        this.listeners = new Map();
    }
    
    async connect() {
        // Try WebSocket first
        if (await this.tryWebSocket()) return;
        
        // Fall back to SSE
        if (await this.trySSE()) return;
        
        // Fall back to Long Polling
        if (await this.tryLongPolling()) return;
        
        // Last resort: Traditional Polling
        this.startPolling();
    }
    
    async tryWebSocket() {
        return new Promise((resolve) => {
            const ws = new WebSocket(this.url.replace('http', 'ws'));
            const timeout = setTimeout(() => {
                ws.close();
                resolve(false);
            }, 5000);
            
            ws.onopen = () => {
                clearTimeout(timeout);
                this.transport = { type: 'websocket', connection: ws };
                ws.onmessage = (e) => this.emit('message', JSON.parse(e.data));
                resolve(true);
            };
            
            ws.onerror = () => {
                clearTimeout(timeout);
                resolve(false);
            };
        });
    }
    
    async trySSE() {
        if (!window.EventSource) return false;
        
        return new Promise((resolve) => {
            const es = new EventSource(this.url + '/sse');
            const timeout = setTimeout(() => {
                es.close();
                resolve(false);
            }, 5000);
            
            es.onopen = () => {
                clearTimeout(timeout);
                this.transport = { type: 'sse', connection: es };
                es.onmessage = (e) => this.emit('message', JSON.parse(e.data));
                resolve(true);
            };
            
            es.onerror = () => {
                clearTimeout(timeout);
                resolve(false);
            };
        });
    }
    
    // ... tryLongPolling() and startPolling() implementations
}

When to Implement Fallback

Summary: Choosing the Right Tool

We've conducted a rigorous comparison of real-time communication approaches. Let's consolidate the decision framework:

Key Decision Criteria

•Traditional Polling suits low-frequency, latency-tolerant scenarios with simple infrastructure requirements
•Long Polling provides lower latency than polling but requires async server architecture and careful proxy configuration
•SSE excels for server-push-only scenarios with built-in reconnection, event IDs, and HTTP/2 compatibility
•WebSocket is optimal for bidirectional, high-frequency, low-latency communication with minimal overhead
•Overhead comparison: WebSocket frame headers (2-14 bytes) vs. HTTP headers (500-800 bytes) is a 50-100x reduction
•Infrastructure reality: Some users are behind networks that block WebSocket; fallback strategies ensure universal reach
•The bidirectionality question is the key decision factor: if client streaming is needed, WebSocket; if server-push only, consider SSE

Quick Decision Guide:

Your Situation	Recommended Approach
Infrequent updates, high latency OK	Traditional Polling
Server push only, HTTP/2 available	SSE
Server push, needs wide compatibility	Long Polling (or SSE with fallback)
Bidirectional, real-time gaming/chat	WebSocket
Enterprise with proxy concerns	WebSocket with fallback chain
Maximum reach, variable environments	Library like Socket.IO

What's Next:

Page Complete