44 | 先睹为快：HTTP/3实验版本长什么样子？

罗剑锋（Chrono）

前奇虎360技术专家，Nginx/OpenResty开源项目贡献者

你好，我是Chrono。

不知不觉，《透视HTTP协议》这个专栏马上就要两周岁了。前几天我看了一下专栏的相关信息，订阅数刚好破万，非常感谢包括你在内的所有朋友们的关心、支持、鼓励和鞭策。

在专栏的结束语里我曾经说过，希望HTTP/3发布之时能够再相会。而如今虽然它还没有发布，但也为时不远了。

所以今天呢，我就来和你聊聊HTTP/3的一些事，就当是“尝尝鲜”吧。

HTTP/3的现状

从2019到2021的这两年间，大家对HTTP协议的关注重点差不多全都是放在HTTP/3标准的制订上。

最初专栏开始的时候，HTTP/3草案还是第20版，而现在则已经是第34版了，发展的速度可以说是非常快的，里面的内容也变动得非常多。很有可能最多再过一年，甚至是今年内，我们就可以看到正式的标准。

在标准文档的制订过程中，互联网业届也没有闲着，也在积极地为此做准备，以草案为基础做各种实验性质的开发。

这其中比较引人瞩目的要数CDN大厂Cloudflare，还有Web Server领头羊Nginx（而另一个Web Server Apache好像没什么动静）了。

Cloudflare公司用Rust语言编写了一个QUIC支持库，名字叫“quiche”，然后在上面加了一层薄薄的封装，由此能够以一个C模块的形式加入进Nginx框架，为Nginx提供了HTTP/3的功能。（可以参考这篇文章：HTTP/3：过去，现在，还有未来）

不过Cloudflare的这个QUIC支持库属于“民间行为”，没有得到Nginx的认可。Nginx的官方HTTP/3模块其实一直在“秘密”开发中，在去年的6月份，这个模块终于正式公布了，名字就叫“http_v3_module”。（可以参考这篇文章：Introducing a Technology Preview of NGINX Support for QUIC and HTTP/3）

目前，http_v3_module已经度过了Alpha阶段，处于Beta状态，但支持的草案版本是29，而不是最新的34。

这当然也有情可原。相比于HTTP/2，HTTP/3的变化太大了，Nginx团队的精力还是集中在核心功能实现上，选择一个稳定的版本更有利于开发，而且29后面的多个版本标准其实差异非常小（仅文字编辑变更）。

Nginx也为测试HTTP/3专门搭建了一个网站：quic.nginx.org，任何人都可以上去测试验证HTTP/3协议。

所以，接下来我们就用它来看看HTTP/3到底长什么样。

初识HTTP/3

在体验之前，得先说一下浏览器，这是测试QUIC和HTTP/3的关键：最好使用最新版本的Chrome或者Firefox，这里我用的是Chrome88。

打开浏览器窗口，输入测试网站的URI（https://quic.nginx.org/），如果“运气好”，刷新几次就能够在网页上看到大大的QUIC标志了。

不过你很可能“运气”没有这么好，在网页上看到的QUIC标志是灰色的。这意味着暂时没有应用QUIC和HTTP/3，这就需要对Chrome做一点设置，开启QUIC的支持。

首先要在地址栏输入“chrome://flags”，打开设置页面，然后搜索“QUIC”，找到启用QUIC的选项，把它改为“Enabled”，具体可以参考下面的图片。

接下来，我们要在命令行里启动Chrome浏览器，在命令行里传递“enable-quic”“quic-version”等参数来要求Chrome使用特定的草案版本。

下面的示例就是我在macOS上运行Chrome的命令行。你也可以参考Nginx网站上的README文档，在Windows或者Linux上用类似的形式运行Chrome的命令行：

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome \
--enable-quic --quic-version=h3-29 \
--origin-to-force-quic-on=quic.nginx.org:443

如果这样操作之后网页上仍然是显示灰色标志也不要紧，你还可以用“F12”打开Chrome的开发者工具面板，查看protocol一栏。

应该可以看到大部分资源显示的还是“h2”，表示使用的是HTTP/2协议，但有一小部分资源显示的是“h3-29”，这就表示它是使用HTTP/3协议传输的，而后面的“29”后缀，意思是基于第29版草案，也就是说启用了QUIC+HTTP/3协议。

Wireshark抓包分析

好了，大概看了HTTP/3是什么样，有了感性认识，我们就可以进一步来抓包分析。

