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

讨论 未结 20 33
mitu9527
mitu9527 会员 2022年9月25日 11:56 发表
<p>感觉 HTTP 2.0 的 header 压缩还能多少有些作用,但恐怕作用不大,因为服务器和服务器间通信时 header 数量不多。而多路复用、二进制分帧好像对内网服务器之间的通信不但没帮助,还会负优化。服务器推送貌似在客户端和服务器通信时比较有用,服务器和服务器通信时基本上用不到。</p> <p>综上所述,有两个猜测:</p> <ol> <li>HTTP 2.0 对内网服务器之间的通信是不是真没啥太大帮助?</li> <li>基于 1, 微服务使用 gRPC (使用 HTTP 2.0 作为通信协议,使用 protobuf 作为数据交换格式)通信时,真正能提升效率的是 protobuf ?那感觉 gRPC 也不会比传统的 HTTP 1.1 + JSON 快多少啊。</li> </ol> <p>上面两个猜测是对的么?还是我漏掉了什么,求解惑。</p>
收藏(0)  分享
相关标签: 灌水交流
注意:本文归作者所有,未经作者允许,不得转载
20个回复
  • aaronlam
    2022年9月25日 11:56
    而多路复用、二进制分帧好像对内网服务器之间的通信不但没帮助,还会负优化。服务器推送貌似在客户端和服务器通信时比较有用,服务器和服务器通信时基本上用不到。 想问下,以上这个观点是怎么得出来的?
    0 0
  • mitu9527
    2022年9月25日 12:26
    HTTP 1.x 浏览器和服务器通信时会使用 N 个连接发送 M 个请求的情况,N 一般最大为 8 ,M 一般都是几十甚至几百,而服务器和服务器通信时好像不存在这种情况,都是 1 比 1 的,TCP 连接内就算同步阻塞读写也没问题;另外内网服务器之间的网络延迟一般都是 1ms 以内,而浏览器和服务器之间的网络延迟一般都在 20-30ms 之间。
    0 0
  • mitu9527
    2022年9月25日 12:26
    HTTP 1.x 浏览器和服务器通信时会使用 N 个连接发送 M 个请求的情况,N 一般最大为 8 ,M 一般都是几十甚至几百,而服务器和服务器通信时好像不存在这种情况,都是 1 比 1 的,TCP 连接内就算同步阻塞读写也没问题。问题不存在,所以解决方案就是多余的,多做的工作就是负优化。我是这么理解的哈。
    0 0
  • mitu9527
    2022年9月25日 12:56
    好像是在 tls 中加了一个 ALPN ,用来判断是否支持 HTTP 2.0 ,不在 tls 中做的话就得在客户端和服务器之间多通信一次,这违背了 HTTP 2.0 的初衷。浏览器和客户端之间应该必须是要用 https 的,服务器和服务器之间应该可以不用,好像不是强制的。
    0 0
  • guyeu
    2022年9月25日 12:56
    服务器内网通信的瓶颈从来不在网络协议上,gRPC 选型使用 HTTP/2 肯定有谷歌自己的倾向在,不过既然是 HTTP 了,选用当时最新的版本好像也没什么毛病。 不知道负优化是咋得出的结论,仅就多路复用一条就很重要呀,想想一个长时间执行的任务需要客户端等待结果,HTTP/1 的话只能新建一个连接,HTTP/2 就可以在同一个连接上用别的 stream 去处理。基于 HTTP/1 虽然也有办法做到这件事,HTTP/2 确实还是有点用的。
    0 0
  • mitu9527
    2022年9月25日 13:28
    HTTP 1.x 客户不是一条连接哈,可以多条。所以多任务时可以通过多连接实现,每个连接只一个请求和响应,就不存在多请求响应了,也就没必要多路复用了,从而二进制分帧也没用了。至于多连接的方式,一般都自带连接复用或者池化技术,所以也不存在频繁创建和销毁连接的情况。客户端和服务器通信时 HTTP 2.0 很有用,内网的服务器和服务器通信时 HTTP 2.0 感觉用处不大。
    0 0
  • guyeu
    2022年9月25日 13:28
    同意你说的用处不大,但确实不是负优化。最起码可以省去在应用层实现一个连接池的成本哟
    0 0
  • mitu9527
    2022年9月25日 13:28
    好像也不用我们实现,都自带甚至默认开启了 keep-alive 了。我刚才上网搜了一下,那些说提升巨大,比如有说将近 10 倍的,都是测得客户端到服务器端;在 github 上找到一个服务器端到服务器端的基准测试,提升不到 10%。我回头再去找找其他基准测试。
    0 0
  • aababc
    2022年9月25日 13:28
    感觉是不是 HTTP3 才是大杀器?
    0 0
  • mitu9527
    2022年9月25日 13:28
    额,还没了解,让我去看看。
    0 0
  • ospider
    2022年9月25日 13:59
    和楼主有一样的疑问好多年了,实在不理解在内网用 http2 图啥,为了 streaming response ?如果 Google 的意思是让 grpc 能在外网也用的话,那这个目标显然没有实现,没人会为了调用外部的 API 去搞 pb 这一套的……
    0 0
  • lysS
    2022年9月25日 13:59
    #3 你是想说 keepalive 吗?
    0 0
  • lslqtz
    2022年9月25日 15:28
    聊胜于无吧, h2c 比 h2 好一点.
    0 0
  • Reficul
    2022年9月25日 15:55
    会负优化,在整体只考虑 HTTP QPS 的压测情况下,因为协议复杂 + TLS 的原因,回避 HTTP 1 慢不止一倍。
    0 0
  • echo1937
    2022年9月26日 00:59
    现在没有浏览器支持 h2c ,postman 好像也没有支持 h2c 的,所以调试起来比较麻烦。 另外就是有些前端,或者上游调用的客户端比较老的话,也不支持 h2c 。 现在有没有同时支持 h2c 和 HTTP 1.1 ,并支持自动 upgrade 到 h2c 的实现方案啊?
    0 0
  • janxin
    2022年9月26日 00:59
    你这么问应该是没用 mTLS... 当然只考虑性能,自然还是抛弃 TLS 更好
    0 0