V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Distributions
Ubuntu
Fedora
CentOS
中文资源站
网易开源镜像站
monkeyNik
V2EX  ›  Linux

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

  •  
  •   monkeyNik · 134 天前 · 752 次点击
    这是一个创建于 134 天前的主题,其中的信息可能已经有所发展或是发生改变。

    背景

    最近一年很多关于 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 每秒传输

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

    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 库的处理逻辑。

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

    7 条回复    2021-07-27 15:31:16 +08:00
    FakNoCNName
        1
    FakNoCNName  
       134 天前
    官方也说了在网络状况良好的情况下 HTTP 和 QUIC 差别不大,主要用来改善网络环境不好条件下的访问。

    但你这个近乎两倍的差距有点迷,考虑到 QUIC 是有加密的,应该对比一下 HTTP+TLS 看看。
    monkeyNik
        2
    monkeyNik  
    OP
       134 天前
    @FakNoCNName 这个就是 HTTP3 和 HTTPS 的对比,只是加密库都是 boringssl
    liuxu
        3
    liuxu  
       134 天前
    国外香,你局域网测不出来的一个问题,就是中国内地各种对 udp 不友好
    monkeyNik
        4
    monkeyNik  
    OP
       133 天前 via iPhone
    @liuxu 确实好像看到过相关言论,不过当时在国内公网和跨国公网测的时候没感觉到…可能我没遇上吧
    liuxu
        5
    liuxu  
       133 天前
    @monkeyNik 很多国内机房高防都是直接禁 udp,或者干扰,可以搜搜金盾高防,镇江那边的小机房,好在现在云服务商收编进度可观
    hronro
        6
    hronro  
       133 天前
    考虑到国内对 UDP 的 QOS,现阶段 QUIC 在国内基本没用
    wetman
        7
    wetman  
       130 天前
    确实夸的多,实测的少,支持楼主实干精神。
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   965 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 23ms · UTC 22:36 · PVG 06:36 · LAX 14:36 · JFK 17:36
    ♥ Do have faith in what you're doing.