In the previous two articles, we briefly introduced the development history, advantages and connection principles of QUIC protocol. This article will take a specific QUIC message as an example to introduce in detail the structure of the QUIC message and the meaning of each field.
There are many early versions of QUIC, mainly gQUIC from Google, IETF QUIC (iQUIC), which is committed to standardizing QUIC, and mvfst from Facebook . In the early days, each company's QUIC had its own customized fields, but overall they were similar.
Unlike TCP, which has a fixed header format, QUIC has two types of headers. The QUIC packet that establishes the connection needs to contain a lot of information, and it uses a long header format. Once a connection is established, only certain header fields are required, and subsequent packets use the short header format for efficiency.
1: gQUIC early version Q043 and below headers
The public headers of gQUIC versions Q043 and below are different from those of versions Q044 and later, and are different from the latest public headers.
The first 8 bits are public flag bits, some of which have the following meanings:
| 0x01 |
Whether the Packet contains QUIC Version |
| 0x02 |
Whether Packet is Public Reset Packets |
| Two bits of 0x0C |
The length of the Connection ID (0/8/32/64 bits) |
| Two bits of 0x30 |
Packet number length (8/16/32/48 bits) |
Connection ID: A 64-bit unsigned integer generated by the client, identifying a unique connection. The length of the Connection ID can be negotiated with the server. When the client roams and the IP 4-tuple cannot identify a connection, the Connection ID can be used to identify a connection. This field may be omitted when an IP 4-tuple can identify the connection.
Version: 32-bit version number. When the version proposed by the client is not supported, the server can set the version flag and provide a list of acceptable versions.
Packet Number: Packet number. Each ordinary packet (as opposed to the special public reset and version negotiation packets) is assigned a packet number by the sender. The packet number of the first packet sent by a certain end should be 1, and the packet number of each subsequent packet should be 1 greater than the previous one.
The Q043 and lower versions of gQUIC do not have the later long and short headers, and the format of their headers is unified. However, in order to be compatible with mainstream QUIC, after the Q044 version, the public header adopts the form of long header and short header.
2: QUIC long Baotou
With the release of QUIC RFC 9000 in May 2021, it is supported by RFC 9001, RFC 9002 and RFC 8999 (among them, RFC8999 defines the QUIC protocol version-independent specification, RFC9001 defines the protocol mapping between QUIC and TLS, and RFC9002 defines the QUIC protocol loss recovery and congestion control). This means that QUIC Version 1 has been officially standardized, and QUIC deployments will move from using the interim draft version to the newly created Version 1. At the same time, the latest news points out that QUIC Version 1 is released as a new Internet transmission technology as a standard, which can improve the performance, security and privacy of web applications.
With the announcement of the QUIC standardized version, Facebook, Akamai, Microsoft, Cloudflare, Ericsson, F5, Fastly and Google have already deployed QUIC and HTTP/3. At this point QUIC has entered an era of unification.
Why should I introduce the above background? Because before RFC9000 came out, QUIC's long and short headers were not only different between major manufacturers, but also the formats of different versions of QUIC headers were different even from the same manufacturer such as Google. This has stopped developing. Let’s take a look at the long header of RFC9000.
The most obvious sign is that the high bit of the first byte is set to 1. All other bits in this byte are version specific. In addition, Packet Type occupies two digits, and its values are as follows:
Version: Four bytes, including a 32-bit version field. The Version of RFC9000 is 1. In fact, it can be understood that this is the first version after QUIC standardization.
Destination Connection ID Length: The length in bytes of the destination connection ID field. This length is encoded as an 8-bit unsigned integer.
Destination Connection ID: Destination connection ID field, length between 0 and 160 bytes.
Source Connection ID Length: The byte length of the source connection ID field. This length is encoded as an 8-bit unsigned integer.
Source Connection ID: Source connection ID field, length between 0 and 160 bytes.
The remainder of the packet contains version-specific content.
Three: QUIC short toe
The format of the short header is as follows:
QUIC packets with short headers have the high-order bit of the first byte set to 0.
QUIC packets with short headers include the destination connection ID immediately following the first byte. The short header does not include the destination connection ID length, source connection ID length, source connection ID, or version fields. The length of the destination connection ID is not encoded in packets with short headers and is not subject to this specification.
The rest of the packet has version-specific semantics