Protobuf 语法与实现原理

starine
1,337 阅读6分钟

本文已参与「新人创作礼」活动，一起开启掘金创作之路

引言

本文介绍了Protobuf 协议语法以及Protobuf序列化原理。

1、Protobuf 协议语法

  • message：  Protobuf中定义一个数据结构需要用到关键字message，这一点和Java的class，Go语言中的struct类似。Message命名采用驼峰命名方式，字段命名采用小写字母加下划线分隔方式

  • 标识号：  在消息的定义中，每个字段等号后面都有唯一的标识号，用于在反序列化过程中识别各个字段的，一旦开始使用就不能改变。标识号从整数1开始，依次递增，每次增加1，标识号的范围为1~2^29 – 1，其中[19000-19999]为Protobuf协议预留字段，开发者不建议使用该范围的标识号；一旦使用，在编译时Protoc编译器会报出警告。

  • 字段规则：  字段规则有三种：

    • required：该规则规定，消息体中该字段的值是必须要设置的。
    • optional：消息体中该规则的字段的值可以存在，也可以为空，optional的字段可以根据defalut设置默认值。
    • repeated：消息体中该规则字段可以存在多个（包括0个），该规则对应java的数组或者go语言的slice。

  • 字段格式： 限定修饰符 | 数据类型 | 字段名称 | = | 字段标识号 | [字段默认值]

  • 数据类型：  常见的数据类型与protoc协议中的数据类型映射如下：  .proto | C++ | Java | Python | Go | Ruby | C# | | -------- | ------ | ---------- | -------------- | ------- | -------------------- | ---------- | | double | double | double | float | float64 | Float | double | | float | float | float | float | float32 | Float | float | | int32 | int32 | int | int | int32 | Fixnum or Bignum | int | | int64 | int64 | long | ing/long[3] | int64 | Bignum | long | | uint32 | uint32 | int[1] | int/long[3] | uint32 | Fixnum or Bignum | uint | | uint64 | uint64 | long[1] | int/long[3] | uint64 | Bignum | ulong | | sint32 | int32 | int | intj | int32 | Fixnum or Bignum | int | | sint64 | int64 | long | int/long[3] | int64 | Bignum | long | | fixed32 | uint32 | int[1] | int | uint32 | Fixnum or Bignum | uint | | fixed64 | uint64 | long[1] | int/long[3] | uint64 | Bignum | ulong | | sfixed32 | int32 | int | int | int32 | Fixnum or Bignum | int | | sfixed64 | int64 | long | int/long[3] | int64 | Bignum | long | | bool | bool | boolean | boolean | bool | TrueClass/FalseClass | bool | | string | string | String | str/unicode[4] | string | String(UTF-8) | string | | bytes | string | ByteString | str | []byte | String(ASCII-8BIT) | ByteString |

+ N 表示打包的字节并不是固定。而是根据数据的大小或者长度
+ 关于 fixed32 和int32的区别。fixed32的打包效率比int32的效率高，但是使用的空间一般比int32多。因此一个属于时间效率高，一个属于空间效率高

  • 枚举类型：  proto协议支持使用枚举类型，和正常的编程语言一样，枚举类型可以使用enum关键字定义在.proto文件中：

    enum Foo {
  FIRST_VALUE = 1;
  SECOND_VALUE = 2;
}

    Enums类型名采用驼峰命名方式，字段命名采用大写字母加下划线分隔方式

  • 字段默认值：  .proto文件支持在进行message定义时设置字段的默认值，可以通过default进行设置，如下所示：

    message Address {
    required sint32 id = 1 [default = 1];
    required string name = 2 [default = '北京'];
    optional string pinyin = 3 [default = 'beijing'];
    required string address = 4;
    required bool flag = 5 [default = true];
}

  • 导入：  如果需要引用的message是写在别的.proto文件中，可以通过import "xxx.proto"来进行引入：

  • 嵌套：  message与message之间可以嵌套定义，比如如下形式：

    message Outer {                // Level 0
    message MiddleAA {         // Level 1
        message Inner {        // Level 2
            int64 ival = 1;
            bool  booly = 2;
        }
    }
    message MiddleBB {         // Level 1
        message Inner {        // Level 2
            int32 ival = 1;
            bool  booly = 2;
        }
    }
}

  • message更新规则：  message定义以后如果需要进行修改，为了保证之前的序列化和反序列化能够兼容新的message，message的修改需要满足以下规则：

    • 不可以修改已存在域中的标识号。
    • 所有新增添的域必须是 optional 或者 repeated。
    • 非required域可以被删除。但是这些被删除域的标识号不可以再次被使用。
    • 非required域可以被转化，转化时可能发生扩展或者截断，此时标识号和名称都是不变的。
    • sint32和sint64是相互兼容的。
    • fixed32兼容sfixed32。 fixed64兼容sfixed64。
    • optional兼容repeated。发送端发送repeated域，用户使用optional域读取，将会读取repeated域的最后一个元素。

Protobuf 序列化后所生成的二进制消息非常紧凑，这得益于 Protobuf 采用的非常巧妙的 Encoding 方法。接下来看一看Protobuf协议是如何实现高效编码的。

  • service如何定义

    • 如果想要将消息类型用在RPC系统中，可以在.proto文件中定义一个RPC服务接口，protocol buffer编译器会根据所选择的不同语言生成服务接口代码
    • 例如，想要定义一个RPC服务并具有一个方法，该方法接收SearchRequest并返回一个SearchResponse，此时可以在.proto文件中进行如下定义：
        service SearchService {
        rpc Search (SearchRequest) returns (SearchResponse) {}
    }
    • 生成的接口代码作为客户端与服务端的约定，服务端必须实现定义的所有接口方法，客户端直接调用同名方法向服务端发起请求，比较麻烦的是，即便业务上不需要参数也必须指定一个请求消息，一般会定义一个空message

2、Protobuf序列化原理

之前已经做过描述，Protobuf的message中有很多字段，每个字段的格式为：修饰符 字段类型 字段名 = 域号;

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的方式。

在序列化时，Protobuf按照TLV的格式序列化每一个字段，T即Tag，也叫Key；V是该字段对应的值value；L是Value的长度，如果一个字段是整形，这个L部分会省略。

序列化后的Value是按原样保存到字符串或者文件中，Key按照一定的转换条件保存起来，序列化后的结果就是 KeyValueKeyValue…依次类推的样式，示意图如下所示：

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

Order.id = 10;
Order.desc = "bill";

则最终的 Message Buffer 中有两个Key-Value对，一个对应消息中的id；另一个对应desc。Key用来标识具体的field，在解包的时候，Protocol Buffer根据Key就可以知道相应的Value应该对应于消息中的哪一个field。

Key 的定义如下：

(field_number << 3) | wire_type

可以看到 Key 由两部分组成。第一部分是 field_number，比如消息Address中field id 的field_number为1。第二部分为wire_type。表示 Value的传输类型。而wire_type有以下几种类型：

img

avatar
文章
阅读
粉丝