HTTP1 vs HTTP2 vs HTTP3

Let's go back to 1996.

That's when HTTP1 was introduced. But before that, there was HTTP0.9. It was simple. It only sent HTML files. It only supported GET and had no headers or status codes.

+ HTTP1.0 added headers, status codes, and new methods that POST and HEAD. It was straightforward. The browser would ask for a web page to server with send it.

- Each request needed its own connection. This means a lot of back and forth. It wasn't very efficient. First, there's a TCP handshake. It's a three-way process to start a connection. Then for HTTPS, there's a TLS handshake for security. This all happens before any data is sent. With HTTP1, this happened for every resource, every image, CSS file, or JavaScript file.

In 1997, HTTP1.1 came out.

It fixed problems with HTTP1. It still used a lot today, even after 25 years.

+ HTTP1.1 introduced persistent connections. The connections stay open and let's tow to close. This meant no more closing after every request. No more multiple TCP handshakes. It got rid of the extra work of constantly opening and closing connections. + It also introduced pipelining. This lets clients send multiple requests over one TCP connection. They didn't have to wait for responses. For example, when a browser needs two images, it can request them one after the other. This made things faster. It reduced the wait time for each response. + Another key feature was chunked transfer encoding. Servers could send responses in smaller chunks. They didn't have to wait for the whole response to be ready. This may initial page rendering faster. It improved user experience, especially for large or dynamic content. + HTTP1.1 also brought better caching and conditional requests. It added headers like cache control and Etag. These help manage cached content and reduce unnecessary data transfers. Conditional requests using headers like "If-Modified-Sins", let clients request resources only if they changed. This saved bandwidth and improved performance. - But website school bigger and more complex. This show a big problem with HTTP1.1 had a line blocking. If the first request in the pipeline was delayed, all the others had to wait. Because of this and other issues, many browsers didn't use pipelining. Developers found ways around these limits. One was Domain Sharding. Websites would serve static access from subdomains. Each new subdomain got six more connections. Another trick was to make fewer requests by bundling access. Images would be combined using sprites. CSS and JavaScript files would be concatenated.

In 2015, HTTP2 arrived.

It was designed to fix HTTP1's performance problems. It brought major improvements.
+ HTTP2 introduced a binary framing layer. Unlike HTTP1's plain text messages, HTTP2 uses binary format. Messages are divided into smaller units called frames. These are sent over the TCP connection. The binary framing layer handles all this. + HTTP2 also brought full requests and response multiplexing. Clients and servers can break down HTTP messages into independent frames. These can be mixed during transmission and put back together on the other side. This fixed a head-aligned blocking problem from HTTP1.
+ Stream power utilization was another key HTTP2 feature. The order of loading access matters for web pages. Stream power utilization lets developers set the importance of requests. The browser can tell the server which assets a high power already. The server then sends more frames for these important requests.
+ HTTP2 also supports server push. HTTP2 allows multiple responses to clients request. A server can send extra resources, along with the requested HTML page, is like giving the client a resource before they even ask for it. + Lastly, HTTP2 introduced header compression. In HTTP1, only the main data was compressed. Headers were sent as plain text. HTTP2 uses HPAC to make headers smaller. HPAC compresses headers and remembers past headers. It uses this info to compress future headers even more. - But as web apps got more complex, and mobile internet became common, HTTP2 shows some limits. TCP's nature is handling of packet loss and head-aligned blocking caused slower page lows. This was especially true on high latency or lossy networks.

This led to HTTP3 standardized in 2022.

+ HTTP3 used Quake instead of TCP. Quake was developed by Google. It was built on UDP, a connectionless protocol. UDP doesn't need to set up a connection before sending data. Quake and HTTP3 have some big advantages. They reduce latency. They improve multiplexing without TCP Head-of-line Blocking. They handle packet loss better. They perform better on mobile networks with seamless connection changes. When a client connects to a server with HTTP3, he starts a quick handshake. Quake combines with TCP1.3 for security. The TLS handshake happens during the Quake Connection setup. This reduces overall latency. HTTP3 sets up connections faster than TCP. If the client and server have talked before, Quake can secure the connection in one round trip (1-RTT). Sometimes, it can do it in zero round trips (0-RTT). In 0-RTT, the client sends a request right away. The server process it without a full handshake. + HTTP3 also handles network changes well. If you switch from Wi-Fi to cellular on your phone, HTTP3 can keep the connection going. This is thanks to Quake's connection IDs. These don't depend on IP addresses.

As of 2023, HTTP1.1 is still widely used, especially for simple websites. HTTP2 has been adopted a lot. It handles over 60% of web requests according to some estimates. HTTP3 is still new beginning gram. Big companies like Google and Cloudflare are leading this adoption.

There's a journey through HTTP's evolution. We've seen how it changed from HTTP1 simple model to HTTP2's multiplexing and HTTP3's quick connections. The web's foundational protocols have adapted to our growing need for fast, reliable online experiences.