QUIC – a new transport communication protocol that features reduced latency, greater reliability and security than the one widely used today TCP (RFC 793).

A lot has already been said about the advantages of the QUIC transport, which is taken as the basis for the future HTTP / 3 standard. In next-generation HTTP, the TCP transport is changed to QUIC, which means automatically speeding up connections and encrypting all Internet traffic that used to go in clear text over TCP. Unencrypted QUIC is not provided at all.

In May 2021, a significant event took place: the QUIC protocol was adopted as the official standard RFC9000… This is great news for the entire internet ecosystem.

Such standards are approved by Internet Engineering Council (IETF). Ancillary standards were previously issued RFC 9001, RFC 9002 and RFC 8999…

Thus, QUIC version 1 is now officially accepted and approved. All parties involved can finish experimenting with draft minutes and go to first official version…

QUIC has been one of the top priorities for the IETF in recent years. Appearing as a Google experiment, soon QUIC development went to the international level. It was conducted almost five years… Fixed 26 face-to-face meetings, 1749 problems in the tracker and many thousands of letters in the mailing list.

QUIC is a very ambitious project that will bring big changes. “The transport ecosystem of the Internet has become ossified for several decades, and QUIC will revive it”, – write Fastly engineers who are part of the protocol development working group.

Ossification means that every year the system becomes less flexible, less mobile. QUIC will bring many innovations to the transport layer, including mandatory encryption, versioning, a much richer and more productive set of services on top of which new technologies will be built. QUIC is expected to lead to the next generation of internet innovation. This is already beginning happening with extensions such as untrustworthy datagrams (Unreliable Datagram Extension). Untrustworthy datagrams open the door to a new class of real-time media and other applications that need more functional transport than obligatory packet delivery with a drop in the link when a few pixels are lost. We are already seeing promising technologies such as MASQUE and WebTransport…

HTTP / 3

Standard HTTP / 3 (this is HTTP over QUIC) comes with a slight delay behind QUIC and will also be officially adopted in the very near future.

34th (!) Draft HTTP / 3

Six years have passed since the adoption of HTTP / 2: the specification RFC 7540 published in May 2015, but not widely used yet. The protocol has been implemented in all browsers since the end of 2015, and after three years only 45.4% of the 10 million most popular internet sites support HTTP / 2. Two and a half years ago, this figure was 31.2%. Recently, the sites of Amazon, Paypal, Telegram.org moved to HTTP / 2.

Now the third version of HTTP / 3 is almost ready, it remains quite a bit to wait.

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

Then the development of QUIC was submitted to the IETF for standardization. Here it is divided into two parts: transport and HTTP. The idea is that the transport protocol can be used to transfer other data as well, not just exclusive to HTTP or HTTP-like protocols. However, the name remained the same: QUIC. The transport protocol is being developed by the QUIC Working Group in the IETF.

For a long time, the IETF version was called iQUIC, while Google and others continued to work on their own implementation of gQUIC, but on November 7, 2018, one of the leading developers of the protocol, Dmitry Tikhonov announcedthat the parties have achieved protocol compatibility, and now the development will continue in the general direction. QUIC in Chrome is enabled in the settings chrome: // flags… There is also an indicator extension that shows which sites support QUIC.

Built-in security and performance

What are the advantages of the QUIC transport protocol over TCP? There are many advantages. The move from legacy TCP to new protocols is inevitable, according to working group leader Mark Nottingham, as it is now clear that TCP is suffering from inefficiencies.

“Because TCP is a sequential packet delivery protocol, the loss of one packet can prevent the application from delivering subsequent packets from the buffer. 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 TCP semantics (along with some aspects of the HTTP / 2 streaming model) over UDP.”

In addition to the transition of a significant amount of traffic from TCP to UDP, the QUIC protocol requires mandatory encryption: an unencrypted QUIC does not exist at all. QUIC uses TLS 1.3 to set session keys and then encrypt each packet. But since it is UDP based, much of the session information and metadata exposed in TCP is encrypted in QUIC.

In The Future of Internet Protocols, Mark Nottingham talks about the significant security improvements with the move to QUIC:

Actually current “Short title” iQUIC – which is used for all packets except for the handshake – only gives out the packet number, an optional connection identifier, and the 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 conducting traffic analysis attacks…
In addition, it becomes impossible to passively estimate RTT and packet loss by simply observing the connection; there is not enough information for this.
The lack of observability has raised serious concerns among some in the carrier community. They say such passive measurements are critical for debugging and analyzing their networks.
One suggestion for solving this problem is an introduction spin bit… This is a bit in the header that changes its value once on the way back and forth, so that the observer can estimate the RTT. Since it is not tied to the state of the application, it should not provide any information about the endpoints, other than a rough estimate of the network location.

Perhaps the adoption of the QUIC standard would have happened earlier, if Google had not rushed to implement its implementation in the Chrome browser, so a “bifurcation” of the standard happened.

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