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