 |
When you think of the dizzying growth of the Internet, you tend to think of hardware innovations, browsers, search engines, or social networks. But behind every click, every image loaded, every page visited, there is a silent and fundamental protocol that has made it all possible: HTTP, the HyperText Transfer Protocol.
Born in the early 1990s as a simple mechanism for transferring hyperlinked text documents, HTTP has managed, with only one real substantial revision over two decades, to bear the full weight of the growth of the web. Its longest-lived version, HTTP/1.1, has resisted time and technological changes almost miraculously, remaining in use even during the advent of mobile browsing, when the first Nokia phones and WAP devices began to connect to the Internet.
In this article, we look back at the history of HTTP: from its birth to its extraordinary longevity, through the reasons that led to the introduction of HTTP/2 and HTTP/3 — modern versions that have reshaped the way the web communicates, without ever breaking with the past.
🎩 The Origins of HTTP: From CERN to the First Web
In 1989, Tim Berners-Lee, a researcher at CERN, proposed a system for sharing hypertext documents among scientists. The World Wide Web was born. The HTTP protocol, along with HTML and URLs, was one of the three pillars of the project.
The first operational version of HTTP, known as HTTP/0.9, was surprisingly simple: it only supported GET requests, did not use headers, and returned HTML content directly. There were no status codes, nor methods like POST or HEAD.
As the web expanded, the needs grew rapidly. In 1996, HTTP/1.0 was standardized, introducing many of the features that are now considered basic:
Status code (
200 OK,404 Not Found, etc.)Header HTTP (to define content type, length, encoding)
Support for methods like
POSTeHEADIntroduction of the concept of connection by request
HTTP/1.0 was a huge step forward, but it had a significant limitation: each HTTP request opened and closed a new TCP connection, a high cost in latency.
📱 HTTP/1.1: The Backbone of the Modern Web
In 1997, HTTP/1.1 arrived, initially standardized with RFC 2068 and then updated in 1999 with RFC 2616. It was much more than a simple revision: HTTP/1.1 represented a real turning point, taking the protocol from a basic tool to a robust and flexible infrastructure, suitable for supporting the rapid expansion of the Internet.
Why HTTP/1.1 Was Revolutionary
HTTP/1.1 introduced a number of key features that addressed major limitations of version 1.0:
Persistent (Keep-Alive) Connections: Instead of opening a connection for each request, HTTP/1.1 allowed the same TCP connection to be reused for multiple requests/responses, reducing latency.
Header
Host: allowed multiple websites to share the same IP address, enabling virtual hosting and the shared hosting boom.Advanced Caching: Through headers such as Cache-Control, ETag, and Last-Modified, HTTP/1.1 allowed for much more efficient resource management.
Compression: The use of encodings such as gzip allowed the transfer of textual content in a much lighter way, reducing bandwidth usage.
Pipeline management: introduced the ability to send multiple requests without waiting for the response of the previous one, although it was then little adopted due to implementation limitations in browsers.
A surprising resilience
HTTP/1.1 has remained the dominant standard of the Web for over twenty years. Despite drastic changes in the digital world – the growth of social networks, the explosion of streaming media, cloud computing – this version has continued to hold up without giving in.
And that's not all. When the first mobile devices with Internet access appeared in the early 2000s, such as the Nokia 60 series and other WAP terminals, HTTP/1.1 was still able to function perfectly. We are talking about devices with very little memory, limited CPUs and very slow networks. Yet, thanks to the lightness of the protocol and its scalability, it was possible to navigate the Web – even if in a simplified form – with acceptable performance.
HTTP/1.1 was the protocol of the desktop era, the advent of mobile and the beginning of the cloud era. It is still partly used today, even if progressively replaced by more recent versions.
🏃♂️➡️ HTTP/2: A Faster Web Without Changing the Rules
After nearly two decades of unchallenged dominance, HTTP/1.1 was starting to show its limits. Despite its optimizations, the protocol was not designed for the modern ecosystem of complex applications, web pages with dozens (or hundreds) of simultaneous requests, multimedia content, and an increasingly mobile user base.
In 2015, HTTP/2 was standardized (RFC 7540), the first real paradigm shift in the way HTTP was transported and managed — while keeping the basic communication model between client and server intact (same methods, headers, semantics).
Reasons for an update
The main problems to be solved were:
Head-of-Line Blocking: In HTTP/1.1, even with persistent connections, requests were stuck in a queue, causing slowdowns if the first request took too long.
Limited number of connections per domain: Browsers typically established 6 connections per domain to avoid TCP congestion, leading to complicated strategies (such as domain sharding).
Bandwidth overhead: The heavy use of repetitive, textual HTTP headers wasted bandwidth.
Key innovations in HTTP/2
HTTP/2 introduced radical changes at the transport layer, including:
Multiplexing: multiple requests and responses can travel simultaneously on the same TCP connection. This eliminates head-of-queue blocking and improves responsiveness.
Header compression (HPACK): significantly reduces message weight, especially in contexts with many similar requests.
Server Push: allows the server to send resources (like CSS or JS) ahead of time, before the client even requests them.
Binary Frames: HTTP/2 transmits data as streams of binary frames, rather than text, improving parsing speed and efficiency.
Impact on web development
With HTTP/1.1, developers were forced to combine JS, CSS, and image files into a single file to minimize the number of requests: heavy bundles, spritesheets, artificial concatenations.
HTTP/2 reversed this logic:
We have returned (finally) to modularity: many small and separate files, more maintainable, without penalizing performance.
End of domain sharding: no more "tricking" the browser into making multiple simultaneous requests.
Smoother user experience, especially on complex and interactive sites.
HTTP/2 has seen very rapid adoption, in part because it is backwards compatible: clients and servers that support it can dynamically negotiate it via TLS (with the ALPN protocol), without having to change application-side code.
🚀 HTTP/3: Speed, reliability and mobility with QUIC
While HTTP/2 has dramatically improved request handling efficiency, it has inherited a structural limitation: it still relies on the TCP protocol, which, while reliable, was not designed for the needs of the modern web, especially in mobile environments or with unstable networks.
In 2022, after years of experimentation by Google with the QUIC protocol, HTTP/3 was standardized (RFC 9114). Unlike its predecessors, HTTP/3 represents a revolution at the transport level, completely abandoning TCP in favor of a more modern and flexible alternative.
Why HTTP/3 was needed
The key issues to be solved were:
Head-of-Line Blocking at TCP level: Even with HTTP/2 multiplexing, if a TCP packet was lost, all ongoing requests on the same connection were blocked.
Slow connection setup: TCP + TLS handshake requires multiple round trips to establish a secure connection.
Poor resilience to network switching: for example, switching from Wi-Fi to mobile network results in the loss of TCP connection.
HTTP/3's Key Innovations
HTTP/3 is based on QUIC, a transport protocol developed by Google and then standardized by the IETF. Its main features are:
Based on UDP, not TCP.
Native and independent multiplexing: requests do not interfere with each other in the event of packet loss.
TLS 1.3 integrated into transport protocol: faster and more secure handshake.
Resilient connections: the connection can survive IP changes, especially useful when mobile.
Lower initial connection latency: the first load of a site can be significantly faster.
HTTP/3: Designed for a Mobile-First World
HTTP/3 does not change the semantics of HTTP: requests and responses remain the same. But it significantly improves the behavior of the Web in real-world conditions:
Faster connections, especially on mobile or unstable networks.
Less impact from packet loss or congestion.
Greater efficiency in content delivery via CDNs, which rapidly adopt HTTP/3 to deliver seamless experiences.
HTTP/3 adoption is growing: the main browsers (Chrome, Firefox, Edge, Safari) and many CDNs (Cloudflare, Google, Akamai) already support it. For the end user, the advantage is faster and more stable navigation, even when the connection is not perfect.
🔁 HTTP Version Comparison Table
| Version | Year | Trasport | Main features | Reasons for the update |
|---|---|---|---|---|
| HTTP/0.9 | 1991 | TCP | Only GET, no header | Simple HTML transport |
| HTTP/1.0 | 1996 | TCP | Status code, header, POST | Greater flexibility and interactivity |
| HTTP/1.1 | 1997 | TCP | Keep-Alive, caching, pipelining | Performance and shared hosting |
| HTTP/2 | 2015 | TCP | Multiplexing, HPACK, server push | Eliminate latency and crashes |
| HTTP/3 | 2022 | QUIC (UDP) | Native multiplexing, TLS 1.3 | Performance and resilience on mobile networks |
🌐 Browser Compatibility with HTTP
| Browser | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|
| Google Chrome | ✔️ | ✔️ (> v41) | ✔️ (> v87) |
| Mozilla Firefox | ✔️ | ✔️ (> v36) | ✔️ (> v88) |
| Microsoft Edge | ✔️ | ✔️ | ✔️ (> v87) |
| Safari (macOS) | ✔️ | ✔️ (> v9) | ✔️ (> v16.4) |
| Safari (iOS) | ✔️ | ✔️ (> v9.3) | ✔️ (> v16.4) |
| Opera | ✔️ | ✔️ (> v28) | ✔️ (> v74) |
Follow me #techelopment
Official site: www.techelopment.it
facebook: Techelopment
instagram: @techelopment
X: techelopment
Bluesky: @techelopment
telegram: @techelopment_channel
whatsapp: Techelopment
youtube: @techelopment
