Let's see how to learn network protocols through the QUIC protocol

This article will take you to understand the QUIC protocol, and take the QUIC protocol as an example to talk about how to learn network protocols. I hope it will be helpful to everyone!

In a previous article about s2n-quic, a reader asked me how to learn a network protocol like QUIC. For most Internet practitioners, although they deal with the Internet every day, few people care about the details of the network protocol under HTTP. Most of the time, it is enough to have a general understanding and know how to use it. . If you have no idea about QUIC, then the following picture can help you have a good understanding of QUIC’s position in the HTTP/3 ecosystem:

So, if you I just want to learn more about QUIC. How to get started?

As a former developer of network protocols and network equipment, my own experience is: start with RFC, supplemented by wireshark packet capture, to quickly master the target protocol.

For QUIC, the first thing we need to read is RFC9000. Reading the agreement is very boring and requires a certain amount of patience. If your English is not very good, you can use Google Translate to translate it into Chinese and browse it quickly (extensive reading). The first reading is mainly to understand the main concepts and main processes.

After that, we can write a program using the QUIC protocol, and then capture the packets through wireshark. By studying the actual messages and comparing them with the contents of the RFC protocol (intensive reading), we can gain a deeper understanding of the essence of the protocol.

We still build the echo client and server based on the code in the previous article. To make it easier for everyone to read, I've also posted the code. Interested students can clone my repo and run the client/server code.

Client code (seegithub: tyrchen/rust-training/live_coding/quic-test/examples/client.rs):

Server code (seegithub: tyrchen/rust-training/live_coding/quic-test/examples/server.rs):

These two pieces of code build the simplest echo server. We can use wireshark to monitor UDP packets under the local loopback interface and capture packets. It should be noted that for traffic using the TLS protocol like QUIC, even if the packets are captured, only the first few packets may be readable, and subsequent packets are encrypted and cannot be read. Therefore, when we build client/server, we need to find a way to capture the session key negotiated between the server and the client for wireshark to decrypt. Generally, SSL/TLS libraries provide this function. For example, for Rustls, we can use key_log in tls config. If you look carefully at the server code above, you will see this sentence:

let config = Builder::new() .with_certificate(CERT_PEM, KEY_PEM)? .with_key_logging()? # 使能 keylogging .build()?;

After using key_log, when starting the server, we only need to specify SSLKEYLOGFILE:

SSLKEYLOGFILE=session.log cargo run --example server

In After the packet capture is completed, open the wireshark preference, select the TLS protocol, and put the log path in:

The following is a complete interaction between the client and the server Capturing the packet, we see that all "protected payloads" are displayed normally:

Because our echo client only does the simplest action (only opens A bidirectional stream), so through this packet capture, we can focus on studying the process of establishing a connection by the QUIC protocol.

The first packet sent by the client

Let’s look at the first packet sent by the client:

This message contains very rich information. First of all, unlike the TCP handshake, the first packet of QUIC is very large, as much as 1200 bytes (the protocol requires UDP payload at least 1200 bytes), including the QUIC header, a 255-byte CRYPTO frame, and 890-byte PADDING frame. As you can see from the header, the type of this QUIC package is Initial.

QUIC message type

For QUIC packets, the Header is plain text, and all subsequent frame payloads are ciphertext (except for the header several packages). We see that this first packet is a Long Header message. In Section 17.2 of RFC9000, Long Header Packet is defined:

Long Header Packet { Header Form (1) = 1, Fixed Bit (1) = 1, Long Packet Type (2), Type-Specific Bits (4), Version (32), Destination Connection ID Length (8), Destination Connection ID (0..160), Source Connection ID Length (8), Source Connection ID (0..160), Type-Specific Payload (..), }

If you are interested, you can read the corresponding chapter of RFC by yourself. For Long Header messages, there are the following types:

既然有 Long Header packet，那么就有 Short Header packet，Short Header packet 目前的版本只有一种：

1-RTT Packet { Header Form (1) = 0, Fixed Bit (1) = 1, Spin Bit (1), Reserved Bits (2), Key Phase (1), Packet Number Length (2), Destination Connection ID (0..160), Packet Number (8..32), Packet Payload (8..), }

为什么需要 connection id？

