透视HTTP协议
罗剑锋(Chrono)
奇虎360技术专家,Nginx/OpenResty开源项目贡献者
立即订阅
11548 人已学习
课程目录
已完结 47 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词|To Be a HTTP Hero
免费
破冰篇 (7讲)
01 | 时势与英雄:HTTP的前世今生
02 | HTTP是什么?HTTP又不是什么?
03 | HTTP世界全览(上):与HTTP相关的各种概念
04 | HTTP世界全览(下):与HTTP相关的各种协议
05 | 常说的“四层”和“七层”到底是什么?“五层”“六层”哪去了?
06 | 域名里有哪些门道?
07 | 自己动手,搭建HTTP实验环境
基础篇 (7讲)
08 | 键入网址再按下回车,后面究竟发生了什么?
09 | HTTP报文是什么样子的?
10 | 应该如何理解请求方法?
11 | 你能写出正确的网址吗?
12 | 响应状态码该怎么用?
13 | HTTP有哪些特点?
14 | HTTP有哪些优点?又有哪些缺点?
进阶篇 (8讲)
15 | 海纳百川:HTTP的实体数据
16 | 把大象装进冰箱:HTTP传输大文件的方法
17 | 排队也要讲效率:HTTP的连接管理
18 | 四通八达:HTTP的重定向和跳转
19 | 让我知道你是谁:HTTP的Cookie机制
20 | 生鲜速递:HTTP的缓存控制
21 | 良心中间商:HTTP的代理服务
22 | 冷链周转:HTTP的缓存代理
安全篇 (7讲)
23 | HTTPS是什么?SSL/TLS又是什么?
24 | 固若金汤的根本(上):对称加密与非对称加密
25 | 固若金汤的根本(下):数字签名与证书
26 | 信任始于握手:TLS1.2连接过程解析
27 | 更好更快的握手:TLS1.3特性解析
28 | 连接太慢该怎么办:HTTPS的优化
29 | 我应该迁移到HTTPS吗?
飞翔篇 (4讲)
30 | 时代之风(上):HTTP/2特性概览
31 | 时代之风(下):HTTP/2内核剖析
32 | 未来之路:HTTP/3展望
33 | 我应该迁移到HTTP/2吗?
探索篇 (5讲)
34 | Nginx:高性能的Web服务器
35 | OpenResty:更灵活的Web服务器
36 | WAF:保护我们的网络服务
37 | CDN:加速我们的网络服务
38 | WebSocket:沙盒里的TCP
总结篇 (2讲)
39 | HTTP性能优化面面观(上)
40 | HTTP性能优化面面观(下)
答疑篇 (3讲)
41 | Linux/Mac实验环境搭建与URI查询参数
42 | DHE/ECDHE算法的原理
43 | 如何进行Docker实验环境搭建?
特别放送 (1讲)
44 | 先睹为快:HTTP/3实验版本长什么样子?
免费
结束语 (2讲)
结束语 | 做兴趣使然的Hero
结课测试 | 这些HTTP协议知识,你真的掌握了吗?
透视HTTP协议
15
15
1.0x
00:00/09:32
登录|注册

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

罗剑锋 2021-03-01
00:00
1.0x
讲述:罗剑锋 大小:8.75M 时长:09:32
你好,我是 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,完成了握手阶段的密钥交换。

小结

好了,QUIC 和 HTTP/3 的“抢鲜体验”就到这里吧,我简单小结一下今天的要点:
HTTP/3 的最新草案版本是 34,很快就会发布正式版本。
Nginx 提供了对 HTTP/3 的实验性质支持,目前是 Beta 状态,只能用于测试。
最新版本的 Chrome 和 Firefox 都支持 QUIC 和 HTTP/3,但可能需要一些设置工作才能启用。
访问专门的测试网站“quic.nginx.org”可以检查浏览器是否支持 QUIC 和 HTTP/3。
抓包分析 QUIC 和 HTTP/3 需要用最新的 Wireshark,过滤器用 UDP,还要导出 SSLKEYLOG 才能解密。
希望你看完这一讲后自己实际动手操作一下,访问网站再抓包,如果能正确解密 HTTP/3 数据,就把资料发出来,和我们分享下。
如果你觉得有所收获,也欢迎把这一讲的内容分享给你的朋友。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/1000字
划线
笔记
复制
unpreview
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《透视HTTP协议》,如需阅读全部文章,
请订阅文章所属专栏
立即订阅
登录 后留言

精选留言

由作者筛选后的优质留言将会公开显示,欢迎踊跃留言。
收起评论
1
返回
顶部