In-depth analysis of QUIC protocol: the cornerstone of HTTP/3 high-speed transmission

Estimated read time 14 min read
In-depth analysis of QUIC protocol: the cornerstone of HTTP/3 high-speed transmission

HTTP/2 is the latest network transmission protocol (as shown on the left in the picture above), which is mainly composed of TCP + TLS 1.2 + HTTP. As time goes by, more and more network traffic is moving to mobile devices. The wireless network environment of mobile phones will encounter problems such as (1) high packet loss rate, (2) long round trip time (RTT) ) and (3) connection migration issues, etc., have caused the HTTP/TCP protocol, which is mainly designed for wired networks, to encounter bottlenecks.

Therefore, Google released a new transmission protocol QUIC (pictured above, right) in 2013, whose full name is Quick UDP Internet Connection. Different from HTTP/2, QUIC uses the less reliable UDP as the transport layer, and implements packet loss recovery and congestion control on the QUIC layer, and introduces new designs to support multiplexing and reduce connection handshake delays. , resolve retransmission ambiguities and support connection migration, etc. The reason why the TCP protocol is not directly modified is mainly because TCP and UDP are mostly implemented in the core of the operating system and cannot be quickly upgraded and widely adopted, so they are directly implemented on the upper layer of UDP, which is already supported by the current system. Use hands and feet.

The IETF’s QUIC working group renamed QUIC to HTTP/3 in 2018, preparing to establish QUIC as the standard for the next generation transport protocol. Among them, the IETF has made some changes to QUIC, such as changing QUIC into a more general transmission protocol. In addition to supporting HTTP, it also supports SMTP, DNS, SSH, etc. The original QUIC Crypto encryption mechanism in QUIC was also replaced by TLS 1.3.

In Google’s documentation on QUIC, it is mentioned that compared with HTTP/2, QUIC mainly has the following advantages:

  • Reduce connection establishment latency (reduce the time it takes to establish a connection)
  • Improved congestion control (enhanced network congestion management)
  • Multiplexing without head-of-line blocking
  • Forward error correction
  • Connection migration (no need to re-establish connection when switching between WIFI and 4G networks on the move)

The following five mechanisms of QUIC will be introduced respectively:

  1. Connection Establishment
  2. Multiplexing
  3. Loss Recovery
  4. Flow Control
  5. Connection Migration

Connection Establishment

In-depth analysis of QUIC protocol: the cornerstone of HTTP/3 high-speed transmission

The original TCP/IP protocol performs the famous Three-Way Handshake on each connection, which takes a total of 1.5 RTT. If the transmission time of TLS is added, the establishment of the entire connection will take 3 RTTs each time, as shown in the left figure above. In the past era of slow transmission speeds, optical data transmission took a very long time, and the proportion of time spent establishing a connection was insignificant. But now that the transmission speed is getting faster and faster, the time spent transmitting data in each connection is getting shorter and shorter, so the time spent on handshaking during the connection has an increasing proportion of the impact on the transmission performance. big.

QUIC therefore proposes a new connection establishment mechanism. The initial connection handshake and key exchange only take 1 RTT, as shown on the right in the above figure and the left in the figure below. By caching the initial connection handshake key on the client, starting from the second connection, each subsequent connection can directly start transmitting data, as shown in the figure below, achieving the advantage of zero handshake latency (0-RTT Handshake Latency). Transfer data directly within an authenticated and encrypted channel.

In-depth analysis of QUIC protocol: the cornerstone of HTTP/3 high-speed transmission

The establishment of a QUIC connection is mainly divided into two steps: (1) initial handshake and (2) final and repeated handshake. These two steps are introduced in detail below.

Initial handshake

During the connection initialization phase, the client first sends a “Client Hello” (CHLO) message to the server to start the handshake process. Subsequently, the server will respond with a REJ (Reject) packet, which encapsulates four key pieces of information:

  1. Server Config: Contains the server’s long-term DH public key (Diffie-Hellman Public Key)
  2. Certificate Chain: The certificate chain used to authenticate the server
  3. Signature of the Server Config: Digitally signed Server Config allows the client to verify that the information is indeed sent by the server.
  4. Source-Address Token: Client IP information after authentication and encryption

After the client receives the REJ, according to the definition of QUIC, the two parties have completed the handshake and can begin to transmit data securely. Why is this? Let’s see what information the client gets from REJ:

  1. Server authentication: Through the certificate chain and digital signature, the client can verify the authenticity of the server and the reliability of the data.
  2. Initial Key: After receiving the REJ, the client must first randomly generate its own short-term DH key for this connection. After calculating its own short-term key and the server’s long-term public key, it can Get an initial key. (The key exchange here uses Diffie–Hellman key exchange)

