UDP Reliable Transport - QUIC

1. QUIC protocol

QUIC, namely Quick UDP Internet Connections (Quick UDP Internet Connections), is an experimental network transport protocol proposed by Google, located in the transport layer of the OSI model. QUIC aims to solve the defects of the TCP protocol and eventually replace the TCP protocol to reduce data transmission, reduce connection establishment delay time, and speed up web page transmission.

Standard document address: https://quicwg.org/base-drafts/rfc9000.html

1. QUIC block diagram

1.1 Why QUIC is implemented at the application layer

New transport layer protocols are often rigorously designed, analyzed and evaluated with repeatable results proving the correctness and fairness of the candidate protocol to existing protocols, between the development of a new transport layer protocol and its widespread deployment in operating systems Usually it takes several years.
Furthermore, many firewalls, NAT (address translation), routers and other intermediate devices have to pass between the user and the server, and many of these devices only recognize TCP and UDP. If another transport layer protocol is used, the connection may not be established or the message cannot be forwarded. These intermediate devices will think that protocols other than TCP and UDP are insecure or problematic.

1.2 QUIC Protocol Terminology

QUIC connection: The communication between CLient and Server is concerned, the Client initiates the connection, and the Server receives the connection

Stream: A unidirectional or bidirectional stream of ordered bytes within a QUIC connection. A QUIC connection can contain multiple Streams at the same time

Frame: The smallest communication unit within a QUIC connection. The data part of a QUIC packet (packet) contains one or more frames

1.3 Comparison between QUIC and TCP

2. QUIC message format

2.1 QUIC packet format

Header is plain text and contains 4 fields: Flags, Connection ID, QUIC Version, Packet Number
Data is encrypted and can contain one or more frames. Each frame is divided into type and payload, where payload is application data

2.2 QUIC Stream frame

There are many types of data frames: Stream, ACK, Padding, Window_Update, Blocked, etc. Here we will focus on the Stream frames used to transmit application data.

Frame Type : frame type, occupying 1 byte

Bit7: Must be set to 1, indicating Stream frame
Bit6: If set to 1, it means that the sender has finished sending data on this stream, and the stream will be in a half-closed state
Bit5: If set to 1, it means that the Stream header contains the Data length field
Bit4-2: Indicates the length of offset. 000 means 0 bytes, 001 means 2 bytes, 010 means 3 bytes, and so on
Bit1-0: Indicates the length of Stream ID. 00 means 1 byte, 01 means 2 bytes, 10 means 3 bytes, 11 means 4 bytes

Stream ID : Stream ID, used to identify the stream to which the packet belongs. The following flow control and multiplexing will be involved.

Offset : Offset, indicating the offset of the packet in the entire data, used for data sorting.

Data Length : Data length, occupying 2 bytes, indicating the length of the actual application data.

Data : actual application data

3. Features of QUIC

Connection establishment with low latency
multiplexing
no head-of-line blocking
Flexible Congestion Control Mechanism
connection migration
Authentication and encryption of packet header and data in the packet
FEC Forward Error Correction
reliable transmission
other

3.1 Low latency for connection establishment

3.1.1 Typical TCP+TLS connection

First, perform a three-way handshake to establish a TCP connection (blue part)
Then, perform a TLS handshake and establish a TLS connection (yellow)
Start transferring business data thereafter

Note that the ACK packet in the three-way handshake is sent together with the handshake. This is a delayed acknowledgment technique used in TCP implementations to reduce protocol overhead and improve network performance.

It takes multiple rounds of protocol interaction between the client and the server to establish a TLS connection, and the delay is quite serious. Usually accessing https websites is obviously slower than http websites, and the three-way handshake and TLS handshake are to blame.

3.1.2 Comparison of the first connection

A total of 3RTT: TCP+TLS1.2: TCP three-way handshake to establish a connection requires 1 RTT; TLS requires 2 RTT to complete identity verification; transmit data
A total of 2RTT: TCP+TLS1.3: TCP three-way handshake requires 1 RTT to establish a connection; TLS requires 1 RTT to complete identity verification; transmit data
A total of 1RTT: In the first QUIC connection, the Client sends a message to the Server, requesting the transmission of configuration parameters and encryption-related parameters; the Server replies with its configuration parameters;

3.1.2 Reconnection comparison

The concept of reconnection: Client has visited the server and stored cookies locally.
2RTT: In TCP+TLS1.2: TCP three-way handshake requires 1 RTT to establish a connection; TLS requires 1 RTT to complete identity verification (due to the existence of cache, reduce 1RTT); transmit data
1RTT: In TCP+TLS1.3: TCP three-way handshake to establish a connection requires 1 RTT; data transmission
0RTT: In the second QUIC connection between the client and the server, the client already has all the configuration parameters (cache) of the server locally, based on which the initial key is calculated and the encrypted data packet is sent directly.

3.2 Multiplexing

There are always multiple data to be transmitted in a web page, and it is always hoped that multiple data can be transmitted at the same time, so as to improve the user experience.

3.2.1 HTTP1.1

Each TCP connection can only process one request-response at the same time. In order to improve the response speed, multiple connections need to be created at the same time, but the management of multiple connections is more complicated.

3.2.2 HTTP2

There are multiple logically independent streams in each TCP connection
Each stream can transmit different file data
Solved the problem that one HTTP1 connection cannot transmit multiple data at the same time
Disadvantages: prone to head-of-queue blocking problems

3.2.3 QUIC（HTTP3）

Borrowing from the concept of stream in HTTP2
The streams are independent of each other, that is, the order of delivery of data between different streams is irrelevant (if the data of stream2 is lost, only the data after stream2 will be affected, and the data of stream1 and stream3 will not be affected)
Built on top of UDP, no dependencies

