Thread by @jgbarah

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

HTTP is this protocol that makes the web work en.wikipedia.org/wiki/Hypertext… 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.

@timberners_lee @CERN 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: w3.org/Protocols/HTTP…

@timberners_lee @CERN HTTP was a great success, with Mosaic ncsa.illinois.edu/enabling/mosaic and then en.wikipedia.org/wiki/Netscape and then Explorer en.wikipedia.org/wiki/Internet_… in 1995. And millions of websites, and e-commerce, etc. etc. etc.

@timberners_lee @CERN 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) tools.ietf.org/html/rfc1945

@timberners_lee @CERN 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 tools.ietf.org/html/rfc2616 (~170 pages long)

@timberners_lee @CERN 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.

@timberners_lee @CERN 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) w3.org/Protocols/

@timberners_lee @CERN 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.

@timberners_lee @CERN 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... chromium.org/spdy/spdy-whit…

@timberners_lee @CERN 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* developers.google.com/web/fundamenta…

@timberners_lee @CERN 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)

@timberners_lee @CERN After this release of the new HTTP 2 "protocols", Google stopped SPDY, and waters came back to the "official standards" river developers.google.com/web/fundamenta… blog.chromium.org/2015/02/hello-…

@timberners_lee @CERN HPACK, btw, is a very interesting addition to HTTP 2 blog.cloudflare.com/hpack-the-sile… 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

@timberners_lee @CERN 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

@timberners_lee @CERN 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 chromium.org/quic

@timberners_lee @CERN 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 chromium.org/quic

@timberners_lee @CERN As it happened with SPDY and HTTP 2, QUIC became the core of HTTP 3 http3.net zdnet.com/article/http-o…

@timberners_lee @CERN Currently, HTTP 3 is still in the works quicwg.org/base-drafts/dr… 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)

@timberners_lee @CERN Today, Cloudflare has announced they are supporting HTTP 3 in their servers blog.cloudflare.com/http3-the-past… Since Cloudflare is running more than 10% of all the web servers in the world w3techs.com/technologies/d… this is big news for HTTP 3 and QUIC

@timberners_lee @CERN 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.

@timberners_lee @CERN If you want to learn more about the details of QUIC and HTTP 3, have a look at "HTTP/3 Explained" http3-explained.haxx.se/en/ Some other references summarizing QUIC & HTTP 3: arstechnica.com/gadgets/2018/1… medium.com/drill/the-inte… kinsta.com/blog/http3/

@timberners_lee @CERN BTW: Quiche, the implementation that Cloudflare is using for QUIC and HTTP 3, is based on @rustlang and is #freesoftware github.com/cloudflare/qui…

@timberners_lee @CERN @rustlang 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 developer.mozilla.org/en-US/docs/Web… 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)