Read on Twitter
HTTP/3 is being deployed in production for all of us, and that could be important for you and me and the Internet.
(Short) thread ahead
(Short) thread ahead
HTTP is this protocol that makes the web work https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol It was first described (and implemented) in 1989 (you know: @timberners_lee and his team and the @CERN and all that), but it was first formally specified as HTTP/0.9 in 1991.
HTTP/0.9 was a simple protocol built on top of TCP, using plain text headers, with no encryption, very limited in functionality, but doing its task well enough for those ages. Its description is like one page long: https://www.w3.org/Protocols/HTTP/AsImplemented.html
HTTP was a great success, with Mosaic http://www.ncsa.illinois.edu/enabling/mosaic and then https://en.wikipedia.org/wiki/Netscape and then Explorer https://en.wikipedia.org/wiki/Internet_Explorer in 1995. And millions of websites, and e-commerce, etc. etc. etc.
People started to add some non-standard functionality both client-side and server-side (main servers at that time were NCSA HTTPd, later Apache; Netscape server; Microsoft IIS), and HTTP 1.0 was produced in 1996 (RFC1945) https://tools.ietf.org/html/rfc1945
But meanwhile, people were already working on HTTP 1.1, so that many of its features were already supported by clients and servers already in 1996. It was formally approved in 1997 as RFC2068, updated in 1999 as RFC2616 https://tools.ietf.org/html/rfc2616 (~170 pages long)
HTTP 1.1 was the protocol that made it possible the big bang of the web, during the late 1990s and early 2000s. Still on TCP, still plain-text headers. But it could be used with encryption, single TCP connection of several interactions, and supported a lot of mechanisms.
HTTP 1.1 was so successful (and the interests on HTTP were so varied and powerful), that until 2014 we didn't have an update... that was still HTTP 1.1 (six RFCs, usually named 723x, plus some complements) https://www.w3.org/Protocols/
This renovation of HTTP 1.1 had into account industry practices & demands, and tried to put some order in a period when the web was the dominant application in the Internet, and it needed to live up to that standard. But it was obvious a more drastic reform was needed.
Since 2009, Google, with the support of other important actors, had been working on SPDY. It changed HTTP in some significant ways: it was binary (forget plain text headers), it supported multiplexing of TCP connetions, header compression... https://www.chromium.org/spdy/spdy-whitepaper
By 2012, Chrome, Firefox, and Opera supported SPDY, and some large web sites too (eg Facebook, Google, Twitter). It was in its path to become a de-facto standard. It's main advantage: it reduced latency *a lot* https://developers.google.com/web/fundamentals/performance/http2/
But instead of letting SPDY become de-facto standard, after an open call it was used as the basis for HTTP 2, the new, shinny version of the protocol, released in 2015 as RFC 7540 (HTTP/2) and RFC 7541 (HPACK)
After this release of the new HTTP 2 "protocols", Google stopped SPDY, and waters came back to the "official standards" river https://developers.google.com/web/fundamentals/performance/http2/ https://blog.chromium.org/2015/02/hello-http2-goodbye-spdy.html
HPACK, btw, is a very interesting addition to HTTP 2 https://blog.cloudflare.com/hpack-the-silent-killer-feature-of-http-2/ It does Huffman encoding of headers, significantly reducing size (specially for requests with a small payload), and is more resilent to attacks aimed to sniff cookies
HTTP 2 has been very successful in adoption, although few users may have noticed (except for better web performance for them). Main reasons are probably the multiplexing of HTTP requests on single TCP connections, and the header compression
But HTTP 2 was not radical enough. In a path that by now may be familiar, Google started to work on a more complete redesign of HTTP: the QUIC protocol https://www.chromium.org/quic
QUIC is radical in several ways, but probably the most noticeable is its use of UDP as transport layer, instead of TCP. This means that QUIC had to implement reliability and order, as TCP does. And TLS. But it does it in its own way https://www.chromium.org/quic
As it happened with SPDY and HTTP 2, QUIC became the core of HTTP 3 https://http3.net/ https://www.zdnet.com/article/http-over-quic-to-be-renamed-http3/
Currently, HTTP 3 is still in the works https://quicwg.org/base-drafts/draft-ietf-quic-http.html But is is expected to be stable until it is fully standardized, and it is already supported by some browsers, with others announced (Chrome, curl, soon Firefox)
Today, Cloudflare has announced they are supporting HTTP 3 in their servers https://blog.cloudflare.com/http3-the-past-present-and-future/ Since Cloudflare is running more than 10% of all the web servers in the world https://w3techs.com/technologies/details/cn-cloudflare/all/all this is big news for HTTP 3 and QUIC
And it also means a change in how Internet works, and likely a change in how we should teach Inet protocols from now on. Reliability, order & encryption for the web are now in QUIC, no longer in TCP and TLS.
If you want to learn more about the details of QUIC and HTTP 3, have a look at "HTTP/3 Explained" https://http3-explained.haxx.se/en/ Some other references summarizing QUIC & HTTP 3: https://arstechnica.com/gadgets/2018/11/the-next-version-of-http-wont-be-using-tcp/ https://medium.com/drill/the-internet-changes-http-3-will-not-use-tcp-anymore-427e82eeadc0 https://kinsta.com/blog/http3/
BTW: Quiche, the implementation that Cloudflare is using for QUIC and HTTP 3, is based on @rustlang and is #freesoftware https://github.com/cloudflare/quiche
Final note: if after all this thread it happens that you don't know about how HTTP works, have a look at a very good summary in MDN https://developer.mozilla.org/en-US/docs/Web/HTTP/Overview It is about HTTP 1.1, but most of it remains similar in HTTP 2 and HTTP 3 (except for how connections work, of course)
