这是一个创建于 1181 天前的主题，其中的信息可能已经有所发展或是发生改变。
感觉 HTTP 2.0 的 header 压缩还能多少有些作用，但恐怕作用不大，因为服务器和服务器间通信时 header 数量不多。而多路复用、二进制分帧好像对内网服务器之间的通信不但没帮助，还会负优化。服务器推送貌似在客户端和服务器通信时比较有用，服务器和服务器通信时基本上用不到。
综上所述，有两个猜测：
- HTTP 2.0 对内网服务器之间的通信是不是真没啥太大帮助？
- 基于 1, 微服务使用 gRPC （使用 HTTP 2.0 作为通信协议，使用 protobuf 作为数据交换格式）通信时，真正能提升效率的是 protobuf ？那感觉 gRPC 也不会比传统的 HTTP 1.1 + JSON 快多少啊。
上面两个猜测是对的么？还是我漏掉了什么，求解惑。
 | 1 aaronlam 2022-09-25 19:51:44 +08:00 而多路复用、二进制分帧好像对内网服务器之间的通信不但没帮助，还会负优化。服务器推送貌似在客户端和服务器通信时比较有用，服务器和服务器通信时基本上用不到。 想问下，以上这个观点是怎么得出来的？ |
 | 2 mitu9527 OP HTTP 1.x 浏览器和服务器通信时会使用 N 个连接发送 M 个请求的情况，N 一般最大为 8 ，M 一般都是几十甚至几百，而服务器和服务器通信时好像不存在这种情况，都是 1 比 1 的，TCP 连接内就算同步阻塞读写也没问题；另外内网服务器之间的网络延迟一般都是 1ms 以内，而浏览器和服务器之间的网络延迟一般都在 20-30ms 之间。 |
| 3 mitu9527 OP @aaronlam HTTP 1.x 浏览器和服务器通信时会使用 N 个连接发送 M 个请求的情况，N 一般最大为 8 ，M 一般都是几十甚至几百，而服务器和服务器通信时好像不存在这种情况，都是 1 比 1 的，TCP 连接内就算同步阻塞读写也没问题。问题不存在，所以解决方案就是多余的，多做的工作就是负优化。我是这么理解的哈。 |
 | 4 wanguorui123 2022-09-25 20:18:40 +08:00 本地确实提升不大 |
 | 5 sam384sp4 2022-09-25 20:20:55 +08:00 http 2.0 的 tls 貌似是必须的 |
| 6 mitu9527 OP @sam384sp4 好像是在 tls 中加了一个 ALPN ，用来判断是否支持 HTTP 2.0 ，不在 tls 中做的话就得在客户端和服务器之间多通信一次，这违背了 HTTP 2.0 的初衷。浏览器和户端之间应该必须是要用 https 的，服务器和服务器之间应该可以不用，好像不是强制的。 |
 | 7 guyeu 2022-09-25 20:50:04 +08:00 服务器内网通信的瓶颈从来不在网络协议上，gRPC 选型使用 HTTP/2 肯定有谷歌自己的倾向在，不过既然是 HTTP 了，选用当时最新的版本好像也没什么毛病。 不知道负优化是咋得出的结论，仅就多路复用一条就很重要呀，想想一个长时间执行的任务需要客户端等待结果，HTTP/1 的话只能新建一个连接，HTTP/2 就可以在同一个连接上用别的 stream 去处理。基于 HTTP/1 虽然也有办法做到这件事，HTTP/2 确实还是有点用的。 |
