CDN and WebSockets: Real-Time Content Delivery
WebSockets and CDN
WebSockets provide persistent, bidirectional connections between client and server. Traditional CDNs are built for request-response patterns (HTTP), not persistent connections. However, modern CDNs have added WebSocket support to serve real-time applications.
CDN WebSocket Support
| Provider | WebSocket Support | Notes |
|---|---|---|
| Cloudflare | Yes (all plans) | Free WebSocket proxying, no extra cost |
| CloudFront | Yes | Supported in distributions, origin must support |
| Fastly | Yes | Via connection upgrades in VCL |
| Akamai | Yes | WebSocket acceleration available |
How CDN Proxies WebSockets
- Client sends HTTP request with
Upgrade: websocketheader - CDN edge server forwards the upgrade request to origin
- Origin accepts the upgrade (101 Switching Protocols)
- CDN maintains the persistent connection, proxying frames bidirectionally
- CDN applies: TLS termination, DDoS protection, rate limiting, and connection monitoring
Challenges
No Caching
WebSocket messages are dynamic and bidirectional — they cannot be cached. Every message must traverse: client → CDN edge → origin. The CDN provides connection optimization but not the primary CDN benefit (caching).
| Metric | Edge Processing | Origin Processing | Improvement |
|---|---|---|---|
| Latency (p50) | 8–15 ms | 120–300 ms | 15–20x faster |
| Cache Hit Ratio | 85–95% | N/A | Reduces origin load |
| TLS Handshake | 1–5 ms (nearby PoP) | 50–150 ms | 10–30x faster |
| Bandwidth Cost | $0.01–0.04/GB | $0.05–0.12/GB | 3–5x cheaper |
| Availability | 99.99% (multi-PoP) | 99.9% (single DC) | 10x fewer outages |
Connection Limits
WebSocket connections are persistent, consuming resources at every hop. At scale (millions of connections), consider:
- Connection limits per IP at the CDN edge
- Origin server capacity for persistent connections
- CDN pricing for WebSocket connections (some charge per connection-minute)
Timeouts
CDNs may timeout idle WebSocket connections (typically 60-300 seconds). Applications should implement heartbeat/ping-pong to keep connections alive.
Real-Time Application Patterns
Server-Sent Events (SSE)
For server-to-client only updates, SSE is simpler than WebSockets and works better with CDN caching:
- Uses standard HTTP (no upgrade)
- CDN can apply standard HTTP optimizations
- Automatic reconnection built into browser API
- Better for: notifications, live feeds, real-time dashboards
Long Polling
HTTP long polling works with all CDNs (standard HTTP requests). The CDN caches the polling response for a short TTL, reducing origin load when many clients poll simultaneously.
Edge-Based Pub/Sub
Some CDNs offer built-in pub/sub at the edge:
- Cloudflare Durable Objects — Stateful WebSocket servers at the edge
- Cloudflare Pub/Sub — MQTT broker at the edge (beta)
- Fastly Fanout — Real-time message delivery via edge
These edge compute solutions eliminate origin round-trips for real-time messaging.
When to Use CDN for WebSockets
Use CDN WebSocket proxying when: you need DDoS protection for WebSocket endpoints, you want TLS termination at the edge, your WebSocket server is behind the CDN anyway, or you want unified monitoring across HTTP and WebSocket traffic.