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
Latest comments (27)
With this http/3, the development of transmission will be much faster.
daniel.haxx.se/http3-explained/ :D
Great article! Thanks for sharing :)
The banner image spells doomsday! :)
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.
It would be pretty dangerous to let HTML5 access the networking layer :-)
I'm sure in browser multiplayer games will benefit from HTTP over UDP as well.
There is WebRTC, which is, IIRC, run over UDP. If you don't care about P2P, you could conceivably use it between the server and the client, eliminating most of the signaling pain.
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.
Isn't QUIC used over UDP?
Yes QUIC is-over-UDP.
Sorry for the confusion, I have changed the explanation. Also updated the article.
Unrelated, but did you make the HTTP/3 Glitch gif you used as your cover photo?
You can get a good result using photomosh (Jitter effect) and can export the result as a .gif
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.
This is nice for web, but seems like a insane booster for competitive gaming where latency matters so much!