HTTP / HTTPS / HTTP2 / HTTP3 and Caching Strategy

0 0
tags: frontend-architecture-cultivation-path frontend-architecture http network performance

Introduction

Should a frontend architect understand HTTP? My answer is yes — not to read RFC 2616, but to build engineering intuition for “what actually happens during an HTTP request”. Three reasons:

  1. The ceiling of first-screen optimization is the network layer. No matter how well you optimize HTML / CSS / JS, you can’t beat TTFB; the gap between HTTP/3 and HTTP/1.1 on weak networks can be 300ms.
  2. Caching strategy determines second-visit speed. Cookie / Cache-Control / ETag / Service Worker mechanisms intertwine; configure one wrong and “works in dev, blows up in prod”.
  3. CDN / edge computing selection isn’t a gut call. Cloudflare / Fastly / Akamai differ significantly on protocol support; whether HTTP/3 needs ops prep or code rewrite depends on understanding the protocol stack.

This is post #4 of the Frontend Architecture Cultivation Path series. We skip RFC details (no explaining every header’s syntax) and use architecture diagrams, real numbers, and selection tables to make HTTP evolution, TLS handshake, HTTP/2 multiplexing, HTTP/3 QUIC, and browser caching concrete. The next post covers front-end security (XSS / CSRF / CSP / SRI).

1. HTTP Evolution: The Essential Change from 1.0 to 3

1.1 Evolution Timeline

Figure 1: HTTP protocol evolution timeline

1.2 HTTP/1.1’s Core Problem: Head-of-Line Blocking

HTTP/1.1 introduced Keep-Alive (connection reuse) and pipelining, but the actual benefit was far below theory. Reasons:

  1. Request-response must be strictly ordered — the client must send requests in order, receive responses in order. If request 1’s response is slow, requests 2–10 all wait.
  2. Connection count limit — browsers limit concurrent connections per domain (Chrome: 6); excess requests queue.
  3. Head-of-Line Blocking — TCP-level packet loss retransmits the entire window, all in-flight HTTP requests stall.

Production case: SF Express ERP’s homepage loads 12 JS chunks (vendor, polyfill, 4 business modules, routing, state management, monitoring, analytics, SDK) — under HTTP/1.1, needs 6 + 6 = 12 RTTs in two batches; single first-screen = 6 × RTT.

2. HTTP/2: Binary Framing and Multiplexing

HTTP/2 is the 2015 major protocol release, solving HTTP/1.1’s core problems.

2.1 Core Mechanism: Binary Framing

HTTP/2 breaks HTTP messages (requests / responses) into smaller binary frames, each tagged with a stream ID and type. Multiple streams can run simultaneously on the same TCP connection.

TCP connection ── stream 1 (main HTML)
                ├── stream 3 (CSS)
                ├── stream 5 (JS chunk 1)
                ├── stream 7 (JS chunk 2)
                └── stream 9 (image)

Benefits:

  • One TCP connection is enough (solves HTTP/1.1’s 6-connection limit)
  • Multiplexed, no HTTP-layer head-of-line blocking
  • Binary frames parse faster than text protocol

2.2 Header Compression: HPACK

HTTP/2 uses HPACK algorithm for header compression:

  • Client and server maintain a “header field table”
  • Repeated headers are replaced with index numbers (saves bytes)
  • Huffman coding compresses strings

Production data: a complete HTTP request header is about 800 bytes; HPACK compresses it to 30–50 bytes. On 4G weak networks, each request saves ≈ 50ms.

2.3 HTTP/2’s Hidden Pitfall: TCP-Layer Head-of-Line Blocking

HTTP/2 solved HTTP-layer head-of-line blocking but not TCP-layer head-of-line blocking. TCP is an in-order byte stream:

TCP window: [frame1 stream A] [frame2 stream B] [frame3 stream A]
                 ↓ if frame2 is lost
                 ↓ TCP retransmits
                 ↓ frame1 and frame3 also wait

Production case: trans-Pacific links have 1–3% packet loss; HTTP/2 can actually be slower than HTTP/1.1 in such scenarios — because one lost TCP packet stalls all streams in the connection. This is exactly the pain point HTTP/3 solves.

2.4 Server Push (Deprecated)

HTTP/2 introduced Server Push — server proactively pushes resources without client requesting. Chrome 107+ removed Server Push (official note) due to low cache hit rate and protocol complexity. Don’t use in production.

3. HTTP/3: Real Parallelism with QUIC

HTTP/3 is officially released in 2022 (IETF RFC 9114), using QUIC to replace TCP as the transport. Core breakthrough: reliable transport over UDP.

3.1 Why QUIC Uses UDP

TCP’s core problem: implemented in kernel space, protocol upgrades require OS updates (which take decades to roll out). QUIC moves transport-layer logic to user space (in the browser / application process), so protocol upgrades only need browser updates.

Figure 2: TCP vs QUIC protocol stack

3.2 What QUIC Solves That HTTP/2 Couldn’t

