关于Protocol Buffers的总结

1. protobuf消息的定义

字段格式：
限定修饰符+数据结构+字段名称 = 字段编码值 [字段默认值]

• 限定修饰符 required\optional\repeated
  Required：表示必须字段，即发送方在发送消息的时候必须设置该字段的值，接收方接受时必须识别该字段的值。
  Optional：可选字段。发送方可设置可不设置，接收方能识别就识别，不能识别就忽略。
  Repeated：表示字段可以包含[0, N]个元素，特性与optional一样，可以看做一个数组。
• 数据结构：bool int32 string…
• 字段名称
• 字段编码值
  官方中给的解释：

These numbers are used to identify your fields in the message binary
format, and should not be changed once your message type is in use.

我的理解是 Message最后会被转化成二进制流，这串二进制流是由一个个filed组成的，字段值编码就是用来区分这些Fields的。

2.Google Protocol Buffer 的 Encoding

一种非常巧妙的方法，考察消息结构之前，让我首先要介绍一个叫做 Varint 的术语。

Varint 是一种紧凑的表示数字的方法。它用一个或多个字节来表示一个数字，值越小的数字使用越少的字节数。这能减少用来表示数字的字节数。

Varint 中的每个 byte 的最高位 bit 有特殊的含义，如果该位为 1，表示后续的 byte 也是该数字的一部分，如果该位为 0，则结束。其他的 7 个 bit 都用来表示数字。因此小于 128 的数字都可以用一个 byte 表示。大于 128 的数字，比如 300，会用两个字节来表示：1010 1100 0000 0010

下图演示了 Google Protocol Buffer 如何解析两个 bytes。注意到最终计算前将两个 byte 的位置相互交换过一次，这是因为 Google Protocol Buffer 字节序采用 little-endian 的方式。

消息经过序列化后会成为一个二进制数据流，该流中的数据为一系列的 Key-Value 对。如下图所示：

采用这种 Key-Pair 结构无需使用分隔符来分割不同的 Field。对于可选的 Field，如果消息中不存在该 field，那么在最终的 Message Buffer 中就没有该 field，这些特性都有助于节约消息本身的大小。

以代码清单 1 中的消息为例。假设我们生成如下的一个消息 Test1:

Test1.id = 10;
Test1.str = “hello”；

则最终的 Message Buffer 中有两个 Key-Value 对，一个对应消息中的 id；另一个对应 str。

Key 用来标识具体的 field，在解包的时候，Protocol Buffer 根据 Key 就可以知道相应的 Value 应该对应于消息中的哪一个 field。

Key 的定义如下：

(field_number << 3) | wire_type
可以看到 Key 由两部分组成。第一部分是 field_number，比如消息 lm.helloworld 中 field id 的 field_number 为 1。第二部分为 wire_type。表示 Value 的传输类型。
才考