可以在没有 gRPC 的情况下使用协议缓冲区吗？答案

【问题标题】：can protocol buffer be used without gRPC?可以在没有 gRPC 的情况下使用协议缓冲区吗？
【发布时间】：2022-12-16 16:00:28
【问题描述】：

大家好，我正在接触 gRPC 和协议缓冲区，并且看到一篇文章提到消息的二进制 protobuf 文件比 Json 对应文件小 5 倍，但在那篇文章中提到这种压缩级别可以只有通过 gRPC 传输才能实现。这个特别的评论“通过 gRPC 传输时可能压缩”，我似乎无法理解，因为我知道协议缓冲区是一种序列化格式，无论 gRPC 如何都可以工作，或者这种理解有缺陷吗？这是什么意思？这是文章和屏幕截图的链接。 https://www.datascienceblog.net/post/programming/essential-protobuf-guide-python/

【问题讨论】：

标签： protocol-buffers grpc grpc-python

【解决方案1】：

你是对的 - Protocol buffers“为大小高达几兆字节的类型化结构化数据包提供序列化格式”并且有很多用途（例如将数据序列化到磁盘，网络传输，在应用程序之间传递数据等）。

文章you reference 说的有点误导

如果我们使用 gRPC 协议传输二进制 Protobuf，我们只能达到这种压缩级别

当您考虑以下段落时，该声明背后的推理会变得更加清晰：

如果 gRPC 不是一个选项，一个常见的模式是使用 base64 编码对二进制 Protobuf 数据进行编码。尽管这种编码不可逆转地将有效负载的大小增加了 33%，但它仍然比相应的 REST 有效负载小得多。

因此，这似乎侧重于通过基于文本的协议 HTTP 传输数据（HTTP/2 稍微改变了这一点）。因为 Profobuf 是二进制格式，所以它通常在通过 HTTP 传输之前进行编码（从技术上讲，它可以使用 application/octet-stream 之类的东西以二进制格式传输）。文章提到了 base64 编码，使用它会增加它的大小。

如果您不使用 HTTP（例如写入磁盘、直接 TCP/IP 链接、Websockets、MQTT 等），则这不适用。

话虽如此，我认为该示例可能有点夸大了 Protobuf 的优势，因为很多 HTTP 流量都被压缩了（this article 报告他们的测试有 9% 的差异）。

【讨论】：

“因为 Profobuf 是一种二进制格式，你需要先对数据进行编码，然后才能通过 HTTP 传输数据（文章提到了 base64 编码），这样做会增加数据的大小。”我觉得这个说法是错误的。我在 StackOverflow 上做了一些搜索，例如 this question，它们似乎都与此声明相矛盾。我相信您混淆了常见的事情和可能的事情。编码二进制数据可能很常见，但不是必需的。标头是文本，但不一定是有效负载。
@GregCobb 你是对的；可以通过 HTTP 发送二进制数据（这种情况经常发生，例如本页上的图像）。 Protobuf 数据可以作为 application/octet-stream 发送，但在这种情况下，文章特别提到了 base-64 编码。

【解决方案2】：

我同意英国人的回答。

一些单独的点。说GPB压缩数据不太准确；它只是以某种方式对数据（例如整数）进行最低限度的编码。如果您发送一条包含 10 个字符串的 GPB 消息，它不会像您期望的 zip 那样压缩它。

GPB 并不是目前最有效的数据编码器。 ASN.1 uPER 甚至更好，能够利用无法在 GPB 模式 .proto 文件中表达的 ASN.1 模式中的知识。例如，在 ASN.1 中，您可以将整数值限制为 1000..1003。在 ASN.1 uPER 中，它是 2 位（有 4 个可能的值）。在 GPB 中，这至少是两个字节的编码数据。

【讨论】：