V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
mitu9527
V2EX  ›  程序员

HTTP 2.0 对内网服务之间的通信是不是没啥帮助?

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

    感觉 HTTP 2.0 的 header 压缩还能多少有些作用,但恐怕作用不大,因为服务器和服务器间通信时 header 数量不多。而多路复用、二进制分帧好像对内网服务器之间的通信不但没帮助,还会负优化。服务器推送貌似在客户端和服务器通信时比较有用,服务器和服务器通信时基本上用不到。

    综上所述,有两个猜测:

    1. HTTP 2.0 对内网服务器之间的通信是不是真没啥太大帮助?
    2. 基于 1, 微服务使用 gRPC (使用 HTTP 2.0 作为通信协议,使用 protobuf 作为数据交换格式)通信时,真正能提升效率的是 protobuf ?那感觉 gRPC 也不会比传统的 HTTP 1.1 + JSON 快多少啊。

    上面两个猜测是对的么?还是我漏掉了什么,求解惑。

    36 条回复    2022-09-27 13:22:25 +08:00
    aaronlam
        1
    aaronlam  
       74 天前
    而多路复用、二进制分帧好像对内网服务器之间的通信不但没帮助,还会负优化。服务器推送貌似在客户端和服务器通信时比较有用,服务器和服务器通信时基本上用不到。

    想问下,以上这个观点是怎么得出来的?
    mitu9527
        2
    mitu9527  
    OP
       74 天前
    HTTP 1.x 浏览器和服务器通信时会使用 N 个连接发送 M 个请求的情况,N 一般最大为 8 ,M 一般都是几十甚至几百,而服务器和服务器通信时好像不存在这种情况,都是 1 比 1 的,TCP 连接内就算同步阻塞读写也没问题;另外内网服务器之间的网络延迟一般都是 1ms 以内,而浏览器和服务器之间的网络延迟一般都在 20-30ms 之间。
    mitu9527
        3
    mitu9527  
    OP
       74 天前
    @aaronlam HTTP 1.x 浏览器和服务器通信时会使用 N 个连接发送 M 个请求的情况,N 一般最大为 8 ,M 一般都是几十甚至几百,而服务器和服务器通信时好像不存在这种情况,都是 1 比 1 的,TCP 连接内就算同步阻塞读写也没问题。问题不存在,所以解决方案就是多余的,多做的工作就是负优化。我是这么理解的哈。
    wanguorui123
        4
    wanguorui123  
       74 天前
    本地确实提升不大
    sam384sp4
        5
    sam384sp4  
       74 天前
    http 2.0 的 tls 貌似是必须的
    mitu9527
        6
    mitu9527  
    OP
       74 天前
    @sam384sp4 好像是在 tls 中加了一个 ALPN ,用来判断是否支持 HTTP 2.0 ,不在 tls 中做的话就得在客户端和服务器之间多通信一次,这违背了 HTTP 2.0 的初衷。浏览器和客户端之间应该必须是要用 https 的,服务器和服务器之间应该可以不用,好像不是强制的。
    guyeu
        7
    guyeu  
       74 天前
    服务器内网通信的瓶颈从来不在网络协议上,gRPC 选型使用 HTTP/2 肯定有谷歌自己的倾向在,不过既然是 HTTP 了,选用当时最新的版本好像也没什么毛病。
    不知道负优化是咋得出的结论,仅就多路复用一条就很重要呀,想想一个长时间执行的任务需要客户端等待结果,HTTP/1 的话只能新建一个连接,HTTP/2 就可以在同一个连接上用别的 stream 去处理。基于 HTTP/1 虽然也有办法做到这件事,HTTP/2 确实还是有点用的。
    mitu9527
        8
    mitu9527  
    OP
       74 天前
    @guyeu HTTP 1.x 客户不是一条连接哈,可以多条。所以多任务时可以通过多连接实现,每个连接只一个请求和响应,就不存在多请求响应了,也就没必要多路复用了,从而二进制分帧也没用了。至于多连接的方式,一般都自带连接复用或者池化技术,所以也不存在频繁创建和销毁连接的情况。客户端和服务器通信时 HTTP 2.0 很有用,内网的服务器和服务器通信时 HTTP 2.0 感觉用处不大。
    guyeu
        9
    guyeu  
       74 天前 via iPhone
    @mitu9527 同意你说的用处不大,但确实不是负优化。最起码可以省去在应用层实现一个连接池的成本哟
    mitu9527
        10
    mitu9527  
    OP
       74 天前
    @guyeu 好像也不用我们实现,都自带甚至默认开启了 keep-alive 了。我刚才上网搜了一下,那些说提升巨大,比如有说将近 10 倍的,都是测得客户端到服务器端;在 github 上找到一个服务器端到服务器端的基准测试,提升不到 10%。我回头再去找找其他基准测试。
    aababc
        11
    aababc  
       74 天前
    感觉是不是 HTTP3 才是大杀器?
    mitu9527
        12
    mitu9527  
    OP
       74 天前
    @aababc 额,还没了解,让我去看看。
    ospider
        13
    ospider  
       74 天前
    和楼主有一样的疑问好多年了,实在不理解在内网用 http2 图啥,为了 streaming response ?如果 Google 的意思是让 grpc 能在外网也用的话,那这个目标显然没有实现,没人会为了调用外部的 API 去搞 pb 这一套的……
    lysS
        14
    lysS  
       74 天前
    @mitu9527 #3 你是想说 keepalive 吗?
    lysS
        15
    lysS  
       74 天前
    grpc 比 json 肯定快不少,当然用 json 传输的都是小数据,表现可能不明显
    mitu9527
        16
    mitu9527  
    OP
       74 天前
    @ospider
    个人认为内网服务器之间通信用 gPRC 的原因不是奔着 HTTP 2.0 去的,而是 protobuf 去的,服务器之间都是内部自己人,沟通成本低,所以可以直接通过 api 列表和 proto 文件。

    而客户端和服务器通信具体分两种情况:
    1. 如果服务器面向的客户端开发人员都是自己公司的人,这种叫 SSKD ,此时首先可以考虑使用 gRPC ;当然 HTTP + json 也是可以的(这时不见得会用 REST ),此时 HTTP 2.0 可以大显神威。
    2. 如果服务器面向的客户端开发人员是外部的人,这种叫 LSUD ,此时一般会考虑使用 HTTP + json + REST(虽然可选,但是这是往往会用),这时候 HTTP 2.0 就可以大显神威了。沟通成本高,所以对外要提供详细的 API 文档,如果用 gRPC 并且只提供 api 列表和 protobuf ,估计技术对接人员会忙死。
    mitu9527
        17
    mitu9527  
    OP
       74 天前
    @lysS 嗯,HTTP 1.1 好像支持,而且默认就会开启来吧。
    mitu9527
        18
    mitu9527  
    OP
       74 天前
    @lysS protobuf 比 json 小,且编解码快,这点没问题哈。不过我在讨论 HTTP 2.0 在内网通信时的作用大小哈。
    lslqtz
        19
    lslqtz  
       74 天前
    聊胜于无吧, h2c 比 h2 好一点.
    Opportunity
        20
    Opportunity  
       74 天前
    内网要用也是 h2c 吧,用 h2 算啥啊
    Reficul
        21
    Reficul  
       74 天前
    会负优化,在整体只考虑 HTTP QPS 的压测情况下,因为协议复杂 + TLS 的原因,回避 HTTP 1 慢不止一倍。
    jim9606
        22
    jim9606  
       74 天前
    内网通信应该主要想使用 HTTP2 的 stream multiplex ,HTTP1.1 即使使用 keep-alive 也依然存在队头阻塞( HOL Blocking )的问题,头压缩什么的应该不是主要目的,跟 Web 应用需要每个请求都重复传一堆头字段不一样,gRPC 没这个问题。

    另外 json 有一个缺陷是它是 schemaless+文本,除了编码要带上结构信息占据额外流量外还涉及大量字符串操作,会带来很大的 GC 压力。

    另外 protobuf 还有些我道听途说的问题,protobuf 理论上编码很高效,但 protoc 生成的代码实际性能不见得高,经常搞出一堆编译警告; google monorepo 模式带来的副作用——跨版本兼容性不佳,你有信心保证一个大型项目(可能还有外部合作方)里所有组件都依赖相同版本的 protobuf 吗?
    IvanLi127
        23
    IvanLi127  
       74 天前 via Android
    @sam384sp4 h2c ,不需要 tls 。
    echo1937
        24
    echo1937  
       74 天前
    现在没有浏览器支持 h2c ,postman 好像也没有支持 h2c 的,所以调试起来比较麻烦。

    另外就是有些前端,或者上游调用的客户端比较老的话,也不支持 h2c 。

    现在有没有同时支持 h2c 和 HTTP 1.1 ,并支持自动 upgrade 到 h2c 的实现方案啊?
    janxin
        25
    janxin  
       74 天前
    你这么问应该是没用 mTLS...

    当然只考虑性能,自然还是抛弃 TLS 更好
    ZE3kr
        26
    ZE3kr  
       74 天前 via iPhone
    对内网还是很有帮助的,对 localhost 没啥帮助
    julyclyde
        27
    julyclyde  
       74 天前
    所谓负优化,很多时候其实体现在不方便 tcpdump 吧
    正常工作状态只是优化意义小,谈不上负
    oceanthe1h
        28
    oceanthe1h  
       73 天前
    个人理解,对于 web 界面来说,H2 多路复用可以让多个小图片对用户呈现同步加载的效果,对于服务器的响应包来说,以字节流为单位的多路复用好像意义不大,服务器需要完整的响应包才能有效解析,如果以包为单位的多路复用,好像 NIO 的 channel 就能够实现在一条 TCP 连接作为逻辑连接,也没必要使用传输层的分帧
    darknoll
        29
    darknoll  
       73 天前
    做个对比测试不行吗?上来就谈我感觉怎么样怎么样。
    mitu9527
        30
    mitu9527  
    OP
       73 天前
    @darknoll 不做对比测试就不配发言了么?你都可以回复,为啥我不能发言?
    darknoll
        31
    darknoll  
       73 天前   ❤️ 1
    @mitu9527 滚一边去吧
    mitu9527
        32
    mitu9527  
    OP
       73 天前
    @darknoll 你要是看着不舒服,不回复关了就是了,整这么一出,什么人啊?
    julyclyde
        33
    julyclyde  
       73 天前
    @mitu9527 人家在讨论学习方法,你却认为是人身攻击
    我只能说,差的人确实有差的原因
    mitu9527
        34
    mitu9527  
    OP
       72 天前
    @julyclyde 我攻击他了么?如果所有的讨论都可以转化成自己测试和研究,以后别提问题也别说话了?你能做到么?
    julyclyde
        35
    julyclyde  
       72 天前
    @mitu9527 你没攻击啊。你是把别人的劝告当成攻击,然后反应过激
    你现在都已经过激到连我说(你认为他攻击)还是说(你攻击)都分不清的地步了
    mitu9527
        36
    mitu9527  
    OP
       72 天前
    @julyclyde 差的人确实有差的原因,这叫劝告?你平时上来就和陌生人这么说话?
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   4821 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 54ms · UTC 02:19 · PVG 10:19 · LAX 18:19 · JFK 21:19
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.