The HTTP-over-QUIC experimental protocol should be renamed to HTTP/3, officials at the (IETF) have disclosed.
There is a big gap in development from HTTP/1.1 (released in 1999) to the release of HTTP/2 (released in 2015), things are hitting up with the release of HTTP/3 due in 2019.
HTTP/3 is an evolution of the QUIC protocol from Google. It's started from this suggestion by Mark Nottingham.
So what is QUIC?
As described in The Chromium Projects homepage:
QUIC ( Quick UDP Internet Connections) is a new transport which reduces latency compared to that of TCP. On the surface, QUIC is very similar to TCP+TLS+HTTP/2 implemented on UDP. Because TCP is implemented in operating system kernels, and middlebox firmware, making significant changes to TCP is next to impossible. However, since QUIC is built on top of UDP, it suffers from no such limitations.
Key features of QUIC over existing TCP+TLS+HTTP2 include
- Dramatically reduced connection establishment time
- Improved congestion control
- Multiplexing without head of line blocking
- Forward error correction
- Connection migration
Google says that roughly half of all requests from Chrome to Google servers are served over QUIC and they are continuing to ramp up QUIC traffic, eventually making it the default transport from Google clients — both Chrome and mobile apps — to Google servers. They plan to formally propose QUIC to the IETF as an Internet standard but they have some housekeeping to do first, like changing the wire format and updating their reference implementation from SPDY-over-QUIC to HTTP2-over-QUIC (current HTTP-over-QUIC protocol draft uses the newly released TLS 1.3 protocol). In the coming months, Google also plans to work on lowering handshake overhead to allow better server-side scalability, improving forward error correction and congestion control, and adding support for multipath connections.
Great explanation of TCP vs QUIC by reddit user:
TCP was developed when we still were transmitting packets over networks that had much larger packet loss than we do today and computer systems had much longer to answer TCP messages. The timeout for connecting to a host for example is still 20 seconds even though you are very unlikely to ever get an answer if the TCP handshake alone can’t even be completed within 5 seconds. These long delays are reasons why networked applications sometimes get stuck for a long time. We haven’t touched these delays since the protocol was invented in the 70s even though we saw massive improvements on reliability and speed.
Instead of finally reducing these defaults which would not alter the packets and is largely compatible with the current TCP implementations, protocol developers just started using UDP and then implement their own TCP on top of it. The transition to IPv6 would have been the ideal time to also update TCP to a version that fixes most of the issues it has, mostly timeouts, window size and TCP slow start. Some of the values can be tweaked in your OS, but the timeout, which is one of the most annoying can’t. If you kill a TCP socket that hangs for 5 seconds, your OS will still leave it open until the 20 seconds expired, consuming system resources.
Originaly published here: https://medium.com/devgorilla/what-is-http-3-94335c57823f
Top comments (27)
Nice writeup, thanks!
Still waiting for HTTP/2 to overtake HTTP/1.1. We're still behind in adoption :(
Large, critical systems are hard to upgrade. Especially when it requires OS level changes. 'It works now, dont touch it'. Health care, defense, physical infrastructure controls, industrial control systems. These systems are critical to the safety and daily survival of millions. Upgrading the OS just to be 'up to date with the new hotness' is to much of a risk factor.
Typically these large systems only get upgraded when the hardware is replaces. If you are an American your health insurance company still interacts with AS/400 from the 1970's on a daily basis. Those machines will (nearly) never update from the version/s of software running.
Large systems update slowly, 'cause an outage could be catastrophic to the organization and public safety. The (entertainment) web can do what it wants as fast as it wants 'cause peoples lives are not at risk in daily operation.
Remember, the "internet" is every connected device. The "web" is what can be rendered in your browser.
Yeah 21 years of HTTP/1.1 do create some legacy :D
...and HTTP 0.9 was released in ... wait for it ... 1991! Nearly in step w/ HTML. Legacy is an understatement :).
Yeah, but for all intents and purposes, many developers saw gains without having to think about it much. You can't yet rely as much on some of the fancier HTTP/2 stuff, but plenty of CDNs and the like adopted it, giving immediate access to multiplexing, which should have default-helped a lot of developers.
If H/3 just makes things better when available without much implementation burden on the individual developer, should be pretty great. And H/3 seems like a huge leap.
True that!
H/2 is a leap forward and even if it's not 100% supported everywhere it's still something. It's a boon especially for this new wave of JAMstack websites. You can even stop concatenating multiple files into one because of HTTP/2.
Talking about the less fancy features: I wonder if someone could implement a HTTP/2 web server that uses machine learning onto its logs to analyze users patterns and tune server push to maximize client side performance.
Just throwing this out there :D
Isn't QUIC used over UDP?
Yes QUIC is-over-UDP.
Sorry for the confusion, I have changed the explanation. Also updated the article.
HTTP right now is on top of TCP yes. HTTP/3 will be on top of UDP. It won't matter much to web developers because HTTP already is an abstraction on TCP, we don't use TCP directly.
The only way you need to actually access the TCP/UDP layer is if you're going to write a networking server instead of just using one.
This was a great intro to whet the appetite :)
The moving picture was worth 1000+ words!
Now I am wondering how long it'd take for the world to adopt H/3. The faster we adopt, the faster we can communicate.
Anybody knows the state of FEC in QUIC? All the documents I can find conclude that it's not worth the pain... But I know use cases where it might be REALLY helpful especially if native in HTTP proxies.
This is nice for web, but seems like a insane booster for competitive gaming where latency matters so much!
Unrelated, but did you make the HTTP/3 Glitch gif you used as your cover photo?
Yes, spent more time for making the HTTP/3 Glitch gif than preparing the article.
How'd you do it? After Effects I assume?
Photoshop + online glitch effect tool.
You can get a good result using photomosh (Jitter effect) and can export the result as a .gif
This is really exciting! Looks like a huge leap from HTTP/2!
It was quic since HTTP/2
I look forward to this. TLS+H2 over UDP? Wow. What a world we live in!