HTTP/3 is a long overdue change in the way the Internet works. Surprisingly, though, it does not impact us as protocol consumers much… Moreover, the transition will be barely noticeable. Eventually, we will notice that port 443 is gone. And we won’t need to type https:// anymore. We will be getting back to http://…
We’ll talk more about it later.
443 is the one that is used for secure HTTP (aka HTTPS connection).So hmmm… What is it all about?
It is all about TCP, really. Or should I say it’s retirement? TCP has been around for astonishing đ˛ 30+ years. It is obsolete by any, even most conservative IT standards. So it was decided to replace it with a more modern transport layer protocol- QUIC.
HTTP/3 uses QUIC instead of TCP. QUIC is the main driver for the new version of HTTP. And that’s pretty much everything that changes from an HTTP perspective. Semantics stays the same. Hence all we know about HTTP as consumers stay the same. It will only be riding new wheels.
Why to change it? Why now? It seems like internet is working fine, isn’t it?
Speed
Connection reliability is a given, thanks to TCP. Thus, the ultimate connection measurement is its speed. And obviously, there’s no way to sell a new protocol without improving it.
Three factors dramatically improve QUIC data transition speed compared to TCP
- Real Streams: is actual direct data transition speed improvement;
- Improved handshake: is an improvement in connection establishment speed;
- Connection Migration: reduces the number of necessary re-connections, hence fewer connection establishments and data losses between sessions, hence even more speed;
Real Streams
Because in the TCP all packets are transitioned in a “line”, if one packet is slow or lost, the whole “line” has to wait for the slow/lost packet to get back to its place and move on. Even though TCP has a concept of streams, those are not real streams but rather an abstraction to simulate them. Multiple files are broken down into packets, and packets are grouped in small frames, but anyway go through a single stream in “line”.
QUIC implements streams, I mean real streams, so the data will flow truly simultaneously via a single connection but through multiple streams. E.g. the JS bundle file might be a stream and markup another stream.
Apart from speed gain by truly parallelizing the packet transition, there’s an annoying problem that has been solved. The Head Of Line Blocking.
You know, when you are in a rush and get in the line at your grocery store. And there’s this super slow person in front that just slows the whole line down. Well, that’s the HoL Blocking.
When a single (slow) object prevents other/following objects from making progress
All versions of HTTP, in one way or another suffered from the Head Of Line Blocking (HoL) on different levels. In HTTP/2, it was TCP HoL blocking because of a single-stream nature.
QUIC doesn’t really solve the HoL blocking problem, it rather moves it to a different place. Although it does not completely solve the problem, nevertheless this shift significantly improves the performance.
The HoL Blocking can occur at the stream level. Because stream order is still important, you can’t reorder or lose packets. Hence, if there’s a slow fellow in the stream, the stream can’t proceed and have to wait… But in this case it won’t block other streams. And once the issue with the annoying packet is solved, the stream will resume.
Handshake
Handshake is a procedure of establishing a connection between client and server. It ensures that both parties ready and know how to communicate.
TCP handshake is a necessary procedure occurring before any data can be sent over TCP. It requires a client to send a request and receive a response/acknowledgment from the server. Time spent waiting is called round trip time (RTT).
QUIC will require at least one handshake less. It will require exactly one handshake for a new connection and no handshake for resumed connection. Which makes QUIC 1RTT for a new connection and 0RTT for resumed.
Image is borrowed from SMB over QUIC: Without the VPN by Ned Pyle
Image (a) shows required handshakes for a new connection. As you could expect TCP with old TLS version will have 3RTT, TCP with modern TLS 2RTT, while QUIC only 1RTT.
Image (b) shows required handshakes for existing connection. Once again, TCP with old TLS will require 2RTT, TCP with modern TLS 1RTT, while QUIC 0RTT
I vacuum (completely identical circumstances): the lesser handshakes the faster connection.
Connection Migration
The way we use the Internet has significantly changed over the past decade. Nowadays, a large portion of the internet traffic is consumed while we are on the go. Walking, commuting on public transport, or driving a car.
Imagine you live within 30 mins walking distance from your work. And you decide to enjoy a walk to work today. There’ll be at least 3 guaranteed network changes on your way, home wifi -> cell network (4G/5G) -> work wifi. However, in reality, during your walk (while you are connected to a cell network), you will be changing a network every 5-10 minutes, depending on the nearby cell tower range and how urban is the area you live/work in.
On every new connection, unavoidably, at least one new handshake will be happening. Any active data downloading/uploading will be lost. Your endpoints will think that connection just has been lost or terminated unexpectedly.
Have you ever experienced troubles with downloads/uploads while you were on the go? Well, there you have it.
TCP was not built, nor was it optimized for such a usage…
Every time the network changes, the client will receive a new IP, hence the whole connection 4-tuple will be changed.
The Connection Identifier (CID) allows the QUIC server and client to identify that what they see is not a new connection, but rather an existing connection migrated from another network. Therefore no need for a handshake and the download/upload process can keep on going.
Security
HTTP is a plain-text protocol. It simply sends a text over the wire (or radio waves). S in the HTTPS stands for Secure. By using HTTPS, we instruct a browser on a TLS protocol involvement in the communication. TLS protocol will encrypt our data using advanced mathematical algorithms. This ensures that even though the data might be intercepted by a third-party, it is useless. Nowadays, most web resources on the Internet use HTTPS.
Even though modern browsers insist on HTTPS usage, we can still avoid it.
With QUIC, it is unavoidable. Because TLS is built in the QUIC. Hence with HTTP/3, there won’t be a need for https:// and port 433. Everything will be encrypted out of the box. And there’s no way to turn encryption off.
There’s one small thing… đĢ
How do you go about upgrading the whole Internet? All devices, all routers, everything that uses TCP? đ¤
And to give you a scale of the problem, have you ever tried to trace any random request? If not, try with something like this online tracer, and you will see how many nodes are involved in your request delivery. These are middle-boxes. My google.com trace shows 11 middle-boxes between me and the server đŽ… And all of them use TCP đŗ… And all of them probably don’t run the latest version of Network Firmware…
When was the last time you updated your router firmware? Exactly đ…
And this was the exact reason why a new protocol was required. Because there’s no way to update all devices in the world.
As you can tell, simply adding a new protocol wouldn’t work for the same reasons as updating TCP. So what do you do?
The answer is User Datagram Protocol aka UDP. It can provide a platform for the QUIC protocol. It is broadly available and has been used as a base for many other protocols, such as DHCP, SMTP and RIP. QUIC is built on top of UDP, which makes it possible to deploy QUIC on the Internet scale.
Over 73% of browsers support HTTP/3 as I’m writing this article. It is only a matter of time before all browsers and the majority of modern app servers will switch to it.
Caveats
There are a few things worth calling out.
QUIC protocol requires more processing power. It has significantly improved since its first iterations. Nevertheless, compared to TCP, QUIC will consume more resources.
And the other thing, even though it is relatively easily deployable because it is built on top of UDP. For the same reason, initially companies will block it as it will open a backdoor of UDP Flood DDoS attacks.
Bottom Line
Hopefully, this article builds a picture of what we can expect from HTTP/3 and QUIC.
I’m keen to see how the world will adopt the new protocol and what will be the future strategy for enabling it. I reckon there are industries that might want to adopt it ASAP. Gaming, video streaming, online communication, meta to name a few.
I’m glad that TCP is getting well-deserved retirement. I’m still surprised at how long it worked on a global scale. It set the bar high.
QUIC is already here. As I mentioned, majority of modern browsers support (to a different extend) HTTP/3, hence QUIC. I’m waiting with anticipation to see if our hopes for a new internet evolution step will be justified.