ProblemHTTP/2 (TCP)HTTP/3 (QUIC)
Head-of-line blockingTCP-level packet loss stalls all streamsEach stream independent, one lost doesn’t block others
Handshake delayTCP 3-way + TLS 3-way ≈ 2-3 RTT1-RTT handshake (QUIC has TLS 1.3 built in)
Connection migrationWiFi → 4G IP changes → connection resetConnection ID identifier, IP change doesn’t affect connection
Congestion controlKernel-level, inconsistent across platformsApplication-level, customizable (BBR / Cubic)

Production data: an overseas business moving from HTTP/1.1 to HTTP/3 saw first-screen drop from 4.5s to 2.8s (38% savings) on high-loss (5%) links.

3.3 HTTP/3 Deployment Status (2024)

BrowserSupported versionNotes
Chrome87+Enabled by default
Firefox88+Enabled by default
Safari14+Enabled by default
Edge87+Enabled by default

Server support: Cloudflare / Fastly / Nginx 1.25+ (with quiche library) / Caddy / Envoy / HAProxy 2.3+. Just configure certs and UDP 443.

CDN status:

  • Cloudflare HTTP/3 on by default
  • Fastly configurable
  • AWS CloudFront HTTP/3 supported (2023+)

SF Express ERP upgraded to Cloudflare + HTTP/3 → TTFB from 800ms to 80ms (the first step of the 4.2s→1.8s first-screen optimization).

4. TLS 1.3: HTTPS Doesn’t Have to Be Slow

4.1 TLS 1.2 vs 1.3 Handshake Comparison

Figure 3: TLS 1.2 vs TLS 1.3 handshake timing

Key improvements:

  • 1-RTT handshake (first connection) vs TLS 1.2’s 2-RTT
  • 0-RTT handshake (session resumption) — client sends encrypted data in the very first frame
  • Removed insecure cipher suites (RC4, SHA-1, DES)
  • Mandatory Perfect Forward Secrecy

4.2 OCSP Stapling: Eliminating Certificate Validation Latency

Traditional TLS validation requires the client to query OCSP (certificate revocation status), usually adding 1 RTT. OCSP Stapling lets the server pre-query OCSP and “staple” it into the TLS handshake — no extra client request.

Production config: Cloudflare enables OCSP Stapling by default; self-hosted Nginx uses ssl_stapling on; ssl_stapling_verify on;.

4.3 HSTS: Enforce HTTPS

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Architect must-add: once you’re on HTTPS, add HSTS to all responses. Production case: an admin system initially only enforced HTTPS on /api, but /static was still HTTP — a man-in-the-middle attack injected ads. Adding HSTS forces browser to use HTTPS, problem solved.

5. Browser Caching Strategy: Cache-Control / ETag / Service Worker

5.1 Cache Layers

Figure 4: 4-layer cache for browser requests

Matching priority: memory cache → Service Worker → HTTP cache → CDN cache → origin. Architect key point: each layer saves one RTT.

5.2 Cache-Control Directives Cheat Sheet

# Static assets (CSS / JS / images / fonts)
Cache-Control: public, max-age=31536000, immutable
# One year cache, immutable (hash-tagged assets)

# HTML main document
Cache-Control: no-cache, must-revalidate
# Validate with server every time (304 negotiation)

# Private data (user-related)
Cache-Control: private, no-store
# Don't cache anywhere

Production rules:

Resource typeRecommended Cache-Control
Hash-tagged JS / CSS (e.g. app.abc123.js)public, max-age=31536000, immutable
Plain HTMLno-cache, must-revalidate + ETag
API responses (user-related)private, no-store
Public API responsespublic, s-maxage=300, max-age=60
Images (immutable)public, max-age=31536000, immutable
Fontspublic, max-age=31536000, immutable

5.3 ETag and 304 Negotiation

ETag (Entity Tag) is a resource “fingerprint” the server generates for each response. Next request the client brings If-None-Match: <etag>, server compares:

  • Resource unchanged → return 304 Not Modified, no body
  • Resource changed → return 200 OK + new content

Production data: a 300KB JS bundle downloaded every time = 800ms. ETag hit returns 304 typically < 50ms. So hash bundles must come with ETag.

5.4 Service Worker Caching Strategy

// stale-while-revalidate: serve cache first, fetch update in background
self.addEventListener('fetch', (e) => {
  e.respondWith(
    caches.open('v1').then(async (cache) => {
      const cached = await cache.match(e.request);
      const fetched = fetch(e.request).then((res) => {
        cache.put(e.request, res.clone());
        return res;
      }).catch(() => cached);
      return cached || fetched;  // cache first, network updates in background
    }),
  );
});

stale-while-revalidate is Service Worker’s most common strategy: users see instant load (cache), background fetches new version (update), next visit gets the latest.

6. CDN and Edge Computing Selection

6.1 CDN’s Core Value

CDN’s core is pushing content to the edge node closest to the user:

No CDN:  user → Beijing origin = 200ms
With CDN: user → nearby edge node = 20ms

200ms savings on first-screen has huge impact on LCP.

6.2 Major CDN Comparison (2024)