3.3 No head-of-line blocking

HTTP/2 will have the head-of-line blocking problem, but this problem is well solved in QUIC-based HTTP/3.

Each datagram in UDP is independent, and each stream in UDP-based QUIC is independent
Even if a packet in stream2 is lost, because the streams are independent and unrelated to each other, stream3 and stream4 will not be blocked, and they can still be delivered to the upper layer

3.4 Flexible Congestion Control and Mechanism

TCP's congestion control actually includes four algorithms: slow start, congestion avoidance, fast retransmission, and fast recovery.

New Reno: based on packet loss detection
CUBIC: based on packet loss detection
BBR: Based on network bandwidth

The QUIC protocol can set or implement a congestion control protocol by itself.

The QUIC protocol currently uses the Cubic congestion control algorithm of the TCP protocol by default. This mechanism is also pluggable, and it can take effect, change and stop very flexibly, and different methods can be switched according to the scene.

The QUIC protocol is implemented in user space. The application program can realize the change of congestion control without stopping and upgrading. On the server side, only need to modify the configuration and reload, and the congestion control can be switched without stopping the service at all. It is even possible to set a congestion control algorithm for each request.

While TCP is in the kernel state, its congestion control is difficult to modify and upgrade.

3.5 Connection Migration

Connection migration: When the client switches networks, the connection with the server will not be disconnected, and normal communication can still be performed.

This is not possible with the TCP protocol. Because the TCP connection is based on 4-tuples: source IP, source port, destination IP, destination port, as long as one of them changes, the connection needs to be re-established.

However, the connection of QUIC is based on the 64-bit Connection ID, and the network switching will not affect the change of the Connection ID, and the connection is still logically connected. When the IP address or port number changes, as long as the ID remains unchanged, the original connection can still be maintained, and the upper-layer business logic will not perceive the change and will not be interrupted.

The client's Connection ID is unique.

3.6 Authentication and encryption of data packet header and data in the packet

Compared with TCP, QUIC's security is built-in, which means it is necessary.

The performance is similar to TLS in a malicious environment, and better than TLS in a friendly environment, because TLS uses a session key, and if this key is intercepted, the security of previous data cannot be guaranteed.

While QUIC uses two keys - the initial key and the session key, and QUIC provides password protection, TLS does not.

In addition, the header of QUIC is authenticated, and the data in the packet is encrypted. In this way, if the QUIC data is maliciously modified, the receiving end can discover it, reducing security risks.

And after the data is encrypted, it can pass through middleware like firewall or nat.

For the generation of two keys, please refer to: https://blog.csdn.net/chuanglan/article/details/85106706

3.7 FEC Forward Error Correction

FEC is the meaning of Forward Error Correction. It means that by sending more redundant packets, when some packets are lost, they can be recovered through redundant packets without retransmission. This algorithm plays an important role in congestion control of multimedia gateways. QUIC's FEC uses the XOR method, that is, send N + 1 packets, and send one more redundant packet. If any packet is lost in the N packets of normal data, it can be recovered through this redundant packet. Use XOR can be used to switch network management connections.

3.8 Reliable Transmission

QUIC is based on the UDP protocol, and UDP is an unreliable transmission protocol. How does QUIC achieve reliable transmission?

Reliable transmission has two important features:

Integrity: The data packet sent by the sender can be received by the receiver
Orderliness: The receiving end can assemble data packets in order and decode them to obtain valid data

3.8.1 Orderly design

QUIC has an offset field and a StreamID field in each Stream frame, which enables the data received out of order to be arranged in an orderly manner.

3.8.2 Integrity design

The sender confirms the integrity of the sent data through the packet number (PKN) and acknowledgment response (SACK).

Client: Send 3 packets to server (PKN = 1, 2, 3)
Server: Inform the client through SACK that 1 and 3 have been received, but 2 has not been received
Client: Retransmit the 2nd packet (PKN=4)

Although QUIC will retransmit the data packet, the PKN of the new data packet continues to increase, that is, the previously sent data packet (PKN=2) and the retransmitted data packet (PKN=4), although the data is the same, but the packet number different. This also solves the retransmission ambiguity problem caused by the same serial number of the original packet and the retransmission packet in TCP.

Since the serial numbers of the TCP original packet and the retransmission packet are the same, the client does not know whether the ACK packet returned by the server is the original packet or the retransmission packet. However, the sequence numbers of the original packet of QUIC and the retransmission packet are different, so the ownership of the ACK packet can be judged.

4. QUIC open source library

Google's gquic originated the earliest, but it is not a separate project. The code is in the chromium project and written in C++, which may not be very suitable.
Microsoft's msquic, written in C, is cross-platform, but it started relatively late.
Facebook's quic is written in C++. Not considered yet.
The quic of nginx does not have its own client, but it can be jointly debugged with ngtcp2.
Litespeed's lsquic is based on MIT. It started in 2017. It is relatively stable. It is written in C language. All mainstream platforms have passed the test. There are server/client/lib. It is used in various products of its own. For the time being, it looks like is the most suitable.
ngtcp2, which is an experimental quic client, is very concise and implements almost every version of ietf draft. From the point of view of code simplicity, it is undoubtedly the best. At present, open source projects such as srs streaming media server and curl are based on ngtcp2 for secondary development.

4.1 ngtcp2

https://github.com/ngtcp2/ngtcp2
Implemented in C language
The sample client and server use the features of c++17, we need to upgrade the compiler (for example, clang >= 8.0, or gcc >= 8.0)
For the compilation document, see "QUIC Open Source Library Installation and Practice.pdf"

Reference Blog: UDP Reliable Transmission - QUIC - Magic cat - Blog Garden