1

作为 POC，我正在研究在我的 XML Web 服务中从 Protobuf 序列化的假定速度和低内存（网络）占用空间中受益的可能性。

因此，不要产生如下消息：

<message>
  <author>Bob</author>
  <text>Hello John!</text>
  <date>1351875211751</date>
</message>

我会生产类似的东西

<message>Cg5IZWxsbyBVbmtub3duIRIEQmlsbBiGteSPrCc=</message>

使用我的 Protobuf 消息的 base64 编码。现在，base64 层的引入不会破坏使用 Protobuf 的整个目的（速度和带宽节省）吗？

4

2 回答 2

3

现在，base64 层的引入不会破坏使用 Protobuf 的整个目的（速度和带宽节省）吗？

这取决于数据。如果您有少量具有短名称的字段并且每个值有很多数据，那么是的，它会更大。

如果您有大量具有短值的字段，那么 XML 标记的大小将压倒数据。例如：

<message>
  <verylongname1>x</verylongname1>
  <verylongname2>y</verylongname2>
  <verylongname3>z</verylongname3>
</message>

在 protobuf 格式中，每个字段只需几个字节，而由于在 XML 中有两次名称，每个字段的开销会很大。即使将数据大小乘以用于 base64 编码的常数 4/3，你仍然会更好。

当然，这是假设没有压缩。如果你压缩 XML，很多缺点就会消失——而我不希望 base64 protobuf 也能压缩得差不多。请注意，我们不知道您是否使用压缩。

您还应该考虑 XML 的诊断吸引力 - 无需通过 base64 解码器和 protobuf 打印机运行数据。

底线：这取决于您的数据以及您正在使用它做什么。当然，除了 XML 和 protobuf 之外，还有其他序列化方案。考虑json，例如...

于 2012-11-02T17:09:38.160 回答
0

感谢您的评论和回答。

我意识到在我的二进制序列化消息上保留 XML 信封实际上是没有意义的，除了保留我熟悉的技术堆栈。在这种情况下，它只是迫使我将优化的二进制流转换为 base64（或其他文本）字符串。

如果我想测试或使用Protobuf，我最好单独测试它，而不是将它包装到另一层xml和base64中。我不需要公开 XML Web 服务，而是需要公开内容类型的服务，例如“application/octet-stream”或“application/x-google-protobuf”

于 2012-11-03T13:20:23.253 回答