ProtocolBuf协议说明

ProtocolBuf知识说明

一段Asn.1的故事:

    记得那是8年前，当我开始从事基于电信2G~3G的增值业务网关、网元开发的时候，我被一个叫Asn.1的编码规则所征服和吸引，但苦于当时自己技术能力有限，对于想写出一套基于Asn.1转C/C++的生成工具而无能为力，无奈之下，只好使用华为给出的一套生成工具，然而，苦逼的是，华为这套工具是要收取服务费的，费用大概在2万左右每年，对于当时的公司来说，其实并不算什么，但年年收费不说，发现有问题时，对于财大气粗的华为来说，并不愿意更改或者根本就鄙视使用者的能力和水平。好吧，自己当时能力确实有限，所以，只能围着这套工具生成器而到处想方设法规避一些问题。

    然而，用了两年之后，公司似乎考虑看着每次支付的费用不多，但年年支付看来还是过于昂贵，可是苦于当时整个公司或者说当时整个软件行业一个针对Asn.1编码规则免费开发的工具，于是，和华为进行一次性的买卖谈判，但没有成功。后来，公司通过多方发力，购买了一套美国一家公司的Asn.1语言转换工具，在我经过一番研究之后，感觉比华为的还要好用一点，于是经过二次封装之后，开始使用。

    后来自以为可以出来闯一番的我，离开了原公司，告别了多年相处的好友和同事，开始闯荡，然而，前进的路比我想想的要曲折好多，直至今日，我也还在闯荡的路上，伤痕累累之外，已经没有了先前的锐气，也失却了往昔的激情，唯一的慰藉就是，依然还走在技术的道路上。

初识ProtocolBuf

    那是在两年前，我进入一个公司，担任公司首席架构师，在设计架构一个综合性大平台的时候，在设计架构业务类的数据传输协议的时候，对于追求数据传输性能和带宽都有严格要求的我，在XML、Json和自定义数据结构之间产生了矛盾，那时的我，对Asn.1念念不忘，但基于公司项目进度，我无暇去实现一套基于Java\c\c++\php\c#的转换工具，无奈的我选择了当时主流的Json，但对于Json，我内心中时时刻刻都有想换掉它的想法。一个偶然的机会，我在面试一个做游戏的程序员时，在问询他如何实现网游数据的高效实时传输而又不对带宽造成太大的压力时，他脱口说出了ProtocolBuf,顿时，我来了兴趣，详细询问了他对于ProtocolBuf的一些情况：“google公司发布的一套开源编码规则，基于二进制流的序列化传输，可以转换成多种编程语言，几乎涵盖了市面上所有的主流编程语言。”

    听完这些，我有一种井底之蛙的感觉，这么好的东西，我怎么就没听说过呢？这简直和Asn.1完全一样呀，优秀到极点的东西为啥用的人不多呢？于是，我马上录用了这个家伙，并开始着手研究其ProtocolBuf来。

详解ProtocolBuf

    在经过一番研究之后，我彻底被其所吸引，于是，我决定立即停掉正在使用的Json，所有业务数据传输全部使用ProtocolBuf协议规则，要求大家加班加点，在一个月之内替换整个业务数据，几乎每天晚上的连续工作到凌晨之后，终于完成，嗯，一切都很好。

ProtocolBuf伪码编写格式

    从开始研究ProtocolBuf开始，我总感觉他是抄袭Asn.1的，因为伪码格式几乎完全一样。都需要先写一个符合格式要求的伪码数据协议并且格式相似，下面是ProtocolBuf的伪码格式,扩展名一般为.pro；

枚举类型数据定义:

//操作类型

enum e_MsgOper_PRO

{

         E_ADD_PRO= 0;                       

         E_DEL_PRO= 1;

         E_MOD_PRO= 2;

}

//用户角色

enum e_RoomRoles_PRO

{

         E_HOST_PRO= 0;                                         //群主

         E_MANGER_PRO= 1;                                  //管理员

         E_NORMAL_PRO= 2;                                  //普通成员

}

通过枚举类型的数据定义来看，有点想C的枚举定义，但是，每个枚举值都是以’;’结束的，并且也不支持typedef而，有点遗憾的是不像C/C++一样，它的枚举值只能大于等于0；为了尽量避免和你的语言内部使用的数据结构发生冲突，最好在Pro文件上加上比较容易识别的后缀，我添加的后缀就是_PRO;

消息类型数据定义:

message HsUserOrderListInfo_Pro                            //用户订单基本信息

