HTTP/3. All you need to know

This content originally appeared on DEV Community and was authored by Valerii Udodov

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.

ℹ️ Port 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 is an application layer protocol that sits on top of the transport layer protocol, like TCP.

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).

ℹ️ Nowadays, we use HTTPS most of the time. HTTPS is an HTTP over TLS. Older versions of TLS (1.2 and lower) will require an extra handshake. So in the worst-case scenario, there's another RTT on top of all other handshakes.

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.

ℹ️ All large files nowadays downloaded and uploaded in segments, so if the large file will be uploading or downloading, you won't loose the whole file, but rather a last segment.

TCP was not built, nor was it optimized for such a usage...

ℹ️ The way TCP identifies a connection is pretty straightforward. Each connection between two endpoints (client and server) is identified by 4 parameters (4-tuple). Client IP address, client port number, server IP address, and server port number. If any one of the 4-tuple changes, TCP thinks it is a new connection. And the old one will be lost, it won't be even closed properly.
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.

ℹ️ It is a bit more involved process. However, there's one more aspect to it. CID won't be encrypted. However, after every successful migration CID will be updated, so the connection (and your route) won't be traceable by CID.

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.

This content originally appeared on DEV Community and was authored by Valerii Udodov