历史

了解 protobuf 的创建原因以及随着时间推移改变它的决策，可以帮助你更好地使用该工具的功能。

为什么发布 Protocol Buffers？

我们发布 Protocol Buffers 有几个原因。

Google 内部的许多项目都使用了 Protocol Buffers。我们还有其他希望以开源形式发布、且使用了 Protocol Buffers 的项目，所以为此，我们需要先发布 Protocol Buffers。事实上，这项技术的一些部分已经进入了开源领域；如果你深入研究 Google AppEngine 的代码，可能会发现一些。

我们希望提供既接受 protocol buffers 也接受 XML 的公共 API，这既是因为它更高效，也是因为无论如何我们都会在后端将 XML 转换为 protocol buffers。

我们认为 Google 外部的人可能会觉得 protocol buffers 有用。将 protocol buffers 整理成我们乐于发布的形式是一个有趣的附带项目。

为什么第一个发布版本是版本 2？版本 1 发生了什么？

protocol buffers 的初始版本（“Proto1”）始于 2001 年初，并在多年中不断演进，每当有人需要新功能并愿意付出工作去创建时，就会增加新功能。像所有以这种方式创建的东西一样，它有点混乱。我们得出的结论是，按照当时的状态发布代码是不可行的。

版本 2（“Proto2”）是完全重写，尽管它保留了大部分设计并使用了 Proto1 中的许多实现思路。一些功能被添加，一些被移除。然而，最重要的是，代码得到了清理，并且没有任何尚未开源的 Google 库依赖。

为什么命名为“Protocol Buffers”？

这个名字起源于格式的早期，那时我们还没有 protocol buffer 编译器来为我们生成类。当时，有一个名为 ProtocolBuffer 的类，它实际上充当了单个方法的缓冲区。用户通过调用 AddValue(tag, value) 之类的方法，单独向此缓冲区添加 tag/value 对。原始字节存储在一个缓冲区中，消息构造完成后可以将其写入。

从那时起，名字中的“buffers”部分已经失去了其含义，但它仍然是我们使用的名称。今天，人们通常使用“protocol message”来抽象地指代一个消息，使用“protocol buffer”来指代消息的序列化副本，使用“protocol message object”来指代表示已解析消息的内存对象。

Google 对 Protocol Buffers 拥有专利吗？

Google 目前没有关于 protocol buffers 的已颁发专利，我们乐于解决人们可能对 protocol buffers 和专利产生的任何疑虑。

Protocol Buffers 与 ASN.1、COM、CORBA 和 Thrift 有何不同？

我们认为所有这些系统都有各自的优缺点。Google 内部依赖于 protocol buffers，它们是我们成功的关键组成部分，但这并不意味着它们是解决所有问题的理想方案。你应在你自己的项目背景下评估每种替代方案。

然而，值得注意的是，其中一些技术既定义了交换格式，也定义了 RPC（远程过程调用）协议。Protocol buffers 只是一种交换格式。它们可以轻松地用于 RPC——实际上，它们确实有限地支持定义 RPC 服务——但它们不与任何特定的 RPC 实现或协议绑定。