背景

Protocol Buffer是google自定义的数据传输协议，目前已经被广泛用于服务端和客户端间的数据传输，清晰理解Protocol Buffer的使用以及语法就显得很重要，本文对Protocol Buffer语法分析是基于proto3.

传输协议对比

目前使用最广泛的数据传输协议为JSON，JSON是一种轻量级的数据交换格式而且层次和结构比较简单和清晰，这里主要对比一下Protocol Buffer和JSON的对比，给出优势和劣势：

优势

传输数据更小
序列化和反序列化更快
由于传输的过程中使用的是二进制，没有结构描述文件，无法解析内容，安全性更高

劣势

由于传输过程使用的是二进制，自解释性较差，需要原有的结构描述文件才能解析

实际数据对比

序列化速度：比JSON快20-100倍
数据大小：序列化后体积小3倍

使用流程

Protocol Buffer的使用流程总体可以分为三步，如下图所示：

根据业务创建并定义proto文件
使用Google Protocol Buffer 提供的工具生成对应语言的源文件
将源文件拷贝到工程中，使用Protocol Buffer提供的库序列化或反序列化数据

语法解析

在使用Protocol Buffer之前需要清楚理解其语法定义，本文对Protocol Buffer的语法解析是基于proto3版本

简单示例

首先创建一个.proto文件，并且在文件中声明如下内容:

syntax = "proto3";

message SearchRequest {
  string query = 1;
  int32 page_number = 2;
  int32 result_per_page = 3;
}

其中第一行标明当前proto使用的版本为proto3，后面定义了一个结构体SearchRequest，结构体中共3个属性。

字段

在整个proto文件中分为基本类型和结构类型，其中结构类型主要为:

message
enum
map

下面分别介绍一下不同结构的作用及规定：

message

message声明

message表示一个结构，类似于java中类，一个proto文件中可以声明多个message结构：

message SearchRequest {
  string query = 1;
  int32 page_number = 2;
  int32 result_per_page = 3;
}

message SearchResponse {
 ...
}

message引用

message可以引用不同proto文件中的message，只要在proto文件中的最上面声明import即可，如下所示：

import "myproject/other_protos.proto";

message继承

meesage 可以使用extend来继承另外一个message，并且使用其中的属性，这里注意一下由于每个message中需要对属性进行编号，在继承的时候需要注意编号，防止重复使用

enum

enum使用

enum使用很简单，直接在message中声明enum结构体并且将属性声明为对应的enum即可：

message SearchRequest {
  string query = 1;
  int32 page_number = 2;
  int32 result_per_page = 3;
  enum Corpus {
    UNIVERSAL = 0;
    WEB = 1;
    IMAGES = 2;
    LOCAL = 3;
    NEWS = 4;
    PRODUCTS = 5;
    VIDEO = 6;
  }
  Corpus corpus = 4;
}

上面代码中Corpus就是一个enum

enum规定

在proto3中，enum第一个值必须为0，主要是为了和基础类型的默认值保持一致

map

map是proto3新加的，使用也很简单：

map<key_type, value_type> map_field = N;

在proto2中可以使用repeated和message结构自定义map，如下所示

message Person {
    string key = 1;
    string value = 2;
  }
repeated Person  person = 4;

基础类型

proto中基础类型有很多，下面给出不同的基础类型对应的java中的类型，及其特点：

proto 类型	java类型	备注
double	double
float	float
int32	int	可变长度编码，如果有负值，可以使用sint32修饰
int64	long	可变长度编码，如果有负值，可以使用sint64修饰
uint32	int	可变长度编码
uint64	int	可变长度编码
sint32	int	可变长度编码，用来表示负值时效率比int32更高
sint64	long	可变长度编码，用来表示负值时效率比int64更高
fixed32	int	4个字节，当数值>2^28时效率比uint32高
fixed64	long	8个字节，当数值>2^56时效率比uint64高
sfixed32	int	4个字节
fixed64	long	8个字节
bool	boolean
string	String	UTF-8 encoded or 7-bit ASCII text, 长度不能超过2^32
bytes	ByteString	长度不超过2^32，任意顺序的字节数据

其中部分基本类型修饰符长度不确定，主要采用了可变长度编码，这也是为什么Prorocol Buffer序列化后的数据字节更少，这个后面原理篇会介绍。

默认值

基础类型的默认值如下：

string：空串
bytes：空字节
bool：false
数字类型：0
enum：默认值是第一个元素，且值必须为0

字段修饰符

singular：一个格式良好的消息应该有0个或者1个这种字段（但是不能超过1个）
repeated：在一个格式良好的消息中，这种字段可以重复任意多次（包括0次），重复的值的顺序会被保留，类似于java中的list

在proto3中，repeated的标量域默认情况下使用packed，也就是可变长度编码

字段编号

先看下一个简单的proto文件：

message SearchRequest {
  string query = 1;
  int32 page_number = 2;
  int32 result_per_page = 3;
  enum Corpus {
    UNIVERSAL = 0;
    WEB = 1;
    IMAGES = 2;
    LOCAL = 3;
    NEWS = 4;
    PRODUCTS = 5;
    VIDEO = 6;
  }
  Corpus corpus = 4;
}

message SearchRequest 中的所有字段都声明了字段编号，这里需要注意：

字段编号从1开始，不可重复定义
字段编号1-15尽量保持经常访问的字段使用，因为1-15编号在传输的过程中只占用1个字节

字段扩充

日常开发过程中，由于需求的变更，往往需要增加字段，这就涉及到字段的扩充，字段扩充需要达到一个目的：兼容

所以Protocol Buffer在字段扩充中定义了如下规则：

不要修改已经存在的字段标号
不用的字段，可以删除，但是编号一定不可以再次使用，建议将字段标为废弃，如加前缀："OBSOLETE_"

只要记住上述规则，就能完成字段扩充且老版本也能兼容

生成对应语言文件

当proto文件编写后，就需要生成对应语言的源文件，生成操作如下：

protoc --proto_path=IMPORT_PATH --cpp_out=DST_DIR --java_out=DST_DIR --python_out=DST_DIR --go_out=DST_DIR --ruby_out=DST_DIR --objc_out=DST_DIR --csharp_out=DST_DIR path/to/file.proto

IMPORT_PATH: proto文件中import的proto文件地址
XX_out:对应源文件输出地址
proto Path:源proto文件

原理简介

Protocol Buffer 更快更小的主要原因如下：

数据在序列化的时候不会传输字段名，只会传输字段标号，并且没有被设置值的字段是不会序列化和传输
采用可变长度编码，优化数据占用

总结

以上基于proto3讲述了Protocol Buffer的语法和使用流程，其中简单说明了Protocol Buffer为什么更快，更小，后面会详细介绍其原理