The Evolution from ‘Slow’ to ‘Fast’: Understanding What HTTP/0.9 to HTTP/3 Solved

The clear wind over the river and the bright moon in the mountains, heard as sound and seen as color, taken without restriction and used without depletion.

HTTP, the protocol we use every day, seems simple but is actually a history of evolution spanning over 30 years, continuously battling “latency” and “inefficiency.” Each version number jump stems from answering a core question.

Today, let us traverse time and see how each generation of HTTP became a “problem solver.” This not only helps you consolidate your knowledge system but also allows you to understand the core driving forces behind technological evolution.

📜 HTTP/0.9: The Genesis

• • Year of Birth:1991
• • Core Problem:How to retrieve a simple hypertext document (HTML) from a server?

At the dawn of the Web, the demand was extremely simple: to retrieve a text file containing links. HTTP/0.9 was born for this purpose. It was so simple that it could hardly be called a formal protocol standard.

• • Solution:

1. 1. Headless Request:Requests contained only the method (<span>GET</span>) and document path, with no request headers.
2. 2. Single-Line Protocol:<span>GET /index.html</span> was a complete request.
3. 3. Only HTML Transmission:The server’s response contained only the HTML document itself, with no status codes or response headers. The connection was closed after transmission.

In summary: HTTP/0.9 solved the problem of “from nothing to something,” making it possible to request a remote hypertext document over the network.

🖼️ HTTP/1.0: The Dawn of Civilization

• • Year of Birth:1996 (RFC 1945)
• • Core Problem:The Web is no longer just text; how to transmit various content formats like images, forms, CSS, etc.? How to inform the client whether the request was successful or failed?

With the popularization of the concept of the “World Wide Web,” web pages began to become colorful. The limitations of HTTP/0.9, which could only transmit HTML, became apparent.

• • Solution:

1. 1. Introduction of Request/Response Headers:Introduced the header concept we know today, allowing clients and servers to pass metadata such as <span>Content-Type</span>, <span>User-Agent</span>, etc. This made it possible to transmit images, videos, and binary files.
2. 2. Introduction of Status Codes:Added status codes like <span>200 OK</span>, <span>404 Not Found</span>, <span>302 Redirect</span>, allowing clients to clearly know the result of the request.
3. 3. Added POST/HEAD Methods:In addition to <span>GET</span>, it also supported the <span>POST</span> method for submitting data to the server.

• Legacy Issues:

• • Connectionless:Each request required establishing a new TCP connection. Requesting a webpage containing 10 images required establishing 11 TCP connections (1 for HTML + 10 for images). The overhead of TCP’s three-way handshake and slow start was enormous, leading to extremely slow page loading.

In summary: HTTP/1.0 solved the problems of “multimedia” and “state management,” making web pages rich and colorful, but its performance was extremely poor.

🔗 HTTP/1.1: The Workhorse

• • Year of Birth:1999 (RFC 2616), still the most widely used version today.
• • Core Problem:How to solve the huge performance overhead caused by “establishing a connection for each request” in HTTP/1.0?

HTTP/1.1 is a milestone, with its design goal aimed at performance optimization.

• • Solution:

1. 1. Persistent Connections:By default, <span>Connection: keep-alive</span> is enabled, allowing multiple requests to reuse the same TCP connection, greatly reducing the overhead of TCP handshakes and slow starts.
2. 2. Pipelining:Allows clients to send multiple requests in succession before receiving the previous response. It’s like ordering all your dishes at once without waiting for one to finish before ordering the next.
3. 3. Host Request Header:Allows a server to host multiple websites with different domain names (virtual hosting).
4. 4. Richer Cache Control:Introduced more granular cache headers like <span>Cache-Control</span>, <span>ETag</span>, etc.

• Legacy Issues:

• • Head-of-Line Blocking (HOL Blocking):This is the Achilles’ heel of HTTP/1.1. Although pipelining allows multiple requests to be sent at once, the server must return responses in order. If the first request is very time-consuming (like a large file), all subsequent requests (even small icons) must wait in line. It’s like ordering dishes; even if all are ordered, if the first one is stuck in the kitchen, none of the others can be served.

In summary: HTTP/1.1 solved the connection overhead problem through persistent connections, becoming the mainstay for nearly 20 years, but its head-of-line blocking issue laid the groundwork for the birth of the next generation protocol.

✈️ HTTP/2: The Efficiency Revolution

• • Year of Birth:2015 (RFC 7540)
• • Core Problem:How to solve the head-of-line blocking problem in HTTP/1.1 and further squeeze network performance?

As web applications became more complex and front-end resources increased, the HOL Blocking problem became increasingly severe. HTTP/2 fundamentally changed the way data is transmitted.

• • Solution:

1. 1. Binary Framing:All transmitted information is divided into smaller messages and frames, encoded in binary format. This is the foundation for subsequent optimizations.
2. 2. Multiplexing:On a shared TCP connection, clients and servers can simultaneously and independently send and receive multiple requests and responses (distinguished by Stream ID). This completely solves application-layer head-of-line blocking. It’s like a restaurant upgrading to multiple windows from the kitchen, serving you different dishes simultaneously without interference.
3. 3. Header Compression (HPACK):Since multiple requests often have many duplicate fields in their headers, the HPACK algorithm can greatly compress header sizes, reducing transmission overhead.
4. 4. Server Push:The server can proactively push resources (like CSS, JS) that the client may need before the client requests them.