CDNHTTP/3Edge computeMainland ChinaPrice
Cloudflare✅ defaultWorkers (JS)ICP requiredGenerous free tier
Fastly✅Compute@Edge (Rust/Wasm)ICP requiredMid-high
Akamai✅EdgeWorkersICP requiredEnterprise premium
AWS CloudFront✅Lambda@EdgeICP requiredPay-as-you-go
Alibaba Cloud DCDN✅EdgeRoutine (JS)✅China-cheap
Tencent Cloud ECDN✅EdgeOne✅China-cheap

Domestic business selection:

  • Mainland users: Alibaba DCDN / Tencent ECDN (ICP filing required)
  • Overseas users: Cloudflare (generous free tier + simple config + strong HTTP/3)
  • Hybrid: domestic + overseas dual CDN, DNS split

6.3 CDN Cache Strategy

Surrogate-Key mode (Cloudflare / Fastly support): tag each resource, let CDN support batch invalidation by tag:

# Response header
Cache-Tag: post-123, user-456, category-tech
# API for batch invalidation
POST /cache-tags/invalidate
{ "tags": ["post-123"] }

Production case: a news website’s homepage uses Cache-Tag: frontpage; when a new article is published, one call to /cache-tags/invalidate { "tags": ["frontpage"] } clears the homepage cache. 1000× faster than traditional “invalidate by URL”.

7. Pitfall Reminders (Senior Architects Please Read Carefully)

  1. Don’t blindly enable HTTP/2 Push. Chrome 107 removed Server Push, Firefox defaults off. Don’t use in production.
  2. Don’t confuse Cache-Control: no-cache with no-store. Former caches locally but validates every time; latter doesn’t cache at all. HTML uses no-cache + ETag, user data uses no-store.
  3. Don’t ignore HTTPS upgrade intermediate state. During HTTP → HTTPS migration, HTTPS resources in HTTP pages may be blocked by mixed content. Use HSTS preload + 301 full-site redirect.
  4. Don’t let CDN cache HTML. HTML is dynamically generated; CDN cache leads to users seeing stale versions. HTML uses no-cache, only do SSL termination and compression at the edge.
  5. Don’t ignore HTTP/3 UDP firewall issues. Some enterprise networks and old firewalls only allow TCP 443. Fallback strategy: HTTP/3 failure automatically falls back to HTTP/2 (QUIC handshake failure transparently handled by browser).

Summary

Seven key facts that thread the network protocol stack together:

  • HTTP/1.1: head-of-line blocking + connection count limit = modern front-end’s biggest optimization target.
  • HTTP/2: binary framing + multiplexing + HPACK, single connection multi-stream is the core.
  • HTTP/3 + QUIC: reliable transport over UDP, truly solves TCP-level head-of-line blocking.
  • TLS 1.3: 1-RTT handshake + 0-RTT resume, HTTPS no longer slows first-screen.
  • Caching strategy: Cache-Control + ETag + Service Worker 4-layer system.
  • CDN selection: Cloudflare (overseas) + Alibaba/Tencent (domestic), HTTP/3 is the default option.
  • TLS 1.3 + 0-RTT: HTTPS doesn’t have to be slow.

Next post: Front-end security — XSS / CSRF / CSP / SRI, covering the attack surface so you know how to write secure code.

5 Key Interview Question Tracks

This section maps one-to-one with the article. Q1 ships with a complete answer as a model; the other four are for you to think through — each one is followed by an AI assistant button for a one-click detailed answer.

Q1 (Answer): What core problem does HTTP/2 solve over HTTP/1.1? And what does HTTP/3 solve that HTTP/2 couldn’t?

A: HTTP/1.1 has three pain points: ① Connection count limit (browser allows 6 concurrent per domain); ② HTTP-layer head-of-line blocking (requests receive responses strictly in order); ③ Repeated header transmission (every request carries complete cookie / UA). HTTP/2 fixes all of these via binary framing + multiplexing + HPACK header compression — a single TCP connection runs multiple streams, headers use an indexed table for compression. HTTP/3 (QUIC) solves the TCP-layer head-of-line blocking that HTTP/2 couldn’t — QUIC rebuilds reliability over UDP, each stream is independent, losing one frame doesn’t block other streams. Plus 1-RTT handshake (vs HTTP/2 2-3 RTT) and connection migration (IP change doesn’t break the connection). Interview tip: explain why HTTP/2’s “HPACK state table” can’t be shared across connections.

Q2 (Think): How does TLS 1.3 optimize handshake latency compared to TLS 1.2? What are the security risks of 0-RTT mode?

Q3 (Think): What’s the core value of a CDN? How should a domestic + overseas hybrid business select CDN? Why is Surrogate-Key better than traditional URL cache invalidation?

Q4 (Think): What are the 4 layers of browser caching? Which scenarios is each suitable for? What are the trade-offs of stale-while-revalidate?

Q5 (Think): In production, how did you take a first-screen time from 4.2s to 1.8s? What specific changes did you make at the network layer?

💡 Each question has an AI assistant button — one click gets you a detailed answer.

References

🔗 Original Link Share to reach more people

Comments