与 JSON 相比,作为协议缓冲区发送时消息的大小如何减小

Posted

技术标签:

【中文标题】与 JSON 相比,作为协议缓冲区发送时消息的大小如何减小【英文标题】:How size of message gets reduced when sent as Protocol Buffers as compare to JSON 【发布时间】:2021-09-26 11:40:54 【问题描述】:

我正在学习gRPC。我知道使用协议缓冲区发送消息时会减小消息的大小。

// JSON - 55 bytes

  "age": 35,
  "first_name": "Stephane",
  "last_name": "Marrek"

协议缓冲区中的相同消息,

// Binary - 20 bytes
message Person 
  int32 age = 1;
  string first_name = 2;
  string last_name = 3;

    JSON 以字符串形式传输而协议缓冲区以二进制形式传输是什么意思?最后他们不是以二进制形式发送的吗? 与 JSON 相比,协议缓冲区的大小如何减小 解析 JSON 是 CPU 密集型的。反序列化二进制协议缓冲区怎么样?

【问题讨论】:

【参考方案1】:
    JSON 以字符串形式传输而协议缓冲区以二进制形式传输是什么意思?最后他们不是以二进制形式发送的吗?

让我们从基本的角度来理解这一点。

gRPC 是一种通过 HTTP 2.0 协议实现 RPC(远程过程调用)API 的技术。这被广泛用于构建微服务,其中两个服务可以以更有效的方式相互通信。协议缓冲区是 gRPC 框架用来利用此基础架构的 IDL(接口定义语言)。这类似于我们在 SOAP 世界中看到的 WSDL。

对于服务间通信,我们通过网络传递消息。在更传统的情况下我们会遇到 JSON、XML 在服务之间传输消息。这些类型的消息可以通过任何支持的 HTTP 协议以基于文本的形式传输。这些消息携带有效负载以及标头。

在 gRPC 的情况下,它的协议缓冲区定义了消息格式以及对这些消息进行编码和解码的机制。该消息通过 HTTP 2.0 传输,HTTP 2.0 是一种二进制协议,意味着数据以二进制格式传输。以二进制格式传输这些消息的是 HTTP 2.0 基础设施。这里的消息不需要所有繁重的模式(与基于文本的 JSON 不同),所有的标头都被压缩,这反过来又减少了开销、减少了延迟并提高了性能/吞吐量。

而 gRPC 为其奠定了基础。它提供了对这些消息进行编码和解码的机制。

总结:- 所以在 gRPC 的情况下,这些消息通过 HTTP 2.0 以二进制格式传输,而在 JSON 的情况下,这些消息通过任何基于文本的 HTTP 协议传输。

    与 JSON 相比,协议缓冲区的大小如何减小

正如我所解释的,我们在 gRPC 消息通信中不需要与 JSON 不同的模式。这可以节省所有这些字节。您只需发送数据字节,在另一端,如果需要,gRPC 框架将负责反序列化它。

    解析 JSON 是 CPU 密集型的。反序列化二进制协议缓冲区怎么样?

gRPC 具有二进制序列化/反序列化。这很快。简单来说,你可以这样理解。在基于文本的编码的情况下,解码器首先将消息翻译成机器可读的格式,然后我们对其进行处理。在二进制数据的情况下,这种开销可以大大减少。

【讨论】:

【参考方案2】:

JSON 文档以某种 UTF 编码传输。通常是 UTF-8,但允许使用 UTF16 BE 和 LE,以及 UTF32 BE 和 LE。 JSON 是人类可读的文本。

由于字段名称(年龄、名字、姓氏)以 JSON 格式传输,因此数据量大大减少。包含 10,000 个字符串的数组几乎不会减少大小。

我有一个运输应用程序,它在启动时会读取大约 10 MB 的 JSON 数据。几年前,这在 iPhone 4s 上是可以接受的。在现代 iPhone 上,完全没有汗水。

专业人士的 JSON:无需使用任何工具,即可将任何第三方代码添加到您的应用中。非常灵活的计划外扩展,因为 JSON 从字面上描述了它包含的内容。除非您有证据表明使用协议缓冲区可以提高销售额或为您节省资金,否则请使用 JSON。

【讨论】:

此答案不针对所提出的问题。请改进它谢谢。

以上是关于与 JSON 相比,作为协议缓冲区发送时消息的大小如何减小的主要内容,如果未能解决你的问题,请参考以下文章

MQTT-QoS与协议流程

将协议缓冲区编码的消息从 Python 服务器发送到 Java 客户端

文本协议的设计与实现-1

阻塞IO和非阻塞IO

粘包现象

为啥特定的 UDP 消息总是低于特定的缓冲区大小?