• Legacy Issues:

• • TCP Layer Head-of-Line Blocking:Although HTTP/2 solved application-layer HOL Blocking, it is still based on TCP. TCP is a reliable protocol that requires packets to arrive in order. If one TCP packet is lost, all streams on the entire connection must wait for that packet to be retransmitted, leading to new HOL Blocking, just shifted from the HTTP layer to the TCP layer.

In summary: HTTP/2 solved application-layer head-of-line blocking through multiplexing, bringing significant performance improvements, but it is still limited by the “ceiling” of the TCP protocol.

🚀 HTTP/3: Breaking Dimensions

• • Year of Birth:2022 (RFC 9114)
• • Core Problem:How to completely break free from the constraints of TCP head-of-line blocking and achieve better performance in weak network environments?

HTTP/3 made the boldest decision:abandoning TCP and adopting a new protocol based on UDP—QUIC (Quick UDP Internet Connections).

• • Solution:

1. 1. Based on QUIC Protocol:QUIC itself implements connection, multiplexing, congestion control, and reliability guarantees. Because it is based on UDP, it has no order dependencies like TCP.
2. 2. Completely Solves Head-of-Line Blocking:QUIC’s multiplexing is true end-to-end multiplexing. Packet loss in one stream does not affect the data transmission of other streams. It’s like a restaurant with multiple independent doors; if a waiter falls in front of one door, other waiters can enter and exit from other doors without interference.
3. 3. Faster Connection Establishment:QUIC combines TCP’s three-way handshake and TLS’s encryption handshake, reducing the connection establishment RTT from 2-3 times to 1 time, or even 0 RTT (for existing connections).
4. 4. Connection Migration:When your network environment changes (like switching from Wi-Fi to 4G), TCP connections are interrupted. QUIC uses connection IDs to identify connections instead of the IP+port quadruple, allowing seamless migration of connections, maintaining calls or downloads without interruption.

In summary: HTTP/3 embraces QUIC, fundamentally solving the TCP head-of-line blocking problem and optimizing connection establishment and network switching experiences, making it a protocol designed for the mobile internet and future networks.

✨ Summary: The Unceasing Evolution

Looking back at the history of HTTP development, we can see a clear main line:

Simple Text -> Multimedia Content -> Performance Optimization -> Efficiency Revolution -> Underlying Reconstruction

Each evolution aims to make data transmission faster, more efficient, and more reliable to adapt to increasingly complex network applications. Understanding this history not only helps us better make technology choices and performance tuning but also allows us to deeply appreciate that all great technologies stem from insights into real problems and relentless pursuit.

This is a comparison table of the evolution of various HTTP versions organized based on the above content, aimed at helping you quickly review and compare.

HTTP Version	Core Problem Solved	Key Features / Solutions	Main Limitations
HTTP/0.9	From Nothing to Something: Retrieve a single HTML document remotely.	– Only <span>GET</span> method– No request/response headers– Can only transmit HTML	Extremely limited functionality, unable to transmit multimedia content or state information.
HTTP/1.0	Support Multimedia: Transmit images, videos, and various types of files, and inform request status.	– Introduced Request/Response Headers (like <span>Content-Type</span>)– Introduced Status Codes (like <span>200</span>, <span>404</span>)– Added <span>POST</span> and other methods	Low Performance: Each resource request requires establishing a new TCP connection, leading to huge overhead.
HTTP/1.1	Performance Improvement: Solve the performance overhead problem of frequently establishing connections in version 1.0.	– Persistent Connections (<span>Keep-Alive</span>)– Pipelining– <span>Host</span> request header supports virtual hosting– More granular cache control	Application Layer Head-of-Line Blocking (HOL Blocking): Subsequent requests must wait when the previous request is blocked.
HTTP/2	Efficiency Revolution: Solve the head-of-line blocking problem in version 1.1 and significantly improve transmission efficiency.	– Binary Framing– Multiplexing– Header Compression (HPACK)– Server Push	TCP Layer Head-of-Line Blocking: Packet loss at the TCP level still blocks all streams on the entire connection.
HTTP/3	Underlying Reconstruction: Completely solve TCP head-of-line blocking and optimize weak network and network switching experiences.	– Based on QUIC protocol (running on top of UDP)– True multiplexing, no head-of-line blocking– 0-RTT/1-RTT fast connection establishment– Connection Migration	Newer, comprehensive support and popularization of ecosystem and network intermediaries (firewalls, etc.) will take time.

Finally, here’s a thought-provoking question for all the experts:What challenges do you think the popularization of HTTP/3 will face (such as firewall and network device support)? Or what new problems do you think the next generation HTTP/4 might aim to solve?

Feel free to share your thoughts in the comments. If this article helped you build a clear knowledge system, don’t hesitate to click “Looking” and share it with more colleagues.