If you are not a network administrator occupied with web server optimization, there is no reason why would stumble over HTTP/3. If you actually try to get into the reading about HTTP/3, you will probably drown in a bunch of acronyms and terms like qQUIC, iQUIC, HTTP over QUIC or HTTP / QUIC which are not exactly self-explanatory. What’s behind these acronyms? How are they connected? How do they relate to HTTP? That’s what this article is all about.
The Hypertext Transfer Protocol, HTTP for short, is one of the three cornerstones of the World Wide Web, along with the Uniform Resource Locator (URL) and Hypertext Markup Language (HTML). Indicated by the versioning, the HTTP development is going forward since it was introduced. Compared to the well-maintained HTML standard, HTTP has developed relatively little in recent years. HTTP/1.1 was introduced in 1999 and is still being used in the vast majority of websites. The current successor HTTP/2, which is now almost four years old, promises enormous speed advantages, but only has a 34% adoption rate.
Although the current protocol is not widely known, there is already a successor waiting at the door (or at least at the garden gate): HTTP/3 which is supposed to bring radical changes.
A 4-class-society or: the layer model
Let’s dive into the theory. In order to better understand the technology and implementation of QUIC, it is helpful to get back to the 1st lesson in computer networking and look at the TCP/IP-layer model (Figure 1).
The electronic signals coming out of the network cable go through the four layers (seven, if you refer to the OSI layer model, but four is sufficient to understand the role of QUIC) in order to display a web page.
Each layer corresponds to one or more protocols. Each protocol processes the incoming signal from prior protocol and passes it to the next protocol. Every layer fulfils a unique task such as physical transmission, quality assurance or representation of the information in an application, like the browser.
HTTP is a protocol of the last layer, the application layer, that is not only used for HTML but also plain text or pictures. Encryption takes place between the application and transport layer using the Transport Layer Security (TLS). On the transport layer, the well-aged Transmission Control Protocol (TCP) does it’s work. An alternative and faster transport protocol is the User Datagram Protocol (UDP). Unfortunately UDP cannot guarantee that all data packets are transmitted. Therefore it is not eligible for being used as a transport protocol and HTTP is still stuck on the ancient TCP.
Once upon a time…
Since every good computer science lecture always includes a historical excursion, let’s also have a look at the development of HTTP.
HTTP was first mentioned by Tim Berners-Lee in the summer of 1991. His concept for the WWW comprises three components HTML, Uniform Resource Locator (URL, originally called Universal Document Identifier, UDI) and HTTP [2]. Berners-Lee’s first version of HTTP was a very simple, text-based protocol where every transmission required its own TCP connection. The HTTP request was a one-liner and the HTTP response from the server only contained the requested resource. Plain and simple.
In the next few years, HTTP developed steadily to meet increasing requirements of the growing WWW. As part of a barely organized process, several parties proposed and implemented additional features. Five years later, in the summer of 1996, the Internet Engineering Task Force (IETF) summarized the most useful of those features as HTTP/1 using the memo RFC1945.
However, the task force felt the need to point out that this was still not a real standard: “This memo does not specify an Internet standard of any kind.”
The actual work on an official standard actually began one year before the mentioned memo under the working name HTTP/ng, ng for next generation. In 1997, it finally became HTTP/1.1, which was introduced as a true standard.
The two most important changes were the (1) keepalive function and (2) the pipelining feature. The keepalive function allowed an open TCP connection that could be used for more than one data transfer. The pipelining feature theoretically offered a way to make requests without having to wait for the associated answer from the server. A feature, that at that time, only a few browsers supported. The protocol also supported sending data to the server.
After announcing HTTP/1.1, the core development plateaued until 2012, when a draft for HTTP/2 was presented to the public. The new version was based on SPDY, an alternative protocol that Google had been using and developing since 2009. The final HTTP/2 standard was officially launched in 2015. The most important changes were:
A new feature multiplexing which improved asynchronous data transfer. Additionally HTTP/2 became a binary protocol, meaning that the data is no longer transmitted in plain text (see RFC 7540).
Transitory, persistent, pipelining und multiplexing
- Transitory: For each data transfer a TCP connection must be created.
- Persistent: An open TCP connection can be used for multiple requests and responses.
- Pipelining: An HTTP request can be issued without waiting for a response from the server. The Answers must match the order of the requests
- Multiplexing: The HTTP requests can be made independently of previous responses and the order does not matter.
The Acronym Potpourri
QUIC (Quick UDP Internet Connections) is a transport protocol that Google first launched in 2012. Since then QUIC has been implemented in many Google products, such as Chrome, YouTube and GMail. In 2016, the IETF established a working group to standardize this new Google technology to make it usable for HTTP. They kept the short name “QUIC”, but insisted that it is no longer an acronym:
QUIC is a name, not an acronym
IETF, 11. March 2019
In order for IETF to differentiate their fork of QUIC, it was referred to as iQUIC, respectively gGUIC was used for Google’s development. Of course the overlying HTTP had to be adapted for the use of QUIC. The internal project name for adapting HTTP became known as HTTP-over-QUIC or HTTP/QUIC. At the end of 2018, IETF announced that HTTP/QUIC will supersede HTTP/2 – HTTP/3 was born.
Combining the best of two worlds – and more
TCP was a loyal servant to the WWW for a long time, but no longer kept up with modern requirements. The protocol not only requires a fixed sending order, but also a receipt for sent data. This makes the protocol reliable, but also slow.
UDP, though faster, is less reliable. The protocol checks the integrity of the data, but does not take corrective action in case of errors or data loss. There are scenarios where lost packets are negligible, like video streaming. It is not a suitable protocol for transferring HTML documents where packet loss is unacceptable.
With the upgrade from HTTP/1.1 to HTTP/2 came promises of improving shortcomings. Unfortunately, the promises did not suffice, because HTTP/2 still utilized TCP.
One example is multiplexing. The head-of-line-blocking still occurs at the TCP-level: if a packet is lost while being transferred using TCP, all subsequent packets must wait for the lost package being recovered.
QUIC solves this by introducing real multiplexing where requests can be issued asynchronously, the order of responses does not matter, and lost packets do not block the queue anymore.
Another example is persistent connections. A common scenario where persistent connections are used is changing networks. When you switch from WiFi to your mobile network, in TCP you would lose your connections.
While TCP connections are identified by the IP addresses and ports of the sender and receiver, QUIC connections are using a unique 64 bit identifier. This id can be maintained across networks and thus enables real persistent connections.
Another improvement concerns the encryption of the communication. TLS previously acted as an additional layer between HTTP and TCP. However, TLS has not been mandated, not even in the HTTP/2 standard. It only became a loose quasi-standard because most common browsers made TLS connections mandatory.
TLS only encrypts the payload, but the metadata of the connection still remains readable and therefore interceptable. QUIC takes a more stringent approach by encrypting payload and metadata and handling authentication directly. Therefore TLS, as separate layer, is eliminated. This also increases performance.
While HTTP/2 was trying to patch TCP issues, HTTP/3 now has the opportunity to communicate over a new transport protocol: QUIC. This should finally enable HTTP to deliver former promises.
QUIC in the wild
If you want to get an idea of the technological model of qQUIC, you can use one of the numerous Google services since they have been using QUIC since 2012. In Chrome open the developer tools and switch to the network tab. Then right click on the column headers and enable the protocol column. Google provides a lot more information and several code examples on its product page.
The network diagnostics program Wireshark is also capable of displaying QUIC packets and it even distinguishes between gQUIC and iQUIC. To see the qQUIC traffic in plain text, open the settings of the gQUIC protocol and check the option “Force decode of all (Google) QUIC Payload”.
But beware that the content is only as decrypted as the protocol allows. This means, that you will not be able to display a search query in clear text.
The quick filter for the protocol is named gquic. For example, to display the initial gQUIC request you may use the filter expression gquic.tag == CHLO . Figure 6 shows an excerpt from the data transmitted by gQUIC in version Q043, with the highest level of decryption.
There are also some experimental and commercial implementations of QUIC. For example the commercial server software LiteSpeed. For nginx there is an experimental QUIC module, as well as for the web server Caddy. Caddy uses an implementation in Go, which is based on both: gQUIC and iQUIC.
Supporting browsers are, of course, Chrome, supporting gQUIC since 2012 when using Google’s services like YouTube or Gmail. Basically, every other browser using the render engine Chromium (from Version 29) is able to understand QUIC. One of them is Opera. Though QUIC has to be enabled manually in Opera, using the settings-page accessible via opera:flags.
Outlook
The real star behind the next HTTP evolution is indeed QUIC. The new transport protocol will replace the time-honored TCP with the goal of increased speed, mobility and security and to finally fulfil the promises of HTTP/2. When QUIC or HTTP/3 will be announced as a standard is still completely unclear.
There is still time for developers and admins to forge plans. Or to panic. Actually, panic may not be required because QUIC will require basic software updates. As QUIC is based on the underlying UDP, updating the browser software without waiting for the next OS release should be sufficient.
In addition, QUIC is backwards compatible. So it supports a fallback to TCP if the remote station is not yet ready for the new protocol.
At Cloudflare it is expected that the QUIC working group will present a first draft at the end of this year. The HTTP working group, however, did not yet provide a fixed date for that. They have announced that they will start developing the necessary extensions to prepare HTTP for QUIC. That’s something, isn’t it?