CDN TCP Optimization: Tuning the Transport Layer

July 03, 2026 · Alex Petrov · 4 min read

TCP at the CDN Edge

Despite HTTP/3's move to QUIC, TCP still carries the majority of CDN traffic (via HTTP/1.1 and HTTP/2). CDN edge servers are tuned far beyond default OS TCP settings, squeezing maximum throughput and minimum latency from every connection.

Figure 1: CDN Protocol Stack — Layered network architecture

TCP Congestion Control

Congestion control algorithms determine how fast TCP sends data. The algorithm choice affects how quickly connections reach full speed: For foundational context, read DNS Resolution in CDN: How Users Reach the Nearest Edge — FlyFish NWA.

Algorithm	Behavior	CDN Use
CUBIC	Aggressive ramp-up after loss	Linux default, widely used
BBR	Estimates bandwidth and RTT, paces sending	Used by Google/Cloudflare, better for high-latency links
BBRv2	Improved fairness over BBRv1	Emerging standard for CDNs

BBR is particularly effective for CDNs because it performs well on high-bandwidth, high-latency paths (like edge server to distant user). CUBIC underperforms on these paths because it's loss-based — it throttles unnecessarily on links with random loss.

Performance Comparison: Edge vs Origin Processing
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

Initial Congestion Window (IW)

The initial congestion window determines how much data TCP sends before receiving the first ACK. Default: 10 segments (14.6 KB). CDNs may increase this to 20-30 segments for faster start.

# Impact on first response:
IW=10: First flight delivers ~14 KB (enough for small HTML)
IW=30: First flight delivers ~44 KB (enough for most pages + critical CSS)

The trade-off: larger IW risks overwhelming slow or congested links.

TCP Fast Open (TFO)

TCP Fast Open sends data in the SYN packet, saving one RTT on connection establishment:

Figure 2: Protocol Handshake Flow — Connection establishment sequence

Standard TCP: SYN → SYN-ACK → ACK + data (1 RTT before data)
TCP Fast Open: SYN + data → SYN-ACK + data (0 RTT for repeat connections)

CDN edge servers enable TFO for returning clients who have a cached TFO cookie. This eliminates one RTT for repeat visitors.

Connection Pooling

CDN edge servers maintain pools of persistent connections to origin servers. Benefits:

No TCP handshake overhead for each origin request
No TLS handshake overhead (connections are already encrypted)
Warmed-up congestion windows (connections already at optimal speed)

Pool sizing matters: too few connections limits throughput; too many overwhelms the origin.

Kernel-Level Optimizations

CDN edge servers use custom kernel configurations:

Increased socket buffers — net.core.rmem_max and wmem_max set to 16+ MB for high-bandwidth connections
SYN cookie protection — net.ipv4.tcp_syncookies=1 for SYN flood resilience
Connection tracking tuning — Increased nf_conntrack_max for millions of concurrent connections
TIME_WAIT reuse — net.ipv4.tcp_tw_reuse=1 to quickly recycle sockets

TLS Optimization

TLS processing is the most CPU-intensive operation on edge servers:

Hardware TLS offload — NICs with built-in TLS engines (kernel TLS offload)
Session tickets — Avoid full TLS handshake for returning clients
OCSP stapling — Include certificate status in TLS handshake (avoids separate OCSP lookup)
Certificate compression — Compress certificates in the TLS handshake (saves 3-5 KB)

See SSL/TLS configuration for full details.