After having the initial key (temporary key), the client can use this key to encrypt the data (request) it wants to transmit and send it to the server securely. In addition to encrypting the data, the client must also put the public key corresponding to the short-term DH key it just generated into a package called Complete CHLO, encrypt it with the request data with the initial key and send it back to the server. , as shown on the left in the picture above. Therefore, the server that gets the Complete CHLO package has both the client’s short-term DH public key and its own long-term DH key. The server can also get the same initial key as the client through the same calculation. Used to encrypt and decrypt data.

Final and Repeat Handshake

If everything goes well, the server will generate a packet called SHLO (Server Hello), which contains the server’s newly generated short-term DH public key. After that, the server will encrypt the requested response data and the generated SHLO packet with the initial key, and then send them back to the client together, as shown in the left figure above. At this time, the client and the server have already conducted a data exchange using the initial key, and exchanged each other’s short-term DH public keys under the encryption protection of the initial key. It is important to mention here that the short-term DH public keys and keys on both sides are newly generated specifically for this connection. Each time a connection is established, a new short-term DH public key and key will be generated. The next thing to do is to replace the initial key.

After all, the initial key is generated based on the server’s long-term DH public key. Before the public key expires, almost all connections use the same public key, which has the possibility of being compromised to a certain extent. In order to achieve forward secrecy (Forward Secrecy) security, the client and the server will use the short-term DH public key exchanged with each other and perform an operation with the short-term DH key they have saved to generate a short-term DH key that is limited to this connection. Forward-Secure Key, subsequent data encryption and decryption will use this new key to achieve forward secrecy security. This completes the final key exchange, connection handshake, and QUIC connection establishment.

When the connection is re-established next time, the client will use its previously cached server’s long-term public key, plus its newly selected short-term key, to regenerate an initial key that is different from the previous one, directly in the initial key. Send the request to the server under protection to achieve a zero-RTT Handshake Latency connection, as shown in the figure above. When the server’s long-term public key expires, the server will retransmit a new REJ packet and re-handshake with the client, which will only take 1 RTT in total, as shown on the right side of the figure above.

Stream Multiplexing

When a packet transmitted by a TCP connection is lost, the transmission of the entire connection will be stuck before the sending end actively discovers and resends it. This is the TCP Head of Line Blocking problem.

Because QUIC supports data transmission of multiple Streams in the same connection, when a packet in a certain Stream is lost, only the transmission of this Stream will be affected, and other Streams can continue to process data without being affected at all. transmission to avoid HOL Blocking. QUIC’s Stream Multiplexing has the following features:

  1. Each Stream can be used to transfer a small amount of data, or up to 264 bytes of data.
  2. Each Stream has its own Stream ID. In order to avoid conflicts, the Stream initiated by the client has an odd number, and the Stream initiated by the server has an even number.
  3. Directly using a new Stream ID to transmit data will open a new Stream. When closing a Stream, you need to set the FIN bit in the Stream Frame to true. If the Stream is closed, lost packets will not be retransmitted.
  4. The data to be transmitted by each Stream is encapsulated in one or multiple Stream Frames for transmission.
  5. QUIC packets transmitted in QUIC connections can carry multiple Stream Frames at the same time. Each Stream Frame may come from a different Stream.

Loss Recovery

In the past, the approach used by TCP in packet loss recovery strategy was to mark each data packet with a sequence number at the sending end. When the receiving end received the data packet, it would send back an ACK data with the corresponding number. The packet is sent to the sending end to inform the sending end that the data packet has been indeed received. When the sender has not received the returned ACK after a certain period of time (Retransmit Timeout, RTO), it will consider that the data packet has been lost, start the resend mechanism, copy the same number as the original and resend the data packet to ensure No packets are missed on the receiving end.

What are the disadvantages of such a mechanism? Assume that the sender sends the same data packet twice in total (initial + retransmission), using the same sequence number: number N. Later, when the sender gets the return ACK of the data packet numbered N, it will not be able to determine whether the ACK with number N is the ACK sent back by the receiving end after receiving the initial data packet (longer RTT), or whether it is the ACK sent back by the receiving end after receiving the initial data packet (longer RTT). The ACK (shorter RTT) sent back after receiving the retransmission packet is the TCP retransmission ambiguity problem. If the judgment of whether the ACK belongs to the initial data packet or the retransmitted data packet is wrong, it will cause the TCP algorithm to sample and predict the actual RTT (Round Trip Time) in the connection channel, and affect the judgment of the subsequent congestion control algorithm. If the RTT is unrealistically amplified, the RTO will grow exponentially as the RTT increases, seriously prolonging the response time for packet retransmission.

