HTTP Protocol Evolution: 1.0 to HTTP/3
May 1996 to June 2022NetworkingStandard publishedDate precision, monthEvidence grade, primary5 primary sources
Drivers:
Web page complexity grew from kilobytes to megabytes. Mobile networks exposed latency issues. Security breaches drove HTTPS adoption. Each HTTP version addressed contemporary bottlenecks.
HTTP is the language your browser uses to request web pages. Like human languages, it has evolved over time. Each new version makes websites load faster and more securely. HTTP/2 lets your browser request many things at once; HTTP/3 works better on unreliable mobile connections.
HTTP Protocol Evolution: 1.0 to HTTP/3 event plate
Structured atlas record showing date, domain, evidence grade, source count, and predecessor and successor links.
Forecasts and counterfactuals stay labelled as opinion in the event data. Source: Computer History Museum.
Before
The original HTTP/0.9 was extremely simple, supporting only GET requests for HTML. As the Web grew, limitations became apparent: no persistent connections (new TCP connection for each request), no content negotiation, no caching headers, and no security.
What changed
HTTP evolved through multiple versions: HTTP/1.0 (1996) added headers, methods, and status codes; HTTP/1.1 (1999) added persistent connections and chunked transfer; HTTP/2 (2015) added multiplexing and header compression; HTTP/3 (2022) moved to QUIC, eliminating TCP head-of-line blocking.
How it happened
RFC 1945 formalised HTTP/1.0 in 1996. RFC 2616 (HTTP/1.1) addressed performance with persistent connections. Google's SPDY research influenced HTTP/2 (RFC 7540). Cloudflare and Google championed QUIC, leading to HTTP/3 (RFC 9114). Each version maintained backward compatibility while addressing specific performance bottlenecks.
Outcomes
- Enabled modern web applications with rich interactivity
- Reduced page load times through multiplexing and compression
- HTTPS became the default, securing web traffic
- Mobile web performance improved significantly
Limitations
- Legacy systems still rely on HTTP/1.1
- HTTP/2 push feature saw limited adoption
- QUIC requires UDP, which some networks block
- Backward compatibility adds protocol complexity
Lessons learnt
- Incremental improvements sustain long-lived protocols
- Performance optimisation drives adoption
- Security should be default, not optional
- Industry collaboration (browsers, CDNs) accelerates standards
Stakeholders and artefacts
Organisations
- IETFstandards_bodyHTTP RFC standardisation
- GooglevendorSPDY and QUIC development
- W3Cstandards_bodyWeb standards coordination
- CloudflarevendorQUIC deployment and advocacy
Individuals
- Roy FieldingCo-author, UC IrvineCo-authored HTTP/1.0 and HTTP/1.1 RFCs, created REST
- Tim Berners-LeeCo-author, W3COriginal HTTP design, HTTP/1.0 RFC co-author
- Mike BelsheCo-author, GoogleLed SPDY development, HTTP/2 RFC co-author
Artefacts
- HTTP/1.1protocolHTTP with persistent connections and chunked transfer
- HTTP/2protocolBinary protocol with multiplexing and header compression
- HTTP/3protocolHTTP over QUIC, eliminating head-of-line blocking
- HTTPSprotocolHTTP secured with TLS encryption
Key terms
Causality
Preceded by: World Wide Web Invented.
On this course
Read in the path How the Internet Works.