在我们捕获的这个报文头中，我们看到有 Source Connection ID（SCID）和 Destination Connection ID（DCID）这个新的概念。你也许会好奇：QUIC 不是基于 UDP/IP 的协议么？底层的协议已经有五元组（src ip / src port / dst ip / dst port / protocol）来描述一个连接（connection），为什么还需要 connection id 这样一个新的概念？

这是为了适应越来越多的移动场景。有了 QUIC 层自己的 connection id，底层网络（UDP/IP）的变化，并不会引发 QUIC 连接的中断，也就是说，你从家里开车出门，即便手机的网络从 WIFI（固网运营商分配给你的 IP）切换到蜂窝网络（移动运营商分配给你的 IP），整个 UDP/IP 网络变化了，但你的 QUIC 应用只会感受到细微的延迟，并不需要重新建立 QUIC 连接。

从这个使用场景来看，QUIC 底层使用无连接的 UDP 是非常必要的。

首包中就包含了 TLS hello？

我们接下来看看 CRYPTO frame：

可以看到，QUIC 在建立连接的首包就把 TLS Client Hello 囊括在 CRYPTO frame 中。并且使用的 TLS版本是 1.3。在 Client Hello 的 extension 中，QUIC 协议使用了一个 quic_transport_parameters 的 extension，用来协商 QUIC 自己的一些初始值，比如支持多少个 stream，这个连接中可以最多使用多少个 active connection id 等等。

QUIC 支持哪些 frame？

现在我们已经见到了两种 Frame：CRYPTO 和 PADDING。下表中罗列了 QUIC 所有支持的 frame：

服务器的回包

我们来看 server 的回包：

这里有一些新东西。首先，一个 UDP 包内部可以包含若干个 QUIC payload，我们看到 server 回复了一个 QUIC Initial 报文和一个 QUIC Handshake 报文。在 Initial 报文中，我们看到了一个 ACK frame，可见 QUIC 虽然构建于 UDP，但在 QUIC 协议内部构建了类似 TCP 的确认机制。

我们之前看到，在 Initial 报文的 CRYPTO frame 中，客户端发送了 TLS Client Hello，同样的，服务器在 Initial 报文的 CRYPTO frame 中发送了 TLS Server Hello。这个我们就略过不看。

在 Handshake 报文中：

服务器发送了自己的证书，并结束了 TLS handshake。

客户端结束 Handshake

我们再看第三个包，客户端发送给服务器结束 TLS 握手：

这个包依旧包含两个 QUIC 报文，其中第一个就是一个 ACK frame，来确认收到了服务器的 Server Hello 那个 QUIC 报文；第二个包含一个 ACK frame，确认服务器的 Handshake，随后有一个 CRYPTO frame 结束客户端的 TLS handshake。

TLS 握手结束之后，客户端和服务器就开始应用层的数据交换，此刻，所有数据都是加密的。

客户端发送一个 “hello” 文本

在我们的 echo client/server 代码中，客户端连接到服务器后，就可以等待用户在 stdin 的输入，然后将其发送到服务器。服务器收到客户端数据，原封不动发回，客户端再将其显示到 stdout 上。在这个过程的前后，客户端和服务器间有一些用于连接管理的 QUIC 报文，比如 PING。我们就略过，只看发送应用层数据的报文。下图是客户端发送的包含 “hello” 文本的报文：

As you can see, the QUIC message here is a Short Header packet. In addition to the ACK frame, it also has a STREAM frame. The lowest two digits of the stream ID of this stream are 00, which represents a client-initiated, bidirectional stream. Since two bits are used to express the type, QUIC's stream has the following types:

We look at the length(6) and Data(68 65 6c 6c 6f 0a of the STREAM frame ). If the content in Data is expressed in ASCII, it is exactly "hello ", and its length is 6 bytes.

The server replies "hello" text

Finally the server echo back:

This is exactly the same as the above message, so I won’t explain it.

Sage Moment

I believe that the above introduction to QUIC based on the wireshark packet capture can give you a preliminary understanding of the QUIC protocol. know. In the last article, we said that QUIC supports multiplexing and solves the problem of head-of-queue blocking at the transport layer. Through the introduction of this article, can you answer the following two questions?

• Which frame type does QUIC use for multiplexing?

• QUIC How to solve the problem of head-of-queue blocking at the transport layer?

Related recommendations:web server security

The above is the detailed content of Let's see how to learn network protocols through the QUIC protocol. For more information, please follow other related articles on the PHP Chinese website!