In order to avoid the problem of retransmission ambiguity, QUIC uses a new number, unique packet number, for each initial and retransmitted data packet when the sender transmits the data packet. Each number is unique and strictly incremented, so that every time When an ACK is received, it can be clearly determined based on the number whether the ACK comes from the initial data packet or a retransmitted data packet. The receiving end uses the Stream ID and Stream Offset values ​​in the data packet to identify which Stream the data packet belongs to, and then reorganizes the data in order according to the Offset of each data packet. To put it simply, the information of the packet transmission sequence and packet data position (offset), which was originally handled by the sequence number, is split into two numbers, the unique packet number and the Stream Offset, which are recorded separately. This solves the problem of retransmission at the same time. The problem of ambiguity and packet reassembly greatly improves the accuracy of RTT sampling and prediction, and reduces the response time of packet retransmission as much as possible.

Flow Control

Through flow control, the amount of data transmitted by the client can be limited. With flow control, the receiving end can only retain a receiving buffer of a corresponding size, optimizing the space occupied by the memory. But if there is a Stream with extremely slow traffic, just one Stream may occupy all the buffers on the receiving end. In order to avoid this potential HOL Blocking, QUIC uses connection layer (connection flow control) and Stream layer (stream flow control) flow control to limit the maximum buffer size that a single Stream can occupy.

Stream Flow Control

In-depth analysis of QUIC protocol: the cornerstone of HTTP/3 high-speed transmission

The receiving end can set the max flow control receive window (max receive window) of the Stream according to its own needs. The larger the max receive window, the larger the buffer size that the receiving end needs to retain. The receiving end can set the maximum flow control receive window (max receive window) of the Stream according to its own memory size and Make appropriate settings for how busy the service is. The newly created Stream is as shown in the figure. Since no data has been transmitted yet, the size of the receive window will be consistent with the size of the max receive window. Flow Control restricts the sender to only send data with an offset within the receive window, that is, it can only send data with an offset from 0 to the flow control receive offset (receive offset), ensuring that the sender will not send data larger than the receiver buffer. The amount of data that can be tolerated.

In-depth analysis of QUIC protocol: the cornerstone of HTTP/3 high-speed transmission

After the sender transmits some data, as shown in the figure, we can see that the size of the receive window gradually shrinks as the highest received byte offset moves to the right. In such a situation, the receiving end can only receive data whose offset is located in the receive window or within the gaps area. There may be two reasons for gaps. One is that the order in which data packets arrive at the receiving end is different due to different transmission rates. The other is that the data packet is lost during transmission and must wait for the sender to retransmit it.

In-depth analysis of QUIC protocol: the cornerstone of HTTP/3 high-speed transmission

As shown in the figure, as consumed bytes (green area without gaps) increases, when the following conditions are met: (flow control receive offset – consumed bytes) < (max receive window / 2)

The receiving end will send a WINDOW_UPDATE signal to the sending end and update the flow control receive offset = (consumed bytes + max receive window), as shown in the figure, allowing the sending end to transmit more subsequent data. It can be noticed that the receive window is still smaller than the max receive window, ensuring that the sender will not transmit an amount of data larger than the buffer of the receiver can bear.

In-depth analysis of QUIC protocol: the cornerstone of HTTP/3 high-speed transmission

Connection Flow Control

The flow control of the connection layer uses exactly the same mechanism, but the calculation of byte consumed and highest received byte offset is the sum of all Stream data, as shown in the following two figures.

In-depth analysis of QUIC protocol: the cornerstone of HTTP/3 high-speed transmission
In-depth analysis of QUIC protocol: the cornerstone of HTTP/3 high-speed transmission

Connection Migration

Currently, to identify a TCP connection, four parameters including (1) source IP, (2) source port, (3) destination IP and (4) destination port need to be used to distinguish which TCP connection the received data packet belongs to. The disadvantage of this mechanism is that when the client’s IP changes, for example, the mobile phone transfers from a WIFI connection to a 4G network connection, all the original connections will become invalid. This makes the TCP protocol very unfriendly when using mobile phones that frequently switch between WIFI networks and different 3G and 4G networks.

Therefore, in order to smoothly handle the Connection Migration problem during the transmission process, QUIC uses a 64-bit independent Connection ID for connection identification. The ID is randomly generated by the client when establishing a connection. When the client’s IP changes, as long as the client continues to use the old Connection ID to transmit data packets, even if the source IP address of the newly sent data packet is different, the receiving end can successfully identify the connection to which the new data packet belongs through the Connection ID. The data packets that are originally being transmitted and contain the old IP can also be identified by the Connection ID and correctly received by the receiving end.


The above is an introduction to the QUIC protocol, introducing its Connection Establishment, Stream Multiplexing, Loss Recovery, Flow Control and Connection Migration mechanisms respectively.

You May Also Like

More From Author

+ There are no comments

Add yours