Before HTTP
Before HTTP 1, the internet had many computer networks that couldn't easily communicate with each other. In the 1960s, the internet began as a way for government researchers to share information, but different computers on different networks couldn't "talk" to each other.
This changed when the Transfer Control Protocol/Internetwork Protocol (TCP/IP) was created in the early 1980s, allowing all networks to connect using a common language. The internet was mostly text-based, and each file or document was separate. The Web we know today didn't exist yet, and the early internet was mainly used by tech-savvy people.
The World Wide Web (WWW) was invented by Tim Berners-Lee in 1989. By 1990, the tools needed for a working Web, including the HyperText Transfer Protocol (HTTP), were built. This started a new era, making it easier to share information over the internet through a user-friendly and popular way.
HTTP 1: The Revolution Begins
In the early 1990s, a groundbreaking technology emerged: HTTP 1.0. The first version of HTTP.
It was like opening a door to a new world where data could travel across the internet in a standardized format. With HTTP 1.0, retrieving a simple text-based webpage from a server became as easy as clicking a link.
However, it had limitations:
Non-Persistent Connections: HTTP 1.0 needed a new TCP connection for every request-response cycle. This wasn't efficient because setting up a TCP connection needs a three-way handshake, which makes things slower. Also, every new connection uses more resources on both the client and server, which can be a problem when loading a webpage with lots of parts, like images and scripts.
Lack of Host Headers: The "Host" header wasn't in HTTP 1.0. This header is important for virtual hosting, letting many domain names use one IP address. Without the "Host" header, the server couldn't tell the difference between requests for different sites on the same server. This made web hosting less scalable and flexible.
No Pipelining: Pipelining is a method where a client can send several HTTP requests without waiting for each response. HTTP 1.0 didn't have this feature, so the client had to wait for the server to answer each request before sending the next one. This step-by-step process could make page loading slower, particularly for websites with lots of resources to load.
Limited Caching Mechanisms: HTTP 1.0 had limited ways to help with caching, which can cut down on requests for resources that haven't changed.
No Chunked Transfer Encoding: Without chunked transfer encoding, HTTP 1.0 needed the server to know the content's full size before sending it. This made it hard to send things like live video streams or real-time data feeds that were created on the spot.
HTTP 1.1: Addressing the Limitations of HTTP 1.0
Recognizing the challenges of HTTP 1.0, HTTP 1.1 was introduced.
Persistent Connections: HTTP 1.1 added the feature to use a connection for many requests, which lowers delays and makes things faster. This is done through the TCP three-way handshake, a method to start a TCP connection between a user and a server. By using the same connection, the handshake doesn't need to happen for every request, making things much faster.
Host Header: HTTP 1.1 lets many domains share the same IP address because it needs a "Host" header in each request. This makes it possible to use virtual hosting, where one server serves multiple websites. This feature is important for shared hosting situations, where many websites are on one server with just one IP address.
Chunked Transfer Encoding: This feature lets the server send a response to the client without knowing the content length beforehand. It's especially helpful for content that's created on the fly. The server can start sending the response before knowing the total size, which is good for streaming and content made in real-time.
Caching: HTTP 1.1 brought better caching support, making it possible to cache parts of content and use more flexible ways to check if it's still valid. This means clients can save partial responses and check with the server if they're still good, which cuts down on sending data the client already has.
However, as the web evolved into a more dynamic and interactive platform, HTTP 1.1 struggled to keep up. The need for a more robust protocol was clear.
HTTP 1.1 came with its own limitations that prompted the development of HTTP 2:
Head-of-Line Blocking: HTTP 1.1 could only handle one request-response pair at a time for each connection. This caused delays because each request had to wait for the previous one to finish.
Multiple TCP Connections: To fix the problem of only handling one request at a time, browsers opened many TCP connections to the server. This made things more complicated and increased overhead for both the client and server sides.
Uncompressed Headers: HTTP 1.1 sends headers in simple text without making them smaller, which causes extra data transfer. This happens especially when the same headers are sent many times during different requests.
No Server Push: HTTP 1.1 doesn't let the server send resources to the client ahead of time, even if it knows the client will need them. This causes more back-and-forth communication and slower response times.
Non-Prioritized Requests: HTTP 1.1 doesn't allow request prioritization, so less important resources might block more important ones.
Text-Based Protocols: As a text-based protocol, HTTP 1.1 is more likely to have parsing errors and is less efficient than binary protocols.
HTTP 2: A Faster, More Efficient Web
Enter HTTP 2 in 2015, a major leap forward. It was a game changer for the Web!
HTTP/2 introduced several new features and improvements compared to HTTP 1.1, which contributed to its significant advancement. These include:
Binary Framing Layer: HTTP/2 brought a new method for sending and receiving data between the client and server. Instead of using plain text like HTTP 1.1, HTTP/2 uses a binary format for its framing layer. This change made data transfer much faster and more efficient.
Multiplexing: HTTP/2 lets many messages mix together and then be put back in order at the other end. This means that several requests and responses can be sent at the same time over one TCP connection, removing the need for multiple connections between the client and server. This feature greatly increases the speed and efficiency of data transfer, especially for modern web pages that need lots of resources to load.
Header Compression: HTTP/2 brought in a new HPACK specification for header compression, which greatly cut down the overhead of sending and receiving headers. This better header compression lessened the data sent between the client and server, making data transfer faster and more efficient.
Server Push: HTTP/2 lets the server send resources to the client before the client asks for them. This feature cuts down on back-and-forth trips and delays, making data transfer faster and more efficient.
Stream Prioritization: HTTP/2 lets you prioritize streams, which means more important resources are sent faster. This feature makes web applications work better because critical resources get priority over less important ones.
However, this isn't the end!
HTTP 2 had limitations itself.
It uses TCP as the underlying transport layer network protocol, which isn't the most efficient transport layer:
Setup Handshake and Slow Start: It requires an initial setup process and starts transferring data slowly, gradually increasing speed to avoid overloading the network.
TIME_WAIT Delays and Port Exhaustion: After closing a connection, TCP waits before reusing the same port, which can lead to delays and a shortage of available ports.
Bandwidth and Latency Issues: When the combined effect of network bandwidth and delay increases, TCP can become inefficient and unstable.
The biggest problem was still Head-Of-Line Blocking for HTTP 2. Not quite the same as in HTTP 1.1. though.
Head Of Line Blocking for HTTP 2
In HTTP/1.1, head-of-line blocking occurs because each TCP connection can handle only one request at a time. If the first request is delayed (for example, waiting for resources), all other requests in the queue are delayed too. This is inefficient, especially when many requests use the same connection.
On the other hand, HTTP/2 uses multiplexing, allowing multiple requests and responses to be mixed over a single TCP connection. So, if one request is delayed, others can still move forward, reducing the effect of head-of-line blocking at the application level.
However, HTTP/2 doesn't completely get rid of head-of-line blocking since it still uses TCP. If a single TCP packet is lost, all streams in the HTTP/2 connection can be blocked until the packet is sent again.
This happens because TCP makes sure data packets are delivered reliably and in order. If a packet is lost during transmission, TCP notices the loss and won't deliver any following packets to the application until the missing packet is sent and received again.
Diagram of HTTP 2
HTTP 3: The Future is Now
HTTP 3, the latest iteration, introduces QUIC - a transport layer network protocol developed by Google. It addresses the shortcomings of HTTP 2 with improved security features and reduced connection establishment time.
HTTP/3 brings improvements to web communications, mainly by addressing the limitations of HTTP/2:
QUIC Transport Protocol: Unlike HTTP/2's reliance on TCP, HTTP/3 uses the QUIC protocol. QUIC is better at handling packet loss and reducing latency, making data transfers faster and more efficient.
Zero Round-Trip Time (0-RTT): HTTP/3 introduces 0-RTT, which allows clients to send requests immediately without waiting for a handshake process to complete. A "round trip" refers to the time it takes for a request to go from the client to the server and back. By eliminating this initial round trip, HTTP/3 reduces latency and speeds up connection times.
Mandatory Encryption: While HTTP/2 made encryption optional, HTTP/3 requires it for all connections. This ensures a higher level of security and privacy.
Enhanced Multiplexing: HTTP/3 improves upon the multiplexing capabilities of HTTP/2. It allows even more efficient simultaneous processing of multiple requests and responses over a single connection, enhancing speed and efficiency.
Conclusion: A Continuous Journey
The development of HTTP shows how the web keeps changing. It went from a basic way to share simple web pages to a complex system for dynamic, interactive experiences. HTTP has always changed to meet the needs of the time.
As we start using HTTP 3, it's fun to imagine what the future holds. The story of HTTP shows how people in technology never stop looking for new ideas.
