资讯

历史

科技

环境与自然

成长

游戏

财经

文学与艺术

美食

健康

家居

文化

情感

汽车

三农

军事

旅行

运动

教育

生活

星座命理

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

创作时间:

作者:

@小白创作中心

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

引用

CSDN

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 的优势

高性能

二进制编码：Protobuf 比 JSON/XML 更紧凑，序列化/反序列化速度更快。
多路复用：基于 HTTP/2，单个连接可并行处理多个请求，减少连接开销。
头部压缩：HTTP/2 的 HPACK 算法显著减少头部大小。

强类型接口

Protobuf 定义：通过 .proto 文件定义服务接口和消息格式，避免手动解析和验证。
代码生成：自动生成客户端和服务端代码，减少开发工作量。

流式通信

四种模式：

一元 RPC（Unary）
客户端流（Client Streaming）
服务器流（Server Streaming）
双向流（Bidirectional Streaming）

适用场景：实时数据传输（如聊天、日志流）。

跨语言支持

官方支持：C++, Java, Python, Go, Ruby, C#, Node.js 等。
一致性：不同语言生成的代码行为一致，减少跨团队协作成本。

内置功能

拦截器：支持中间件模式（如认证、日志、限流）。
超时与重试：内置机制，简化容错设计。

三、HTTP 的优势

通用性

广泛支持：几乎所有编程语言和框架都支持 HTTP。
工具生态：丰富的调试工具（如 Postman、curl）和监控方案（如 Prometheus）。

可读性

文本格式：JSON/XML 易于人类阅读和调试。
自描述性：无需额外定义接口文档（如 Swagger）。

兼容性

RESTful 风格：符合 Web 标准，易于与现有系统集成。
浏览器支持：直接用于前端与后端通信。

灵活性

无状态：适合分布式系统设计。
缓存支持：利用 HTTP 缓存机制（如 ETag、Cache-Control）提升性能。

部署简单

无需额外依赖：直接运行在 Web 服务器（如 Nginx、Apache）上。
防火墙友好：使用标准端口（80/443），无需特殊配置。

四、适用场景对比

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

五、性能对比

延迟

gRPC：由于二进制编码和多路复用，延迟显著低于 HTTP（尤其是高并发场景）。
HTTP：文本编码和连接开销导致延迟较高。

吞吐量

gRPC：单连接可处理更多请求，适合高吞吐场景。
HTTP：受限于连接数和文本编码，吞吐量较低。

资源占用

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 文件定义数据结构，确保类型安全。