{

         requireduint32                                    uOrderID= 1;                                        //订单查询标示;

         optionale_HsOrderState_Pro                   iOrderState= 2;                                   //订单状态ID

         optionalstring                                      szOrderState= 3;                                //订单状态

         optionalstring                                      szOrderType= 4;                                  //订单类型标示;

         optionalstring                                      szOrderTime= 5;                                 //订单生成日期;

}

message HsUserOrderList_Resp_Pro

{

         requirede_HsOperResult_Pro         eOperResult = 1[default = E_HSOPER_SUCCESS_PRO];

         repeatedHsUserOrderListInfo_Pro         Value =2;

}

1、数据类型

Protocol支持的基本数据类型还是比较多的如下表所示：

 N 表示打包的字节并不是固定。而是根据数据的大小或者长度。

   例如int32，如果数值比较小，在0~127时，使用一个字节打包。

   关于枚举的打包方式和uint32相同。

   关于message，类似于C语言中的结构包含另外一个结构作为数据成员一样。

   关于 fixed32 和int32的区别。fixed32的打包效率比int32的效率高，但是使用的空间一般比int32多。因此一个属于时间效率高，一个属于空间效率高。根据项目的实际情况，一般选择fixed32，如果遇到对传输数据量要求比较苛刻的环境，可以选择int32.

2、字段名称

   字段名称的命名与C、C++、Java等语言的变量命名方式几乎是相同的。

   protobuf建议字段的命名采用以下划线分割的驼峰式。例如 first_name而不是firstName.

3、字段编码值

   有了该值，通信双方才能互相识别对方的字段。当然相同的编码值，其限定修饰符和数据类型必须相同。

   编码值的取值范围为 1~2^32（4294967296）。

   其中 1~15的编码时间和空间效率都是最高的，编码值越大，其编码的时间和空间效率就越低（相对于1-15），当然一般情况下相邻的2个值编码效率的是相同的，除非2个值恰好实在4字节，12字节，20字节等的临界区。比如15和16.

   1900~2000编码值为Google protobuf系统内部保留值，建议不要在自己的项目中使用。

   protobuf 还建议把经常要传递的值把其字段编码设置为1-15之间的值。

   消息中的字段的编码值无需连续，只要是合法的，并且不能在同一个消息中有字段包含相同的编码值。

   建议：项目投入运营以后涉及到版本升级时的新增消息字段全部使用optional或者repeated，尽量不实用required。如果使用了required，需要全网统一升级，如果使用optional或者repeated可以平滑升级。

4、默认值

当在传递数据时，对于required数据类型，如果用户没有设置值，则使用默认值传递到对端。当接受数据是，对于optional字段，如果没有接收到optional字段，则设置为默认值。

编程语言转换

ProtocolBuf支持针对多种语言的数据类型转换，当然还是以Java语言的转换最到位，悲催的C++数据转换竟然抹掉了所有的注释说明，因此，使用ProtocolBuf转换后的C++代码，需要你对着.pro文件去细看，还有就是针对C++语言的支持的一个缺陷是，如果数据内容完全相同，只是消息名称不一样的话，也不支持。转换之后，只需把.h和.cc文件加入到工程中，再引入Protocol的动态库即可。关于ProtocolBuf的转换工具也是开源的，虽然不太好用，但也是可以的，如果实在忍受不了，则自己写一个呗。

ProtocolBuf的缺陷;

ProtcolBuf的出现，可以说很好的解决了我的需求：免费、开源、短小、传输效率高，然而，它也有其自身的缺点：那就是还不够成熟，且数据易读性很差，相对Asn.1来说，因为已经是被纳入到国际标准中，并且使用了很长一段时间，因此根据其编码规则，很容易对传输的16进制数据进行抓包分析，通过相对专业的分析，就可以找出其中的问题，但ProtocolBuf是谷歌自己使用和编写出来的，协议尚未纳入到国际表中中去，仅靠抓包和码流分析，难以发现问题，不过，好在其是开源的，可以根据自己的业务数据，写出一套专门的数据拆分工具来，也可以使用网上已有的数据解析工具；另外一点就是调试比较难，发现有问题，调试起来并不能得心应手，因为转换后的语言信息可读性太差。有利就有弊，自己权衡吧。

附：

（转换后的C++代码和使用方法.h）

#include <google/protobuf/generated_message_util.h>

#include <google/protobuf/message.h>

#include <google/protobuf/repeated_field.h>

#include <google/protobuf/extension_set.h>

#include <google/protobuf/unknown_field_set.h>

#include