HTTP3/QUIC 性能测试与配套组件

背景

最近一年很多关于 QUIC 的文章层出，但是发现一个问题，这些文章都是在介绍 QUIC 或 HTTP3 是怎样的一个东西，以及它的优点和机制，将它夸的近乎上天了。然而有心的人估计会亲手做一些测试，就会发现这个被捧上天的东西性能居然还不如 HTTP1.1，这是怎么回事呢？

最近我一直在做 QUIC 或者说 HTTP3 的相关工作，就一直在憋着写这样一篇文章，给和我当初有同样疑问的人一种变相的解答。

测试

测试很简单，分为两台机器，均在同一局域网内。服务器使用 Nginx 的 QUIC 分支版本，即 nginx-quic 。客户端使用 h2load （支持 HTTP3 版本的）做基准测试工具。在服务端使用 netem 模块对网络状况进行操控，模拟不同的网络环境。请求无请求体，响应体为 Nginx 默认 612 字节首页文件，那么简单来看下测试结果吧：

h2load 的参数如下：-t 10 -c 100 -n 1000 -m 100，即 10 线程、100 个连接、1000 个请求，每个连接可以同时处理 100 个请求。

在这份测试结果中我给出的都是典型值，当然我也对这些值都做过大小调整看结果。从这份结果我们可以看出如下结论：

1. 单独提高延迟并不会出现 HTTP3 性能优于 HTTP1.1 的情况。
2. 丢包率的增加会使得 HTTP3 对 HTTP1.1 的性能优势明显增加。
3. 单独提升包重复率 HTTP3 对 HTTP1.1 的性能仅有微弱的优势。
4. 单独提升包损毁率会明显提升 HTTP3 对 HTTP1.1 的性能优势。
5. 延迟与其他因素同时出现不会对整体结果造成更大的影响。
6. 包重复率与损毁率（或丢包率）是一组对立项，丢包或损毁导致可用包减少，但重复率又填补了这一损失，导致结果倾向 HTTP1.1 更优。

从上述结论中我们可以看到，并非任何时候 HTTP3 都优于 HTTP1.1，但对弱网高丢包率、包损的情况下，QUIC 或者说 HTTP3 的优势就非常明显了，这得益于其 FEC 机制和连接复用机制。然而生活中，弱网的环境其实非常多，例如地铁换站、电梯、部分楼宇内、以及一些网络覆盖不全面的城镇等等。因此 QUIC 更多的是一个对整体网络的兜底策略。

因此，如果使用 nginx-quic 的默认配置将所有的请求都升为 HTTP3 版本是不明智的，因为常规情况下 HTTP1.1 的性能优势是不可视而不见的。这也就引入了下一小节的组件。

组件

由上面的结论，我们发现并非对每一个请求都升级是一个明智之举，因此就有了这个 Nginx 模块对版本升级进行自动化控制——ngx_http_autoquic_module

这个模块会根据 TCP 的网络状况来决定是否需要将 HTTP 版本升至 HTTP3 版本。而根据 QUIC 的统计情况来判断是否需要降级至 HTTP1.1 版本。由于降级并不像升级那样平滑，因此对降级增加了开关，让使用者可以选择是否允许降级。

目前对于浏览器，可以很好地支持升降级。但对于众多客户端而言，升降级与否还要看客户端所使用的 HTTP 库的处理逻辑。

感谢阅读，期待诸位的评论。