Transcript from the "Evolution of HTTP" Lesson
>> So, both the HTTP request and the HTTP response both have a header and a body. That for the request, the initial request the body is typically empty. So the header is text that the browser is sending to the server, saying, hey, I'm Chrome, I want that document, I accept PNG files, JPEG files.
[00:00:26] So it's a lot of information that the browser is sending to the server. And when the server is responding, there is a header. In that header, for example, the server adds the status code such as 404, 500, 200. Saying that, yeah, I have the file you requested, I don't have it, or I have an error, and the body, that is the actual data that you requested, okay?
[00:00:52] When you're in the network layer within Chrome, you can click on each request and actually see the headers. So if we go to the headers we have, let me increase the font size a little bit for you, and we have their response headers and the request headers. So this is going right now to request the HTML.
[00:01:19] All these strings are sent through the uplink to the server, and then the server responds with that information apart from the HTML. That's how that works. Just have that in mind for now. Okay, so HTTP has several versions. I'm not going to even mention HTTP 1.0 because it's been not deprecated, but it's not in the wild, and it hasn't been in the wild for probably 15 years.
[00:01:53] So HTTP 1.1, it's still 15% or 20% of the market share. In fact, how can we know the percentage of HTTP based network communications, HTTP 1.1, 2 or even 3? One resource of information is a website known as HTTP Archive. I'm not sure if you've heard about HTTP Archive.
[00:02:23] Have you heard about archive.org, that's the Internet Archive? Well, based on the Internet Archive, it's actually saving resources, the HTML, CSS of websites. So you can see here how Google was like 20 years ago, okay? So you can actually see how Google was, you can see the website, okay?
[00:02:47] But the Internet Archive is not saving the HTTP headers or performance data, okay? So that was the homepage, I remember that one. Well, the logo is not there for some reason. There it is. I used that version of Google, by the way. But it's just the contents of the file.
[00:03:09] Well, HTTP Archive, it's actually saving not the file but all the headers, all the information that is useful for, for example, web performance, or for analysis. So here, for example, we can get reports about the loading speeds of websites. That's how we know how performance is doing over time, generally, on the web.
[00:03:36] There are a lot of reports here, from here, we can also check for example, how many, I think it's here, State of the Web? Yeah, how many requests do we have in HTTP/2? So this is how it's getting better over time. But we are right now on around 68% of the web is in HTTP/2, okay?
[00:04:00] And I will explain what that is in a minute. HTTP/3 is 20%, and there's still some network connections on 1.1. So on 1.1, the biggest problem, that is not the problem today anymore because we don't have so many connections on this version, we have one request per TCP connection.
[00:04:20] Which means that if I call you, I can only request you one file over that call. So if I wanna download in parallel more files, I wanna download PNG file, CSS file, I need to make different calls. I need to have four phone numbers, eight phone numbers, eight phone devices, I'm sorry, and then call you eight times.
[00:04:42] I need to open four TCP connections, okay, which is kind of a problem. It was a problem at the time to download several resources in parallel. This version accepted GZIP. I'm not sure if you know this, but when you're browsing the web, if everything is set up correctly, you're downloading ZIP files, at least for the HTML, the CSS, and the text-based files.
[00:05:10] Everything is zipped, so then the transfer part is smaller. HTTP/2 altered performance from scratch. HTTP/2 came from an experimental protocol created by Google with the name SPDY. And that became the standard then that was created with performance from scratch. And here was the moment where we realized that we have to switch to HTTPS.
[00:05:38] Because if not, we cannot change the protocol safely. HTTP/2 added header compression. So those headers that I mentioned before are compressed as well, not with GZIP, but different algorithm. But on HTTP 1.1, they were not compressed. And the space that headers consume is typically around 1K. So you have 1K for the request and 1K for the response, even if it's an empty response.
[00:06:08] So, you have 1.5 to 2 kilobytes, per request, wasted just in metadata, not in the real data. Well, HTTP/2 is compressing that so it's not a problem, and also has something known as TCP connection reuse. It opens just one TCP connection and over that connection it can send and receive several files at a time, Okay, using different algorithm, it doesn't matter.
[00:06:36] But that's having in mind that HTTP/2 is much better for performance. And now we have HTTP, before that. HTTP/2 is TLS-based only, as we mentioned before. Today, it's good compatibility. You just need to upgrade your servers or use a CDN, okay? It works with upgrading connections. So the first connection, we start with HTTP/1, that is a standard, and we ask the server, hey server, I accept 2 if you wanna upgrade.
[00:07:03] And the server will say, okay, let's upgrade, and from now on, it continues in 2. If the browser is not supporting 2 or the server is not supporting HTTP/2, everything is done over HTTP/1.1. And HTTP/3 It's exactly the same as HTTP/2, so it's the same interface. But instead of using TCP, it's using UDP.
[00:07:26] Does anyone know what that means? You have the face of I know it but I'm not sure.
>> Universal digital packet or unstructured digital packet?
>> No, it's not about unstructure, but I mean, I'm not talking about what the acronym means, but what's the difference between TCP and UDP?
>> Yeah, it's packet-based as opposed to [INAUDIBLE].
>> Both are packet-based.
>> But it's asynchronous. That UDP doesn't necessarily have to maintain a handshake continuously.
>> [SOUND] You're close, but I'm not sure I like the answer.
>> Doesn't UDP allow dropping some packets, you can lose some data in the process?
>> Yeah, we are close. It's not that it's allowing dropping the packets, but actually what is happening is it's not detecting if packages are being delivered or not. TCP is guaranteeing that packages will be delivered, and if it's not, I mean, it's checking that every packet is getting into the destination, and if it's not, it's retrying.
>> Is it the ordering? Is UDP not necessarily in this order that it's supposed to be [INAUDIBLE]?
>> That's another thing, so actually, TCP is guarantee the order. So actually, because when you're sending messages over TCP, for example, the message typically is split in chunks, in packets. And they go over the network, and they are traveling around the Internet.
[00:09:02] And they might arrive in different orders, or maybe one packet is lost, so that's why TCP is managing that. UDP, it's more that, okay, I'm sending this, I don't care, okay, I will continue my job. HTTP/3 is based on UDP. And maybe you're thinking, well, but what happens then?
[00:09:24] My packets will not get into the destination. Well, actually, there is another protocol on top of that that will. There is a thin layer, there is much performance that TCP, that makes things faster. Anyway, the only thing that you need to know is that it's faster, and it's something that you have to support in your server.
[00:09:46] If you don't want to, or don't have the resources to do that, maybe your infrastructure team is telling you we're not going to do that. The solution you have is a layer on top, such as Cloudflare. There are companies, free or paid, where you add a frontend to your website, they offer HTTP/3 to your users and they contact you over an older protocol.
[00:10:12] Cloudflare is one example of that, okay? Anyway, those are the versions of HTTP are available today.