| 8 mitu9527 OP @guyeu HTTP 1.x 客户不是一条连接哈，可以多条。所以多任务时可以通过多连接实现，每个连接只一个请求和响应，就不存在多请求响应了，也就没必要多路复用了，从而二进制分帧也没用了。至于多连接的方式，一般都自带连接复用或者池化技术，所以也不存在频繁创建和销毁连接的情况。客户端和服务器通信时 HTTP 2.0 很有用，内网的服务器和服务器通信时 HTTP 2.0 感觉用处不大。 |
| 10 mitu9527 OP @guyeu 好像也不用我们实现，都自带甚至默认开启了 keep-alive 了。我刚才上网搜了一下，那些说提升巨大，比如有说将近 10 倍的，都是测得客户端到服务器端；在 github 上找到一个服务器端到服务器端的基准测试，提升不到 10%。我回头再去找找其他基准测试。 |
 | 11 aababc 2022-09-25 21:09:11 +08:00 感觉是不是 HTTP3 才是大杀器？ |
 | 13 4BVL25L90W260T9U 2022-09-25 21:34:14 +08:00 和楼主有一样的疑问好多年了，实在不理解在内网用 http2 图啥，为了 streaming response ？如果 Google 的意思是让 grpc 能在外网也用的话，那这个目标显然没有实现，没人会为了调用外部的 API 去搞 pb 这一套的…… |
 | 15 lysS 2022-09-25 21:59:45 +08:00 grpc 比 json 肯定快不少，当然用 json 传输的都是小数据，表现可能不明显 |
| 16 mitu9527 OP @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 ，估计技术对接人员会忙死。 |
| 18 mitu9527 OP @lysS protobuf 比 json 小，且编解码快，这点没问题哈。不过我在讨论 HTTP 2.0 在内网通信时的作用大小哈。 |
 | 19 lslqtz 2022-09-25 22:58:10 +08:00 聊胜于无吧, h2c 比 h2 好一点. |
 | 20 Opportunity 2022-09-25 23:44:13 +08:00 内网要用也是 h2c 吧，用 h2 算啥啊 |
 | 21 Reficul 2022-09-25 23:52:45 +08:00 会负优化，在整体只考虑 HTTP QPS 的压测情况下，因为协议复杂 + TLS 的原因，回避 HTTP 1 慢不止一倍。 |
 | 22 jim9606 2022-09-26 00:35:30 +08:00 内网通信应该主要想使用 HTTP2 的 stream multiplex ，HTTP1.1 即使使用 keep-alive 也依然存在队头阻塞（ HOL Blocking ）的问题，头压缩什么的应该不是主要目的，跟 Web 应用需要每个请求都重复传一堆头字段不一样，gRPC 没这个问题。 另外 json 有一个缺陷是它是 schemaless+文本，除了编码要带上结构信息占据额外流量外还涉及大量字符串操作，会带来很大的 GC 压力。 另外 protobuf 还有些我道听途说的问题，protobuf 理论上编码很高效，但 protoc 生成的代码实际性能不见得高，经常搞出一堆编译警告； google monorepo 模式带来的副作用跨版本兼容性不佳，你有信心保证一个大型项目（可能还有外部合作方）里所有组件都依赖相同版本的 protobuf 吗？ |
 | 24 echo1937 2022-09-26 08:45:53 +08:00 现在没有浏览器支持 h2c ，postman 好像也没有支持 h2c 的，所以调试起来比较麻烦。 另外就是有些前端，或者上游调用的客户端比较老的话，也不支持 h2c 。 现在有没有同时支持 h2c 和 HTTP 1.1 ，并支持自动 upgrade 到 h2c 的实现方案啊？ |
 | 25 janxin 2022-09-26 08:55:12 +08:00 你这么问应该是没用 mTLS... 当然只考虑性能，自然还是抛弃 TLS 更好 |
 | 26 ZE3kr 2022-09-26 09:11:47 +08:00 via iPhone 对内网还是很有帮助的，对 localhost 没啥帮助 |
 | 27 julyclyde 2022-09-26 09:46:40 +08:00 所谓负优化，很多时候其实体现在不方便 tcpdump 吧 正常工作状态只是优化意义小，谈不上负 |
 | 28 oeanthe1h 2022-09-26 11:47:48 +08:00 个人理解，对于 web 界面来说，H2 多路复用可以让多个小图片对用户呈现同步加载的效果，对于服务器的响应包来说，以字节流为单位的多路复用好像意义不大，服务器需要完整的响应包才能有效解析，如果以包为单位的多路复用，好像 NIO 的 channel 就能够实现在一条 TCP 连接作为逻辑连接，也没必要使用传输层的分帧 |
 | 29 darknoll 2022-09-26 12:58:05 +08:00 做个对比测试不行吗？上来就谈我感觉怎么样怎么样。 |
1
Select Language