5. HTTPS Optimization: Balancing Security and Performance

5.1 Motivation for HTTPSing on CDN Important

Scenario Comparison:

Without HTTPS:
User accesses http://cdn.example.com/image.jpg
↓
Browser address bar shows "Not Secure"
↓
Some browsers/APPs directly block access
↓
SEO ranking drops

With HTTPS:
User accesses https://cdn.example.com/image.jpg
↓
Browser shows green lock icon
↓
HTTP/2 multiplexing takes effect
↓
Performance + security both improved

5.2 CDN HTTPS Configuration Essentials

Certificate Management

Solution	Description	Cost	Use Case
Cloud provider free cert	Provided by Alibaba Cloud/Tencent Cloud	Free	Single domain, quick start
Let's Encrypt	Community free certificate	Free	Automated deployment
Commercial DV/OV/EV cert	Symantec, GeoTrust, etc.	Hundreds to tens of thousands CNY/year	Enterprise, green bar needed
Wildcard certificate	*.example.com	Thousands CNY/year	Multiple subdomains

Practical Recommendations:

• Testing environments: Let's Encrypt or cloud provider free certificates
• Production environments: Wildcard certificate (convenient) or single-domain OV certificate (cost-effective)
• Watch certificate expiration dates; set up auto-renewal reminders

HTTPS Optimization Configuration

TLS Version Selection:

Recommended: TLS 1.2 and TLS 1.3 only
Compatibility: TLS 1.1 + TLS 1.2 + TLS 1.3 (for legacy browsers)

Cipher Suites:

Recommended: ECDHE key exchange + AES-GCM encryption
Disabled: DES, RC4, MD5, SHA1

OCSP Stapling:

Function: CDN node pre-fetches certificate revocation status
Effect: Reduces client verification time by 200-500ms
Recommendation: Always enable

TLS Session Resumption:

Session ID resumption: Client sends last Session ID, server resumes session
Session Ticket resumption: Server encrypts session state and sends to client, client sends it back next time
Effect: Avoids full TLS handshake, saves 1-RTT

5.3 HTTP/2 and HTTP/3 on CDN

HTTP/2 Multiplexing:

HTTP/1.1:
Request 1 (index.html) ────────────────→
Response 1 ←──────────────────────────────
Request 2 (style.css) ─────────────────→
Response 2 ←──────────────────────────────
Request 3 (script.js) ─────────────────→
Response 3 ←──────────────────────────────
(Serial, one finishes before the next)

HTTP/2:
Request 1 ──→
Request 2 ──→   Merged on one TCP connection, frames interleaved
Request 3 ──→
Response 1 ←──   Streamed back by priority
Response 2 ←──
Response 3 ←──
(Parallel, one connection multiplexed)

HTTP/2 Server Push:

Scenario: User requests index.html, which references style.css and script.js

Traditional approach:
1. User downloads index.html
2. Parsing discovers style.css and script.js are needed
3. Two more requests to fetch them

HTTP/2 Push:
1. User requests index.html
2. CDN node returns index.html while proactively pushing style.css and script.js
3. When the user parses the HTML, the resources are already in the cache

Note: Push cautiously—too much wastes bandwidth, too little has no effect

HTTP/3 (QUIC):

HTTP/2 problem: TCP-based, head-of-line blocking
→ One TCP packet lost, entire connection waits for retransmission

HTTP/3 solution: QUIC-based (reliable transport over UDP)
→ Each stream is independent; one stream blocked doesn't affect others
→ Connection migration: WiFi to 4G switch, connection doesn't drop
→ 0-RTT handshake: Fast connection establishment even on first visit

Current status: As of 2024, mainstream CDNs support HTTP/3; recommended to enable