问小白 wenxiaobai
资讯
历史
科技
环境与自然
成长
游戏
财经
文学与艺术
美食
健康
家居
文化
情感
汽车
三农
军事
旅行
运动
教育
生活
星座命理

grpc 和 http 的区别:二进制 vs JSON 编码

创作时间:
作者:
@小白创作中心

grpc 和 http 的区别:二进制 vs JSON 编码

引用
CSDN
1.
https://m.blog.csdn.net/cpxsxn/article/details/145407180

gRPC和HTTP是两种广泛使用的通信协议,各自适用于不同的场景。本文将详细对比它们的核心特性、优势、适用场景以及性能表现,并通过实际案例展示二进制编码与JSON编码的区别。

一、核心特性对比

特性
gRPC
HTTP
协议基础
基于 HTTP/2
基于 HTTP/1.1 或 HTTP/2
数据格式
默认使用 Protobuf(二进制)
通常使用 JSON/XML(文本)
传输效率
高(二进制编码 + 多路复用)
较低(文本编码 + 无多路复用)
流式支持
支持(客户端流、服务器流、双向流)
有限(HTTP/2 支持 Server Push,但不如 gRPC 灵活)
代码生成
支持(通过 Protobuf 生成客户端/服务端代码)
无(需手动编写客户端/服务端代码)
跨语言支持
优秀(官方支持多种语言)
优秀(几乎所有语言都支持 HTTP)
适用场景
高性能、低延迟的微服务通信
通用 Web 服务、RESTful API

二、gRPC 的优势

  1. 高性能
  • 二进制编码:Protobuf 比 JSON/XML 更紧凑,序列化/反序列化速度更快。
  • 多路复用:基于 HTTP/2,单个连接可并行处理多个请求,减少连接开销。
  • 头部压缩:HTTP/2 的 HPACK 算法显著减少头部大小。
  1. 强类型接口
  • Protobuf 定义:通过 .proto 文件定义服务接口和消息格式,避免手动解析和验证。
  • 代码生成:自动生成客户端和服务端代码,减少开发工作量。
  1. 流式通信
  • 四种模式:
    一元 RPC(Unary)
    客户端流(Client Streaming)
    服务器流(Server Streaming)
    双向流(Bidirectional Streaming)
    
  • 适用场景:实时数据传输(如聊天、日志流)。
  1. 跨语言支持
  • 官方支持:C++, Java, Python, Go, Ruby, C#, Node.js 等。
  • 一致性:不同语言生成的代码行为一致,减少跨团队协作成本。
  1. 内置功能
  • 拦截器:支持中间件模式(如认证、日志、限流)。
  • 超时与重试:内置机制,简化容错设计。

三、HTTP 的优势

  1. 通用性
  • 广泛支持:几乎所有编程语言和框架都支持 HTTP。
  • 工具生态:丰富的调试工具(如 Postman、curl)和监控方案(如 Prometheus)。
  1. 可读性
  • 文本格式:JSON/XML 易于人类阅读和调试。
  • 自描述性:无需额外定义接口文档(如 Swagger)。
  1. 兼容性
  • RESTful 风格:符合 Web 标准,易于与现有系统集成。
  • 浏览器支持:直接用于前端与后端通信。
  1. 灵活性
  • 无状态:适合分布式系统设计。
  • 缓存支持:利用 HTTP 缓存机制(如 ETag、Cache-Control)提升性能。
  1. 部署简单
  • 无需额外依赖:直接运行在 Web 服务器(如 Nginx、Apache)上。
  • 防火墙友好:使用标准端口(80/443),无需特殊配置。

四、适用场景对比

场景
推荐协议
原因
微服务通信
gRPC
高性能、强类型、流式支持
实时数据传输
gRPC
双向流、低延迟
浏览器与后端通信
HTTP
浏览器原生支持
公开 API
HTTP
通用性强、易于调试
跨平台数据交换
HTTP
文本格式易于解析
高性能内部系统
gRPC
二进制编码、多路复用

五、性能对比

  1. 延迟
  • gRPC:由于二进制编码和多路复用,延迟显著低于 HTTP(尤其是高并发场景)。
  • HTTP:文本编码和连接开销导致延迟较高。
  1. 吞吐量
  • gRPC:单连接可处理更多请求,适合高吞吐场景。
  • HTTP:受限于连接数和文本编码,吞吐量较低。
  1. 资源占用
  • gRPC:CPU 和内存占用较低(得益于高效编码)。
  • HTTP:资源占用较高(尤其是 JSON 解析)。

六、如何选择?

选择 gRPC 的场景

需要高性能、低延迟的通信(如微服务、实时系统)。
需要强类型接口和代码生成(如跨团队协作)。
需要流式通信(如实时日志、消息推送)。

选择 HTTP 的场景

需要与浏览器或移动端通信。
需要公开 API 或与第三方系统集成。
需要快速原型开发或调试。

七、混合使用建议

在实际项目中,可以结合两者的优势:

内部服务:使用 gRPC 实现高性能通信。
对外 API:使用 HTTP 提供 RESTful 接口。
网关层:通过 API 网关(如 Envoy、Kong)将 HTTP 请求转换为 gRPC。

通过合理选择协议,可以最大化系统性能和开发效率。

八、wireshark截图,对比 protobuf 和 json编码

grpc: protobuf 编码

请求:

响应:

Http:JSON 编码

请求:

响应:

总结:可以看到protobuf 和 json 编码对于同样的业务数据,protobuf编码的数据更紧凑。

对于json:这是一个用 JSON 表示的用户信息:

{
"id": 123,
"name": "Alice",
"email": "alice@example.com"
}
可读性:人类可以直接阅读和理解。
冗余性:字段名(如 "id"、"name")重复出现,占用额外空间。
解析开销:需要将文本转换为内存中的数据结构(如字典、对象),性能较低。
兼容性:几乎所有编程语言都支持 JSON/XML 解析。

对于 protobuf:这是用 Protobuf 定义的相同用户信息:
message User {
int32 id = 1;
string name = 2;
string email = 3;
}
编码后的二进制数据可能是这样的(十六进制表示):
08 7B 12 05 41 6C 69 63 65 1A 10 61 6C 69 63 65 40 65 78 61 6D 70 6C 65 2E 63 6F 6D
紧凑性:去除了冗余信息(如字段名),仅存储数据和元数据(如字段编号)。
高效性:序列化/反序列化速度快,占用带宽和存储空间少。
不可读性:人类无法直接理解二进制数据。
强类型:通过 .proto 文件定义数据结构,确保类型安全。

© 2023 北京元石科技有限公司 ◎ 京公网安备 11010802042949号