The evolution of QUIC protocol

A new protocol, QUIC (Quick UDP Internet Connection), is becoming the default choice for FAANG when transferring data over the network. This article describes how the QUIC protocol stands out over the limitations of other versions of HTTP.

FAANG is an acronym for five of the most popular and best-performing tech stocks in the U.S. market: Facebook, Apple, Amazon, Netflix and Google.

The evolution of HTTP

HTTP is an application-layer transport protocol that runs on top of TCP/IP. It is now the basis for data exchange on the World Wide Web. HTTP comes in four stable versions: HTTP/0.9, HTTP/1.0, HTTP/1.1, and HTTP/2. HTTP/3 was first introduced in 2018 and is now supported by two-thirds of the world’s web browsers.

HTTP / 0.9 (1991).

HTTP/0.9 is the first version of HTTP and serves as the W3C’s underlying communication protocol. It is a very simple client-server, request-response, protocol using Telnet that supports only the GET command (as the request method) and the hypertext protocol (as the response type). The protocol does not contain HTTP headers, and the connection is immediately broken after a response is sent.

HTTP / 1.0 (1996).

HTTP/0.9 is extremely simple and very limited to use. The new HTTP version, HTTP/1.0, introduced many new features to make it more generic. These new features include:

• The TCP connection is re-established with each HTTP request/response

• Added support for POST and HEAD methods

• The protocol header contains the version number, protocol type, and status code fields

• Response type: hypertext, script, media, style sheet

• Keep-alive connections are supported, but by default they are “off”

HTTP / 1.1 (1997).

The main drawback of HTTP/1.0 is that it requires a new TCP connection to be established every time a request \ response is made. This is time-consuming and affects client and server performance. HTTP/1.1 came along to solve this problem:

• Multiple HTTP requests and responses can be transmitted over a single TCP connection

• Added support for PUT, DELETE, TRACE, and OPTIONS methods

• Default persistent connection

HTTP / 2 (2015).

As more content is streamed, sites are becoming more complex. To meet this need, HTTP/1.1 has expanded: support for multiple TCP connections has been introduced for the first time, and pipelining, which allows clients to send multiple requests simultaneously within the same TCP connection, has been introduced on an experimental basis. ** But extensions can’t be endless, and eventually a new protocol was needed, hence HTTP/2, which includes the following major improvements:

• Multiplexing: This is a feature of HTTP/2 that allows multiple request-response messages to be initiated simultaneously over a single TCP connection. Each HTTP request-response is split into binary frames, and both the client and server send messages (request and response) in binary frames. With multiplexing, clients can send multiple requests without waiting for the last request to complete. Thus, HTTP/2 solves the HTTP queue header blocking (HoL) problem. As shown in the figure:

• Header compression: Compress headers using HPACK

• Non-blocking download

• Server push

• Binary frames are used instead of plain text

• Solved the team head blocking problem

HTTP / 3 (2018).

By multiplexing, HTTP/2 solves the problem of queue head blocking. But if there is a packet loss in a TCP stream, the other data flows have to wait for the packet loss to be resend and received, according to TCP’s congestion control mechanism. So, TCP’s queue header blocking problem still exists in HTTP/2.

HTTP/3 solves this problem by using QUIC, a UDP-based transport protocol.

HTTP/3 is the latest and most important version of HTTP since HTTP/2. Because HTTP/3 was itself designed for the QUIC protocol, it has also been described as QUic-based HTTP/2. The goal of HTTP/3 is to provide fast, reliable and secure network connections using Google’s QUIC protocol. HTTP/3 includes the following features:

• Using QUIC based on UDP as the transport protocol

• Solves the TCP queue header blocking problem

• Use the QPACK header compression mechanism

• Provides faster page load times

HTTP/2 VS HTTP/3

Here is a comparison of HTTP/2 and HTTP/3:

Similarities:

HTTP/2 and HTTP/3 use the same syntax and semantic structure, and apply to the same request/response method, status code, and protocol fields. In addition, both use header compression algorithms (HPACK and QPACK) of similar design.

Difference:

QUIC is a new multi-transport layer network protocol standard, based on UDP. The main goal of QUIC is to improve the user experience by reducing page load times and improve HTTPS transport performance. It is essentially TCP+TLS+HTTP/2.

HTTP/3 was designed to take full advantage of QUIC. The QUIC protocol handles the data flow itself, so it eliminates the TCP queue header blocking problem.

Some of the key features of QUIC include:

• Based on UDP

• Use connection multiplexing without queue head blocking

• Refactoring the key mechanisms of TCP (connection multiplexing, connection establishment, congestion control, reliability) into a reliable transport protocol

Switch packets

For a typical QUIC protocol, there are three types of packets exchanged between the client and the server, as shown in the figure below:

QUIC connection set up and secure net purse

1. Secure first pack

First, the Client transmits the first packet containing the TLS 1.3 Client Hello in a CRYPTO frame. Client Hello contains different types of extensions, such as Server Name Indication (SNI) for the target Server, QUIC transmission parameters, compression certificates, and compression methods and encryption suites supported by the Client.

If the Server accepts QUIC and TLS 1.3 parameters, it will also send a first packet containing the client’s first packet acknowledgement and the TLS 1.3 Server Hello in the CRYPTO frame. The Server Hello contains the encryption suite received by the Server and the different extensions (such as key sharing, supported versions, and so on). When the client receives the Server Hello, it sends an ACK packet to the Server.

Each of these first packets may contain a fill frame to increase the size of the packet as needed.

2. The package

After the first packet is exchanged between the client and server, the server sends a handshake packet containing the remaining server-side messages, such as certificates and encryption extensions associated with server authentication. The client validates these certificates, and the QUIC handshake ends with a handshake message sent by the client.

3. Safe purse

Once a secure QUIC connection is established, information can be transferred securely between the client and the server.

QUIC 0-RTT

To reduce the time it takes to establish a new connection, QUIC uses 0-RTT. Here, if the client previously connected to the server using 1-RTT, the server must store copies of the transmission parameters related to flow control, such as initial_MAX_DATA, initial_max_stream_data_bidi_LOCAL, etc.

Next time, in QUIC 0-RTT mode, the client immediately starts transferring data to the server without waiting for the handshake to complete.

However, 0-RTT also has a design flaw: it allows replay attacks.

Why do we use QUIC?

The traditional TCP protocol is built on the operating system layer and intermediate routing module, its handshake phase information is easy to be tampered with by these intermediate modules and become insecure.

But the QUIC protocol is implemented on top of UDP at the user level, such as a browser, so it is more flexible, user-friendly, and can support more devices in a short period of time.

In QUIC, the information associated with the transmission is encrypted by different protection layers, and the handshake packet is not easy to identify and modify over the transmission link. Therefore, it provides more secure network data transmission.

Read on:

QUIC Version 1 (RFC 9000) is now available as a standardized Version

Understand WebTransport

QUIC helps Snapchat improve the user experience

Next generation live transmission Protocol SRT

** 30 years TCP and 7 years QUIC who is the future? * * * * * *

Translation/Alex

Technology Review/Yuan Rongxi

Link to original article:

Blogs.keysight.com/blogs/tech/…

Special note: Thanks to the original author, Anubhab Sahu, for authorizing the translation and publication of this article.

Please scan the QR code for more information.