首页 > 文章 > 运维 > 通过QUIC协议，来看看怎么学习网络协议

通过QUIC协议，来看看怎么学习网络协议

青灯夜游转载: 2022-03-01 09:57:243283浏览

本篇文章带大家了解一下QUIC协议，并以QUIC协议为例，来聊聊如何学习网络协议，希望对大家有所帮助！

在之前发布的关于 s2n-quic 的文章中，有读者问我如何学习像 QUIC 这样的网络协议。对于大部分互联网从业者来说，虽然大家每天都在跟网络打交道，但很少有人会（需要）关心 HTTP 之下的网络协议的细节，大部分时候，了解个大概，知道如何使用就可以了。如果你对 QUIC 一点概念都没有，那么，下面这个图能帮助你很好地了解 QUIC 在 HTTP/3 生态中的地位：

那么，如果你就是要详尽地了解一下 QUIC 的知识，该如何入手呢？

作为一个曾经的网络协议和网络设备的开发者，我自己的心得是：从 RFC 入手，辅以 wireshark 抓包，来快速掌握目标协议。

对于 QUIC 而言，我们首先需要阅读的是 RFC9000。协议的阅读是非常枯燥的事情，需要一定的耐心，如果英文不太好，可以用 google translate 将其翻译成中文，快速浏览一番（泛读）。第一遍阅读主要了解里面的主要概念，以及主要流程。

之后，我们就可以撰写使用 QUIC 协议的程序，然后通过 wireshark 抓包，通过研究实际的报文，对比 RFC 协议中的内容（精读），来更深入地理解协议的本质。

我们还是以上一篇文章中的代码为基础，构建 echo 客户端和服务器。为方便大家阅读，我把代码也贴上来。感兴趣的同学可以自行 clone 我的 repo，并运行 client/server 代码。

客户端代码（见 github: tyrchen/rust-training/live_coding/quic-test/examples/client.rs）：

服务端代码（见 github: tyrchen/rust-training/live_coding/quic-test/examples/server.rs）：

这两段代码构建了一个最简单的 echo server。我们可以使用 wireshark 监听本地 loopback 接口下的 UDP 包，进行抓包。要注意的是，对于 QUIC 这样使用了 TLS 协议的流量，即便抓到了包，可能只有头几个包可读，后续的包都是加密内容，无法阅读。因此，我们在构建 client/server 时，需要想办法把服务器和客户端之间协商出来的 session key 抓取下来，供 wireshark 解密使用。一般 SSL/TLS 库都会提供这个功能。比如对于 Rustls，我们可以在 tls config 中使用 key_log。如果你仔细看上面 server 的代码，会看到这句：

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

使用了 key_log 后，在启动 server 的时候，我们只需要指定 SSLKEYLOGFILE 就可以了：

SSLKEYLOGFILE=session.log cargo run --example server

在抓包完成后，打开 wireshark 的 preference，选择 TLS 协议，把 log 的路径放进去就可以了：

以下是一次完整的客户端和服务器的交互的抓包，我们看到，所有 “protected payload” 都被正常显示出来了：

因为我们的 echo client 只做了最简单的动作（只开了一个 bidirectional stream），所以通过这个抓包，我们重点可以研究 QUIC 协议建立连接的过程。

客户端发送的首包

我们看客户端发的第一个报文：

这个报文包含了非常丰富的信息。首先，和 TCP 握手不同的是，QUIC 的首包非常大，有 1200 字节之多（协议要求 UDP payload at least 1200 bytes），包含 QUIC 头，一个 255 字节的 CRYPTO frame，以及 890 字节 PADDING frame。从 header 可以看到，这个 QUIC 包的类型是 Initial。

QUIC 报文类型

对于 QUIC 包来说，Header 是明文，之后的所有 frame payload 都是密文（除了头几个包）。我们看到这个首包是一个 Long Header 报文，在 RFC9000 的 17.2 节中，定义了 Long Header Packet：

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 (..),
 }

感兴趣的可以自行去阅读 RFC 相应的章节。对于 Long Header 报文，有如下几种类型：

既然有 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” 文本的报文：

可以看到，这里 QUIC 报文是个 Short Header packet，除了 ACK frame 外，它还有一个 STREAM frame。这个 stream 的 stream ID 最低两位是 00，代表是客户端发起的，双向的 stream。由于使用了两位来表述类型，所以 QUIC 的 stream 有如下类型：

我们看 STREAM frame 的 length(6) 和 Data(68 65 6c 6c 6f 0a)。Data 里的内容如果用 ASCII 表示，正好是 “hello48d850c955600b460c577ffbab3877a8”，它的长度是 6 个字节。

服务器回复 “hello” 文本

最后是服务器 echo back：

这个和上面的报文如出一辙，就不解释了。

贤者时刻

相信通过上面对照着 wireshark 抓包进行的 QUIC 简介，能让你对 QUIC 协议有一个初步的认识。上篇文章，我们说 QUIC 支持多路复用，并且解决了传输层队头阻塞的问题。通过这篇文章的介绍，你能回答以下两个问题么？

QUIC 通过哪个 frame 类型来做多路复用的？
QUIC 如何解决传输层队头阻塞的？

通过QUIC协议，来看看怎么学习网络协议

相关文章