Three and a half years have passed since the adoption of the HTTP / 2 standard: RFC 7540 was published in May 2015, but is not used everywhere. The protocol has been implemented in all browsers since the end of 2015 , and three years later, only 31.2% of the 10 million most popular Internet sites support HTTP / 2. Of the most popular sites, Google, Youtube, Wikipedia, Twitter, Vk.com and others have switched to it.

Nevertheless, progress does not stand still - and work is already underway on the next version of HTTP / 3. As it has now become known , the developers of the two alternatives have reached compatibility, and the HTTP-over-QUIC protocol now changes the name and is officially referred to as HTTP / 3 . Accordingly, in a future version of HTTP, TCP transport will be replaced by QUIC.

Confusion with different QUIC options

QUIC is a TCP replacement that runs on top of UDP. Initially, this technology was created by Google engineers, like the previous SPDY protocol, which became the basis of HTTP / 2. At first, QUIC was called “HTTP / 2-encrypted-over-UDP”.

Then the development of QUIC was transferred to the IETF for standardization. Here it is divided into two parts: transport and HTTP. The idea is that the transport protocol can also be used to transfer other data, and not only exclusively for HTTP or HTTP-like protocols. However, the name remains the same: QUIC. The transport protocol is developed by the QUIC Working Group at the Internet Engineering Council (IETF).
')
At the same time, Google continued to work on its own implementation - and implemented it in the Chrome browser. Although tests show that Google’s QUIC implementation works much worse than TCP if the network does not guarantee the order of delivery of packets .


Performance difference between QUIC with TCP (in percent) on a network with 112 ms RTT and 10 ms jitter, source


The performance difference between QUIC with TCP (as a percentage) on a network with a 112 ms RTT and 10 ms jitter, which changes the order of packets, the source

Some developers generally call any version of QUIC on UDP "the wildest experiment . "

Differences in QUIC versions and naming are explained by Daniel Stenberg, a leading curl developer working for Mozilla, who has been following this story for a long time.

According to him, the informal names of the two versions of QUIC were spread among the developers, since the options from IETF and Google differ significantly in implementation details:

• iQUIC (IETF version)
• gQUIC (google version)

The protocol for transmitting HTTP over iQUIC (IETF version) has long been called “hq” (HTTP-over-QUIC).

In general, there was no established name for different versions. At the QUIC workshop, Mike Bishop scared everyone with this slide as if it were a logo.


Slide from Mike Bishop's presentation

The seminar leaders asked Mike to never show it again .

Nevertheless, on November 7, 2018, Dmitry Tikhonov, one of the leading protocol developers, announced that LiteSpeed ​​Tech and Facebook had achieved protocol compatibility, and now the development will continue along the same lines.

In September , Mark Nottingham, one of the most influential IETF engineers and co-author of several web standards, suggested combining iQUIC and gQUIC called HTTP / 3 in September. According to him, this will help eliminate confusion between the QIUC transport and the QUIC wrapper for HTTP.

Thus, HTTP / 3 is a new version of HTTP that will use the QUIC transport .

QUIC transport

What are the advantages of the QUIC transport protocol over TCP? There are many advantages, and according to Mark Nottingham himself, the transition from outdated TCP to new protocols is simply inevitable, since it is now clear that TCP suffers from inefficiency problems.

“Since TCP is a packet delivery protocol in order, the loss of one packet can interfere with the delivery of subsequent packets from the buffer to the application. In a multiplexed protocol, this can lead to a large loss of performance, explains Mark Nottingham. "QUIC is trying to solve this problem by effectively rebuilding the TCP semantics (along with some aspects of the HTTP / 2 streaming model) over UDP."



In addition to switching a significant amount of traffic from TCP to UDP, and Google QUIC (gQUIC), and IETF QUIC (iQUIC) require mandatory encryption: an unencrypted QUIC does not exist at all . iQUIC uses TLS 1.3 to set session keys, and then encrypt each packet. But since it is based on UDP, much of the session information and metadata opened in TCP is encrypted in QUIC.

In the article “The Future of Internet Protocols,” Mark Nottingham talks about significant improvements in security with switching to QUIC:

In fact, the current iQUIC “short header” —which is used for all packets except handshaking — gives you only the packet number, an optional connection identifier, and a status byte needed for processes like changing encryption keys and packet type (which can also be encrypted). Everything else is encrypted - including ACK packets, which significantly raises the bar for carrying out attacks with traffic analysis .

In addition, it becomes impossible to passively evaluate RTT and packet loss by simply monitoring the connection; there is not enough information for this.

The lack of observability has caused serious concern among some representatives of the communication operators community. They say that such passive measurements are critical for debugging and analyzing their networks.

One suggestion for solving this problem is the introduction of a spin bit . This is a bit in the header, which changes its value once on the way back and forth, so the observer can evaluate the RTT. Since it is not tied to the state of the application, it should not provide any information about the end points, except for an approximate estimate of the network location.

Perhaps the adoption of the QUIC standard would have happened before, if Google had not rushed to implement its implementation in the Chrome browser, so now the proprietary version of iQUIC accounts for more than 7% of traffic on the Internet.

Nevertheless, progress is inevitable - and in the coming years, standardization and the widespread introduction of various new generation protocols, including HTTP / 3, on QUIC transport, will continue.

---