You use it every day: HTTP. But have you ever taken a closer look at it? I got curious and decided to dive into it, specifically the differences between HTTP versions. This is what I found.
What is HTTP?
HTTP stands for HyperText Transfer Protocol and is used to transfer data over the web. When you type a URL in your browser - which from now on we'll call a 'client' - the client will send a request for a webpage to a server. This request is done using HTTP. This protocol is the language that both the client and the server use to communicate with each other.
Where is it used?
HTTP is the foundation for communicating on the World Wide Web. It makes it possible to do many things, like loading a webpage, sending an email, or posting on social media. This means HTTP is used everywhere. It is not only used in your browser but also on your phone, smartwatch, and smart TV; if you have a smart fridge, it'll be used there as well. Got a smart car? It's using HTTP. Are you smart? Then you're probably using it as well! Just kidding.
Either way, it's used in a lot of places. But did you know there are also different versions of the protocol? Let's find out what makes them different.
Why are there different versions?
Just as regular languages tend to evolve over time, so does HTTP. I will do as high-over a comparison as possible for my comparisons and only go into a little detail.
HTTP/0.9
The first version of HTTP (version 0.9) was released in 1991. It was pretty simple and only supported doing a GET request. This meant that you could get data but not send any data.
HTTP methods
A GET request defines what type of request the HTTP request is. GET is also referred to as an HTTP method. The GET method retrieves data from a server, which is used a lot on the World Wide Web. There are more HTTP methods, but we'll get to those later.
A request looked something like this:
GET /index.html
Headers
This version of HTTP did not allow for the use of headers. Headers are a way to send extra information to the server. For example, it can tell the server what kind of data you are sending or expecting to receive. Because HTTP/0.9 did not support headers, it was only possible to get an HTML page.
HTML
HTML stands for HyperText Markup Language. This language is used to create web pages. It describes the structure of a document.
HTTP/1.0
Version 1.0 of HTTP was released in 1996. It had quite a few improvements over the last version. It included more HTTP methods and supported adding headers, which made it possible to send more types of data.
A request looked something like this:
GET /index.html HTTP/1.0
Host: example.com
or
POST /index.html HTTP/1.0
Host: example.com
Content-Type: application/json
{
"name": "Jesse",
"age": 27
}
HTTP methods
The following HTTP methods were supported in version 1.0:
Headers
Allowing for headers made it possible to not only GET HTML pages but also other types of data. Combined with HTTP methods like POST, it also made it possible to send data to a server. For example, the combination of POST and a header like Content-Type: application/json together with a Content-Length header made it possible to send JSON data to a server.
Caching
With headers available, it became possible for servers to work together with the client to cache data. A server could let the client know how long it should store the data. In turn, the client could let the server know if it still had the data in its cache. This significantly improved how quick it was to browse the web.
Status codes
It's always possible that something might go wrong when you're sending an HTTP request. Maybe the server doesn't have the resource you're requesting of it, or perhaps you do not have the proper permissions to access it. In HTTP/0.9, there was no way for you to know if your request succeeded. With HTTP/1.0, this changed: it became possible to send a status code along with the response. It became possible to know if your request succeeded or not.
There were five different groups of status codes defined:
- 1xx: Informational
- 2xx: Success
- 3xx: Redirection
- 4xx: Client Error
- 5xx: Server Error
HTTP/1.1
It took only a short time after the release of HTTP/1.0 for HTTP/1.1 to be released. It was released in 1997, but the specification was updated many times after that. It is still the most used version of HTTP today. A bunch of information on this standard can be found in this document.
Persistent connections and lower latency
When using HTTP, you need to first make a connection to the server. Once the connection has been made, you can send your request. In HTTP/1.0, that connection was closed by default every time you made a request. This meant that if you wanted to ask one server for multiple resources, you had to start a new connection each time you wanted to do that. To make a connection, you need to do something called a 'handshake'. To do a handshake (and this is simplified), you ask the server if you can make a request; if it says yes, you can make your request. Doing this handshake takes time, and it meant that every GET request consisted of a handshake, approval for the handshake, and then the actual request. This took a lot of time and increased something we call 'latency', which is the time it takes for a request to be made and a response to be received.
Real life comparison:
This would have been the same as going to the bakery to buy a loaf of bread, a cake, and some white buns. You would ask the baker if you can do an order. They would say: yes, you can; what would you like? You would tell them: "I want a loaf of bread". They would get it for you, and you would pay, leave the store, and go through the entire process again to also get your cake and white buns. It would make more sense to say: "I'd like a loaf of bread, a cake, and some white buns," without having to leave the store in between.
Thankfully, in HTTP/1.1, the default behavior was to keep this connection open. This meant that you could make more than one request over the same connection. This made the web a lot faster.
Chunks
HTTP/1.1 also became cute and chonky, like a fluffed-up puppy or cat.
ahum
What I meant to say is that it became possible to send data with an unclear size. With previous versions of HTTP, you had to know how big the data that you were sending was. But it is only sometimes possible to know how big a file might be. So, 'chunked transfer encoding' was introduced. It was now possible to send chunks of data. Once all the data was sent, the server would let the client know that it was done sending data.
Host
Now, back in the day, one server would usually host one website. This meant that you first connected to the server, which was at one IP address, and then you would ask for a resource, like an HTML page. But as the World Wide Web grew, servers started hosting more websites. This meant that you'd also have to tell the server from which website you wanted to get your HTML page. This is where the Host header came in.
HTTP/2
In 2015, HTTP/2 was officially standardized and released by a team called the "Internet Engineering Task Force" (IETF). The goal of HTTP/2 was to support a growing web, including its increasing complexity. A big part of that was to improve performance.
Multiplexing
Remember those 'persistent connections'? Where you wouldn't have to create a new connection for each new request you wanted to make? Well, in HTTP/2, they took that a step further. They introduced something called 'multiplexing'. This meant that you could send multiple requests at the same time without having to wait for the response of the last request, kind of like asking both the baker and their coworker for different baked goods at the same time. This greatly improved performance.
Compressing headers
Headers are handy, but the more you use along with your request, the bigger it gets. With HTTP/2, it became possible to make headers smaller by compressing them.
Speaking binary
As mentioned before, HTTP is a protocol, and we can compare it to a language that both the client and the server know how to speak. But this language has always been human-readable, which is great for us but unnecessary for both the client and the server. These two already speak binary, so why not make HTTP speak binary as well? HTTP/2 introduced a binary protocol. This way, it was easier for the client and server to talk to each other.
Prioritization of requests
Some parts of a webpage are more important than others. For example, the HTML of a webpage is more important than the images on it. Or any critical CSS is more important than the CSS that styles the page. This is why HTTP/2 introduced the ability to prioritize requests. The client can now let the server know which resources are more important than others.
Security
While it is possible to use the security protocol TLS/SSL with HTTP/1.1, you do not have to. The team working on HTTP/2 HIGHLY recommends using it, helping to make the web more secure.
Pushing resources
HTTP/2 made it possible for a server to actually take the initiative and push resources to the client without the client actually asking for it. This is called 'server push'. It can be used to send resources that the client will need in the future without it knowing it needs them.
HTTP/3
The latest version HTTP/3 was published as a proposal in 2022. The big difference between HTTP/3 and HTTP/2 (and, thereby, HTTP1.1) is that the way that the client connects to the server is changed. This should lead to a faster web experience.
Transport protocol
HTTP has always used something called the Transmission Control Protocol (TCP) as its way to connect to a server. However, in HTTP/3, they introduced a different type of protocol called QUIC. This is a protocol that is built on top of UDP, which is a protocol that is similar to TCP, but it doesn't have to do a handshake before it can send data. This makes it faster to connect with.
QUIC should make things like the earlier mentioned multiplexing and prioritization of requests even faster. It is also supposed to handle any errors if something goes wrong during a request.
Security
While HTTP/2 does encourage the use of the security protocol called HTTPS, it does not require it. QUIC is built on top of UDP, which, by default, is not secure. This is why HTTP/3 generally requires using the HTTPS security protocol. QUIC does mention that it has built-in security features, but it is still recommended to use HTTPS.
Conclusion
Yes. This was a lot of information, of which I'm sure I've not mentioned or found some details that could be super important, but oh well. I did not know HTTP could be this interesting. It surprised me just as much as the time I started diving into hashing. I hope you learned something new as well! Have fun coding!
Top comments (0)