与 HTTP/1.1 JSON 的对比:同一接口的延迟和字节数

字节数

实测 · 本机执行输出

  小(id、name、count)             gRPC:请求 97 + 响应 103 = 200 字节;HTTP/1.1 JSON:请求 227 + 响应 184 = 411 字节(JSON 是 gRPC 的 2.06 倍)
  中(+10 个 tag、1 KiB payload)   gRPC:请求 1194 + 响应 1200 = 2394 字节;HTTP/1.1 JSON:请求 1674 + 响应 1631 = 3305 字节(JSON 是 gRPC 的 1.38 倍)
  大(+64 KiB payload)           gRPC:请求 65782 + 响应 65788 = 131570 字节;HTTP/1.1 JSON:请求 87691 + 响应 87667 = 175358 字节(JSON 是 gRPC 的 1.33 倍)

小消息主要差在 HTTP/1.1 每个请求重复发完整的头;大消息差在 JSON 的文本表示和 bytes 的 base64。

单个调用的延迟

实测 · 本机执行输出

  小 Item           gRPC p50 70 µs、p99 136 µs;HTTP/1.1 JSON p50 72 µs、p99 154 µs(p50 之比 1.04)
  64 KiB payload   gRPC p50 215 µs、p99 596 µs;HTTP/1.1 JSON p50 357 µs、p99 631 µs(p50 之比 1.66)

小消息的往返延迟两者几乎一样;消息变大之后,JSON 的编解码和 base64 让延迟明显变长。

并发

实测 · 本机执行输出

  gRPC,1 条连接:         90024 请求/秒,p50 667 µs
  HTTP/1.1 JSON, 1 条连接:   16484 请求/秒,p50 3824 µs
  HTTP/1.1 JSON,64 条连接:   87007 请求/秒,p50 549 µs

HTTP/1.1 一条连接上一次只有一个请求在途,要用很多条连接换并发;gRPC 靠 HTTP/2 多路复用,一条连接就够。

建连

实测 · 本机执行输出

  gRPC:新连接 + 第一次请求 p50 256 µs;HTTP/1.1 JSON:p50 146 µs

gRPC 新建连接比 HTTP/1.1 慢一些,不适合每个请求新建一个连接。以上都是同一台机器、回环网络上 Go 对 Go 的比较,不是普遍结论。

分步演示

与 HTTP/JSON 的对比

本步的对象

本文用到的工具与边界

本机 macOS 27 arm64 / Go 1.27.1 / grpc-go v1.84.0 / protobuf-go v1.36.12 / golang.org/x/net v0.57.0 / protoc 36.2(Homebrew);服务端和客户端都是本机起的 Go 进程(127.0.0.1,端口 9800 以上,不访问任何外部服务);需要看线上字节时用我自己写的 TCP 抓包代理加 golang.org/x/net/http2 的 Framer 解析 HTTP/2 帧;计时用 time.Now 或 perf_counter,数字每次运行会有小幅抖动。HTTP/JSON 一侧是 net/http + encoding/json,gRPC 一侧是 grpc-go + gwpb.Item;两个服务都在一个子进程里;字节数由我写的只数字节的 TCP 代理统计(每次写入增量累加);其余是本机回环的耗时,每档一次运行(并发那一节各 2 秒),有噪声
没有验证:HTTP/2 + JSON(用 h2c 的同一个 JSON 服务)——它能把“多路复用”和“protobuf 编码”两个因素分开;TLS 开启时的比较;跨机器的真实网络;其它 JSON 库(如 jsoniter、sonic)或其它语言;请求头更多(Cookie、鉴权)时 HTTP/1.1 的字节数;流式和长连接场景

下一篇 · GRPC 38

连接池:多少个 ClientConn 合适