HTTP3/QUIC|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个请求。
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更优。
因此,如果使用nginx-quic的默认配置将所有的请求都升为HTTP3版本是不明智的,因为常规情况下HTTP1.1的性能优势是不可视而不见的。这也就引入了下一小节的组件。
组件
由上面的结论,我们发现并非对每一个请求都升级是一个明智之举,因此就有了这个Nginx模块对版本升级进行自动化控制——ngx_http_autoquic_module
这个模块会根据TCP的网络状况来决定是否需要将HTTP版本升至HTTP3版本。而根据QUIC的统计情况来判断是否需要降级至HTTP1.1版本。由于降级并不像升级那样平滑,因此对降级增加了开关,让使用者可以选择是否允许降级。
目前对于浏览器,可以很好地支持升降级。但对于众多客户端而言,升降级与否还要看客户端所使用的HTTP库的处理逻辑。
【HTTP3/QUIC|HTTP3/QUIC 性能测试与配套组件】感谢阅读,期待诸位的评论。
推荐阅读
- 数据库|SQL行转列方式优化查询性能实践
- 性能测试中QPS和TPS的区别
- javascript|javascript 性能测试笔记
- 使用交叉点观察器延迟加载图像以提高性能
- golang锁竞争性能
- Linux性能分析-平均负载
- swoole打造高性能赛事直播平台1(准备工作)
- locust——python性能测试模块
- JavaScript|JavaScript 性能优化—学习笔记
- Crack|vectordraw图形库,提高了 WebGL 3D 渲染模式的性能