Let's talk about HTTP/3, QUIC, how do they work?

Why do we need HTTP/3? One important reason is to solve the "header blocking" problem.

Header blocking problem in HTTP/2

HTTP/2 solves the header blocking problem at the HTTP level through frames and streams. However, the problem still exists at the TCP level.

After receiving frames from upper layers, TCP divides them into segments.

If all goes well, all segments will reach the other end.

However, the Internet may be unstable. Some segments may be lost during this process.

TCP has a guaranteed delivery feature. It puts received segments into a buffer and waits for lost segments to be retransmitted, resulting in head-of-line blocking.

To solve this problem, we need to find alternatives to TCP - QUIC and UDP.

Updated protocol stack

A major change can be seen in the protocol stack: TCP is replaced by UDP.

Unlike TCP, UDP does not guarantee delivery and there are no dependencies between segments. This means there is no more head-of-line blocking problem.

In addition, since UDP is a connectionless protocol, no handshake is required. It runs faster than TCP.

Based on UDP, a new protocol QUIC was introduced. It inherits some advantages of TCP, including connection management and flow control. In addition, QUIC implements some functions to ensure data delivery to make up for the shortcomings of UDP.

Another change is that TLS is implemented inside QUIC, while inheriting all its security features. Since TLS 1.3 is already in production, QUIC starts with this version.

Last but not least, QPACK replaces HPACK, further improving the performance of the header compression algorithm. The number of entries in the static table has increased from 61 to 98 and is now 0-indexed.

QUIC packets, frames, and streams

QUIC consists of packets and frames. A packet consists of multiple frames.

Following is the structure of a QUIC packet.

In the packet header, QUIC uses a connection ID to mark its destination and source.

Browsers and servers can choose their IDs. With them, we can decouple connections from IP and port and achieve smooth connection migration.

The following situations may happen to you every day.

When you leave home, your phone switches from WiFi to 4G (and soon 5G). Because the IP changes, TCP reconnects. You will lose connection for a split second before reconnecting to the internet.

With QUIC, the connection ID remains constant, so the connection conceptually remains the same. Although the IP changes, the connection is reused with no reconnection cost.

Next, let's look at an example of a QUIC packet.

QUIC IETF

QUIC connection information

[Data packet length: 1350]

1... .... = Head form: Long head (1)

.1.. .... = Fixed bit: True

..00 .... = Packet Type: Initial (0)

.... 00.. = Reserved: 0

.... ..00 = Packet number length: 1 byte (0)

Version: draft-29 (0xff00001d)

Target connection ID length: 8

Target connection ID: 45fb5955dfaa8914

Source connection ID length: 0

Token length: 0

Length: 1332

Packet number: 1

Load: 5a99e5b29413627619ca3b5add4cf8b6ce348355b1c1a2be9874c7961e7996a24aeec860…

TLSv1.3 Record Layer: Handshake Protocol: Client Hello

Padding length: 997

From the public flag 1100 0000, we can know that it is a long header and its type is initial. Next is the QUIC version: draft-29, and then the target connection ID and its length.

Next, let's look at the QUIC frame structure.

Similar to HTTP/2 frames, there are various frame types in QUIC.

For example, STREAM frames are used to carry streams, while ACK frames are used for control.

Fields in the header use variable length encoding and can be up to 8 bytes.

The number of stream identifiers can be up to 2^62, two of which are reserved for markers.

• The least significant bit marks the sender: 0 for client, 1 for server.
• The second least significant bit marks the direction of the flow: 0 for bidirectional flow, 1 for unidirectional flow.

The following is an example of a frame.

• TLSv1.3 Record Layer: Handshake Protocol: Client Hello
• Frame Type: CRYPTO (0x0000000000000006)
• Offset: 0
• Length: 314
• Encrypting Data
• Handshake protocol: Client Hello
• The frame type is CRYPTO, which is designed for handshakes, and the payload is encrypted data.

Here is another example, Server Hello.

• TLSv1.3 Record Layer: Handshake Protocol: Server Hello
• Frame Type: CRYPTO (0x0000000000000006)
• Offset: 0
• Length: 90
• Encrypting Data
• Handshake Protocol: Server Hello
• Handshake Type: Server Hello (2)
• Length: 86
• Version: TLS 1.2 (0x0303)
• Random number: 0f58bdbd934450c7aa98242121447bef2fe0733aa5fc3beffab6513c7177f9a4
• Session ID length: 0
• Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301)
• Compression method: null (0)
• - Extended Length: 46
• Extension: key_share (len=36)
• Extension: supported_versions (len=2)

Except for the new fields of the QUIC frame, the rest of the fields are mentioned in the TLS 1.3 handshake.

HTTP/3 protocol and framing

QUIC can do a lot of work and reduce the workload of HTTP/3.

For example, unlike HTTP/2, HTTP/3 leverages QUIC streams rather than defining and controlling the streams itself.

Most of the frame types managed in HTTP/2 have moved to QUIC, such as the RST_STREAM frame and the WINDOW_UPDATE frame.

Because of this, the HTTP/3 frame structure is simplified to only 2 fields - frame type and length.

One thing worth mentioning is that HTTP/3 does not have a designated port like port 443 for HTTPS.

The browser first establishes a connection with the server using HTTP/2 to discover the service. The server responds to the request with an Alt-Svc header that includes the port for HTTP/3, such as Alt-Svc: h3-29=":443". With this information, the browser connects to that port asynchronously. Once the connection is established, future communications will be conducted using HTTP/3.