How HTTP Evolved Over Time - HTTP1 vs HTTP2 vs HTTP3

What is HTTP?

HTTP, or Hypertext Transfer Protocol, is a way of transferring data over the internet between web browsers and servers. It's used for sending resources like images, web pages. HTTP uses a client-server model and relies on TCP. The process involves a web browser asking a web server for a resource, and the server responding with that resource and a message saying if the request worked or not.

Stateless:

HTTP is a stateless protocol, which means that each request and response is independent of any previous requests or responses, which makes it flexible but also means that extra tools like cookies and sessions are needed to keep track of things.

Methods:

To communicate between the client and server, HTTP employs a range of methods, such as GET, POST, PUT, DELETE, HEAD, OPTIONS, PATCH and others. These methods are utilized to request or submit data to the server and perform various resource-related operations.

Explanation of Different HTTP Methods:

• GET: retrieves a resource from the server
• POST: submits data to be processed by the server
• PUT: updates a resource on the server
• DELETE: removes a resource from the server
• HEAD: retrieves metadata about a resource
• OPTIONS: retrieves information about what methods and operations are supported by the server
• PATCH: partially updates a resource on the server.

Headers:

HTTP also uses headers to offer more details about the request and response, including content type, cache control, and authentication credentials, among others. These headers enhance communication between the client and server, as well as ensure the accurate transmission of data.

Evolution:

HTTP is constantly evolving, and new versions like HTTP/2 and HTTP/3 aim to make it faster, more secure, and more reliable. We'll discuss each of the versions briefly below.

HTTP1

In 1996, the first version of HTTP, HTTP/1, was published, which established the basic specifications for the HTTP protocol that we use today.

Drawback

HTTP/1 had a major drawback: for each request-response exchange between the client and the server, a new TCP connection had to be established. This meant that if a web page required multiple JavaScript or image files, the web browser needed to retrieve each file before the page could finish loading. To mitigate this, browsers could open multiple TCP connections to the server to retrieve data in parallel. However, this approach was resource-intensive and increased latency since TCP and TLS handshakes had to be completed before each request. Moreover, TCP requires a warm-up period before each connection to allow its algorithm to estimate how much data it can handle, resulting in slower data transmission.

HTTP1.1

In an attempt to solve these issues, HTTP 1.1 was introduced a few years later. It introduced the concept of keep-alive connections that allowed clients to reuse TCP connections and reduce the cost of setting up a new connection. However, this was not a complete solution. While multiple requests could share the same connection, they still had to be serialized, meaning that the client and server could only execute one request-response exchange at any given moment. As websites required more and more resources over time, browsers needed more concurrency when fetching and rendering web pages. However, HTTP 1.1 only allowed clients to perform one HTTP request-response exchange at a time, so the only way to achieve concurrency at the network level was to use multiple TCP connections. As a result, the benefits of keep-alive connections were largely lost, and while connections could still be reused to some extent, the issue remained unsolved.

HTTP2

HTTP/2, which was released more than a decade after HTTP 1.1, introduced multiplexing, allowing a client to request multiple files and download them all in parallel over a single TCP connection. However, this solution wasn't perfect, as a single request affected by packet loss could lead to all requests and responses being equally affected, due to TCP's lack of awareness of HTTP/2 multiplexing. TCP's job is to deliver the entire stream of bytes in the correct order from one endpoint to the other, so when a packet carrying some of those bytes is lost on the network path, it creates a gap in the stream that TCP needs to fill by resending the affected packet. This causes head-of-line blocking, where none of the successfully delivered bytes that follow the last one can be delivered to the application, even if they are not lost and belong to an independent HTTP request. In a high-loss packet environment, HTTP/1.1 performs better due to the multiple parallel TCP connections that the browser opens.

gRPC, a popular open-source remote procedure call (RPC) framework, uses HTTP/2 as its underlying protocol due to its support for multiplexing and improved performance over HTTP/1.1. If you want to learn more about gRPC give this article a look.

HTTP3

HTTP3 is a recently developed protocol that is designed to replace its predecessors and become the new standard for the web. It aims to provide faster, more reliable, and more secure communication. Despite still being under development, HTTP3 is already supported by all major browsers. The primary change in HTTP3 is the use of a new internet transport protocol called QUIC, which was initially developed by Google. QUIC introduces the concept of streams at the transport layer, which enables independent delivery of data packets. In this way, loss of data packets in one stream does not affect the others. QUIC encapsulates packets on top of UDP datagrams, which is a connectionless protocol and thus technically unreliable. However, QUIC identifies lost data and re-transfers the missing bytes to ensure seamless user experience. Since QUIC uses UDP, there is no need for a complex three-way handshake to initiate the first connection. The protocol includes initiating encryption and the exchange of keys into the initial handshake process, which takes only one round trip to establish a path for communication. Moreover, encryption and authentication are provided by default.

If your website hasn't already adopted HTTP 3 and your cloud provider supports it, now might be a good time to consider enabling it. If you want to learn more about HTTP3 or QUIC you can give this article a read.