HTTP Protocol: From 0.9 to HTTP/3

The HTTP protocol (Hypertext Transfer Protocol) is the communication standard that powers the World Wide Web — the language that browsers and servers use to exchange web pages, images, APIs, and every other piece of content online. From its humble beginnings as a one-line protocol created by Tim Berners-Lee in 1991, HTTP has evolved through five major versions, each addressing fundamental performance and security limitations. Understanding HTTP's evolution is critical for CDN optimization because every version change has reshaped how content is delivered at the edge.

How Did HTTP Begin?

In 1989, Tim Berners-Lee, a British computer scientist working at CERN (the European Organization for Nuclear Research), proposed a system for sharing research documents across the internet. His proposal included three innovations that defined the web:

• HTML: A markup language for structuring documents with hyperlinks
• URLs: A uniform addressing system for locating resources
• HTTP: A protocol for transferring hypertext documents between client and server

The first version, HTTP/0.9 (1991), was astonishingly simple. It supported only a single method — GET — and the entire protocol exchange looked like this:

GET /index.html
(server returns the HTML document and closes the connection)

No headers, no status codes, no content types. Each request opened a new TCP connection, received the response, and the connection closed. This simplicity was deliberate: Berners-Lee optimized for adoption, not performance.

What Changed in HTTP/1.0 and HTTP/1.1?

HTTP/1.0 (1996, RFC 1945) added the features we consider fundamental today:

• HTTP headers (Content-Type, Content-Length, User-Agent)
• Status codes (200 OK, 404 Not Found, 500 Server Error)
• Multiple HTTP methods (POST, HEAD, PUT, DELETE)
• Content negotiation (Accept, Accept-Language headers)

But HTTP/1.0 retained a critical inefficiency: each request-response required its own TCP connection. Loading a web page with 10 images meant 11 separate TCP connections (1 for HTML + 10 for images), each with its own handshake overhead.

HTTP/1.1 (1997, RFC 2068, updated in RFC 2616) fixed this with persistent connections (keep-alive) — a single TCP connection could carry multiple request-response pairs sequentially. It also introduced:

• Chunked transfer encoding: Servers could start sending a response before knowing its total size
• Host header (required): Enabled virtual hosting — multiple websites on a single IP address
• Pipelining: Clients could send multiple requests without waiting for responses (though this was rarely used in practice due to head-of-line blocking)
• Cache-Control headers: Fine-grained control over caching behavior (max-age, no-cache, no-store, must-revalidate)

HTTP/1.1 was remarkably durable. Despite being standardized in 1997, it remained the dominant protocol until 2015 — an 18-year reign during which the web transformed from simple text pages to rich, interactive applications.

What Made HTTP/2 a Game-Changer?

HTTP/2 (2015, RFC 7540) was the most significant upgrade in HTTP's history, born from Google's experimental SPDY protocol. While HTTP/1.1 was a text-based protocol, HTTP/2 introduced a binary framing layer that fundamentally changed how data flows between client and server:

• Multiplexing: Multiple requests and responses travel simultaneously over a single TCP connection. No more head-of-line blocking where a slow response delays all subsequent requests. A page with 100 resources can load them all concurrently over one connection, instead of needing 6-8 parallel connections as in HTTP/1.1.
• Header Compression (HPACK): HTTP headers (cookies, user-agent, accept headers) often repeat identically across requests. HPACK compresses these headers by maintaining a shared dictionary between client and server, reducing header overhead by 85-95%.
• Stream Prioritization: Clients can assign priorities to different resources, ensuring that critical assets (CSS, fonts) load before lower-priority ones (analytics scripts, below-fold images).
• Server Push: Servers can proactively send resources before the client requests them. When a server sends an HTML page, it can simultaneously push the CSS and JavaScript files it knows the client will need.

CDN providers were among the first to deploy HTTP/2 at scale, often bridging HTTP/2 connections with clients while using HTTP/1.1 to origin servers. This meant websites could benefit from HTTP/2 performance without modifying their origin infrastructure — the CDN handled the protocol translation transparently.

How Does HTTP/3 with QUIC Improve Performance?

HTTP/3 (2022, RFC 9114) represents a radical departure: it replaces TCP with QUIC as the transport protocol. QUIC (Quick UDP Internet Connections) was developed by Google engineer Jim Roskind starting in 2012 and standardized by the IETF in 2021.

Key improvements over HTTP/2:

• No TCP Head-of-Line Blocking: In HTTP/2, all streams share one TCP connection. If a single TCP packet is lost, ALL streams must wait for its retransmission — even streams whose data arrived completely. QUIC runs each HTTP stream over an independent QUIC stream, so packet loss on one stream doesn't affect others.
• Faster Connections (0-RTT): QUIC integrates TLS 1.3 into its handshake. New connections require just 1 RTT (vs. 2-3 RTT for TCP + TLS 1.3). Repeat connections can send data in 0 RTT — the first packet carries both the handshake resumption and application data. TLS 1.3 is mandatory in QUIC, providing encryption by default.
• Connection Migration: QUIC connections are identified by connection IDs, not IP addresses. If a user's phone switches from Wi-Fi to cellular (changing IP address), the QUIC connection continues seamlessly — no new handshake needed. This is transformative for mobile users.

CDN providers have aggressively adopted HTTP/3. As of 2025, Cloudflare, Fastly, and Akamai serve HTTP/3 on the majority of their edge traffic. The performance gains are most pronounced on mobile networks with higher latency and packet loss.

How Do CDN Cache-Control Headers Work?

HTTP headers are the primary mechanism for controlling CDN caching behavior. The most important headers include:

Deep understanding of these headers is essential for effective CDN configuration. Our Cache-Control headers deep dive covers advanced patterns including stale-if-error, surrogate headers, and CDN-specific extensions.

What Is the Performance Difference Between HTTP Versions?