HTTP/3 is Coming!

Ryuzaki

お前はもう死んでいる
Moderator
BuSo Pro
Digital Strategist
Joined
Sep 3, 2014
Messages
6,244
Likes
13,130
Degree
9
I learned about this from Cloudflare's Blog, who apparently has chipped in on the tech and helped create standards so we can all get on the same page (no pun intended!).

There's not a lot to say. I don't know when this will be released, but all the browsers are working on it. It basically breaks down like this...

____

HTTP/1
The problem is every single request had to be made over it's own TCP connection, and the TLS handshake takes forever up front. Lot's of initial latency, and then latency for the handshake before getting each resource, while getting resources one at a time. This was kind of solved with keep-alive connections so you only had to do the TLS handshake during the first connection.

HTTP/2
This is where we are now. The benefit here is that we can push most if not all the resources over one single connection. Now we don't have to worry about keep-alive connections, though the initial slow TLS handshake is still there. A problem with this setup is that if you lose a single packet in the single stream sending all the resources, everything stops until that packet is re-sent. Major bottleneck there, called "head-of-line blocking."

HTTP/3
The future. TCP is out of the picture and QUIC is in. We'll only need one TLS handshake still, but that typical 3 step process is now faster somehow (magic), and we can still multiplex resources in one single stream, but now somehow the QUIC packets get "mapped" and if a packet drops, the rest of the stream can still be delivered and the trailing packet can be added back in once it catches up. So no bottlenecks. The header compression scheme HPACK is now replaced by QPACK. HTTP headers had to come in a certain order one after another. Now they can come in any order and at the same time, and are then re-ordered in the browser. Much faster! And to top it off, QUIC lets us start sending HTTP requests before the TLS handshake is even done, which is even faster than server pushing.

_____

What this ultimately means in terms of speed? It sounds like not a lot if you want to measure it. But what it does mean is we should start rendering pages a lot faster. We're removing a lot of TLS handshake time, getting HTTP headers in place faster, and won't deal with head-of-line blocking. If we shave an extra 100 milliseconds off each connection by default before first-paint just by using HTTP/3, that's pretty freaking significant. It will be a nice boost for first adopters until everyone catches up (by default we'll all be using this soon enough).

Exciting times!

All these advances are amazing, but the real changes will come when our general bandwidths are doubled and tripled and the servers themselves can handle it. We'll see a lot of that kind of thing happening in the mobile realm with 5G and 6G in the coming years till it fully catches up with desktop speeds. Then it's going to start coming down to hardware advances, methinks.

If you're excited, give me a HELL YEAH and also add what you think the implications of this are for SEO and general internet usage at large so we aren't littering the forum with just HELL YEAH's.
 
I never knew about the HTTP scheme of things. Just educated me
 
Back