网络抓包工具Wireshark你一定已经比较熟悉了，这里同样要用最新的，不然可能识别不了QUIC和HTTP/3的数据包，比如我用的就是3.4.3。

QUIC的底层是UDP，所以在抓包的时候过滤器要设置成“udp port 443”，然后启动就可以了。这次我抓的包也放到了GitHub的Wireshark目录，文件名是“44-1.pcapng”。

因为HTTP/3内置了TLS加密（可参考之前的第32讲），所以用Wireshark抓包后看到的数据大部分都是乱码，想要解密看到真实数据就必须设置SSLKEYLOG（参考第26讲）。

不过非常遗憾，不知道是什么原因，虽然我导出了SSLKEYLOG，但在Wireshark里还是无法解密HTTP/3的数据，显示解密错误。但同样的设置和操作步骤，抓包解密HTTPS和HTTP/2却是正常的，估计可能是目前Wireshark自身对HTTP/3的支持还不太完善吧。

所以今天我也就只能带你一起来看QUIC的握手阶段了。这个其实与TLS1.3非常接近，只不过是内嵌在了QUIC协议里，如果你学过了“安全篇”“飞翔篇”的课程，看QUIC应该是不会费什么力气。

首先我们来看Header数据：

[Packet Length: 1350]
1... .... = Header Form: Long Header (1)
.1.. .... = Fixed Bit: True
..00 .... = Packet Type: Initial (0)
.... 00.. = Reserved: 0
.... ..00 = Packet Number Length: 1 bytes (0)
Version: draft-29 (0xff00001d)
Destination Connection ID Length: 20
Destination Connection ID: 3ae893fa047246e55f963ea14fc5ecac3774f61e
Source Connection ID Length: 0

QUIC包头的第一个字节是标志位，可以看到最开始建立连接会发一个长包（Long Header），包类型是初始化（Initial）。

标志位字节后面是4字节的版本号，因为目前还是草案，所以显示的是“draft-29”。再后面，是QUIC的特性之一“连接ID”，长度为20字节的十六进制字符串。

这里我要特别提醒你注意，因为标准版本的演变，这个格式已经与当初第32讲的内容（draft-20）完全不一样了，在分析查看的时候一定要使用对应的RFC文档。

往下再看，是QUIC的CRYPTO帧，用来传输握手消息，帧类型是0x06：

TLSv1.3 Record Layer: Handshake Protocol: Client Hello
    Frame Type: CRYPTO (0x0000000000000006)
    Offset: 0
    Length: 309
    Crypto Data
    Handshake Protocol: Client Hello

CRYPTO帧里的数据，就是QUIC内置的TLS “Client Hello”了，我把里面的一些重要信息摘了出来：

Handshake Protocol: Client Hello
   Handshake Type: Client Hello (1)
   Version: TLS 1.2 (0x0303)
   Random: b4613d...
   Cipher Suites (3 suites)
       Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301)
       Cipher Suite: TLS_AES_256_GCM_SHA384 (0x1302)
       Cipher Suite: TLS_CHACHA20_POLY1305_SHA256 (0x1303)
   Extension: server_name (len=19)
       Type: server_name (0)
       Server Name Indication extension
           Server Name: quic.nginx.org
   Extension: application_layer_protocol_negotiation (len=8)
       Type: application_layer_protocol_negotiation (16)
       ALPN Protocol
           ALPN Next Protocol: h3-29
   Extension: key_share (len=38)
       Key Share extension
   Extension: supported_versions (len=3)
       Type: supported_versions (43)
       Supported Version: TLS 1.3 (0x0304)

你看，这个就是标准的TLS1.3数据（伪装成了TLS1.2），支持AES128、AES256、CHACHA20三个密码套件，SNI是“quic.nginx.org”，ALPN是“h3-29”。

浏览器发送完Initial消息之后，服务器回复Handshake，用一个RTT就完成了握手，包的格式基本一样，用了一个CRYPTO帧和ACK帧，我就不细分析了（可参考相应的RFC），只贴一下里面的“Server Hello”信息：

Handshake Protocol: Server Hello
    Handshake Type: Server Hello (2)
    Version: TLS 1.2 (0x0303)
    Random: d6aede...
    Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301)
    Extension: key_share (len=36)
        Key Share extension
    Extension: supported_versions (len=2)
        Type: supported_versions (43)
        Supported Version: TLS 1.3 (0x0304)

这里服务器选择了“TLS_AES_128_GCM_SHA256”，然后带回了随机数和key_share，完成了握手阶段的密钥交换。