共计 2044 个字符，预计需要花费 6 分钟才能阅读完成。
背景
最近一年很多对于 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 个申请。
| HTTP 版本 | 提早 | 丢包率 | 反复率 | 包损毁率 | 后果 |
|---|---|---|---|---|---|
| HTTP1.1 | – | – | – | – | 总耗时 406.49ms, 24601.15 req/s QPS，21.30MB/s 每秒传输 |
| HTTP3 | – | – | – | – | 总耗时 611.90ms, 16342.59 req/s QPS，12.98MB/s 每秒传输 |
| HTTP1.1 | 100ms+-10 | – | – | – | 总耗时 1.90s, 5275.52 req/s QPS，4.57MB/s 每秒传输 |
| HTTP3 | 100ms+-10 | – | – | – | 总耗时 3.65ms, 2740.22 req/s QPS，2.18MB/s 每秒传输 |
| HTTP1.1 | – | 30% | – | – | 总耗时 33.64s, 297.28 req/s QPS，263.60KB/s 每秒传输 |
| HTTP3 | – | 30% | – | – | 总耗时 19.82s, 504.45 req/s QPS，447.31KB/s 每秒传输 |
| HTTP1.1 | – | – | 70% | – | 总耗时 443.55ms, 23065.39 req/s QPS，19.97MB/s 每秒传输 |
| HTTP3 | – | – | 70% | – | 总耗时 419.98ms, 23810.43 req/s QPS，18.92MB/s 每秒传输 |
| HTTP1.1 | – | – | – | 20% | 总耗时 14.46s, 691.61 req/s QPS，613.27KB/s 每秒传输 |
| HTTP3 | – | – | – | 20% | 总耗时 4.12s, 2424.55 req/s QPS，1.93MB/s 每秒传输 |
| HTTP1.1 | 100ms+-10 | 30% | – | – | 总耗时 30.64s, 326.42req/s QPS，289.44KB/s 每秒传输 |
| HTTP3 | 100ms+-10 | 30% | – | – | 总耗时 17.16s, 582.89 req/s QPS，474.19KB/s 每秒传输 |
| HTTP1.1 | – | 30% | 70% | – | 总耗时 2.03s, 4914.90 req/s QPS，4.26MB/s 每秒传输 |
| HTTP3 | – | 30% | 70% | – | 总耗时 3.06s, 3264.89 req/s QPS，2.59MB/s 每秒传输 |
| HTTP1.1 | – | 30% | – | 20% | 慢到没后果 … |
| HTTP3 | – | 30% | – | 20% | 总耗时 15.09s, 662.75req/s QPS，539.16KB/s 每秒传输 |
在这份测试后果中我给出的都是典型值，当然我也对这些值都做过大小调整看后果。从这份后果咱们能够看出如下论断：
- 独自进步提早并不会呈现 HTTP3 性能优于 HTTP1.1 的状况。
- 丢包率的减少会使得 HTTP3 对 HTTP1.1 的性能劣势明显增加。
- 独自晋升包反复率 HTTP3 对 HTTP1.1 的性能仅有强劲的劣势。
- 独自晋升包损毁率会显著晋升 HTTP3 对 HTTP1.1 的性能劣势。
- 提早与其余因素同时呈现不会对整体后果造成更大的影响。
- 包反复率与损毁率（或丢包率）是一组对立项，丢包或损毁导致可用包缩小，但反复率又填补了这一损失，导致后果偏向 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 库的解决逻辑。
感激浏览，期待诸位的评论。
