Ⅰ protobuf 怎么查看版本
protobuf版本需要在protobuf程序中查看。
在protobuf程序中查看版本步骤如下所示：
1、点击打开计算机，进入分区列表。
Ⅱ 怎样在protobuf中添加消息长度和类型
编译后protobuf形成对应的文件，加入工程，创建你的消息对象，给里面的成员赋值，然后将这个对象转化为字节流，用socket函数直接write出去即可。
Ⅲ 了解一下ProtoBuf
我们在进行网络通信调用的时候，总是需要将内存的数据块经过序列化，转换成为一种可以通过网络流进行传输的格式。而这种格式在经过了传输之后再经过序列化，能还原成我们预想中的数据结构。
那么我们对于这种用于中间网络传输的数据格式就有一定的要求。首先它可以准确地描述数据内容，在此基础上我们则希望它尽量的小。
最开始流行起来的是XML，可扩展标记语言。由于它可以用来标记数据、定义数据类型，所以用户可以自己定义数据自己的语言，从而让对不同的数据结构化成统一的格式称为了可能。
而另外一个我们熟知的则是jsON（javaScript Object Notation, JS 对象简谱）。尽管JSON中缺少了XML中的标签属性等描述方式，但是足够简介和清晰的层次结构使得其成为了必XML更受欢迎的数据交换格式。
同一份数据显然JSON的数据量比XML所使用的空间更少。那么空间省略在哪里呢？一方面是json使用更简单的字符来定义数据间的关联关系；另一方面是JSON减少了对数据类型的描述。但是丢少的数据类型再哪里呢？
以Java中的 OpenFeign 举例，JSON中缺少的类型定义被定义道程序中的接口中了。当进行序列化与反序列化时，JSON格式并不记录数据的类型，具体的数据类型在序列化方与反序列化方通过事先约定的接口来进行定义。这样就减少了信息传输过程中的信息量，从而让数据得以压缩。
但是JSON由于没有定义数据类型，所以在传输的过程中实际上就都是文本流，那么这种方法还可以进一步压缩吗？
结合上文的讨论，我们先说结论：方法是有的，并写当前的实现方式是ProtoBuf。但在此之前我们先来了解一下ProtoBuf。
我们可以先看看官方给出的定义与描述：
同样的，ProtoBuf也是一种支持序列化反序列化的方法，并且他具有很多优点：
实际上，ProtoBuf提供了一种通用的数据描述方式，这种定义数据的方式是通用的，就如同JSON或者XML一样。
接下来我们来来回答本节一开始的问题，针对JSON来说，ProtoBuf是如何将体积变得更小的呢？答案很简单，就是为数据序列化反序列化提供更多的先验知识。
本文暂不过度深入ProtoBuf原理，但是可以通过一张图来进行简要说明（）：
ProtoBuf中的数据是按顺序进行排列，而整体的结构为若干个field，每一个field中由 Tag-[Length]-Value 组成。Length是可选的，而是否存在Length是通过Tag的类型来决定的。也就是说如果是指定的类型，比如int64，那我们就可以知道Value的长度，也就不用在依靠Length来对其空间进行描述（redis中的压缩列表也是这个思想）。
那么field应该对应的是什么字段呢？这个则是在序列化与反序列化时在ProtoBuf的服务端与客户端之间进行预先定义的。而因为提前定义了field的类型、排序，所以field本身可以不用对字段名、字段位置进行描述，只需要根据字段类型选用合适的二进制序列化方法，将字段本身的value值进行序列化传输即可。
稍微总结一下：
ProtoBuf通过对传输字段的名称、顺序进行预定义，从而在传输结构中只需要顺序的记录每个字段的类型标签和二进制值。
尽管上文和官方中都是以XML或者JSON来对ProtoBuf进行对比。但是因为ProtoBuf本身就是二进制序列化方式，所以从压缩比上比较感觉有点欺负人。
对应的在Java中二进制常用的序列化器有Kryo和Hessian。但事实上，由于Kryo和Hessian中都需要对Java类名和字段信息进行存储。而ProtoBuf则只有Tag-Length-Value的数据对，且Value更是有针对性的特殊编码，所以空间占用小的很多。
Kryo是专门针对Java进行优化了的。所以在使用的便捷性上来说Kryo则更加方便。但ProtoBuf是跨平台的，且由于进行了字段的顺序定义，所以似的ProtoBuf定义后的接口是可以向前兼容的（只向后追加字段），而这种优势是Kryo所没有的。
ProtoBuf是跨语言的，使用ProtoBuf的第一步是先定一个 proto 文件 ，而由于ProtoBuf 2和3语言版本的不同，其定义格式会有所不同，具体的细节还是得参考官方文档：https://developers.google.cn/protocol-buffers/docs/proto3
对于ProtoBuf 3 的定义文档我们可以按如下方法定义：
其中message关键字是定义的文件名，而 string、int32则是预定的字段类型，repeated则是描述字段为可重复任意多次的字段。
ProtoBuf通过这种形式的文件定义了传输信息的文件结构。
但是之前小节中我们知道了ProtoBuf是通过 Tag-[Length]-Value 组成的数据组来进行信息传输的，那么proto文件中定义的内容如何转换为实际传输的对象呢？
ProtoBuf的做法是，为每一种语言提供一个生成器protoc。通过使用protoc则可以根据.proto文件生成为一组java文件。对应的官方语法演示样例为：
官方的生成参考为：https://developers.google.com/protocol-buffers/docs/reference/java-generated
生成后的java文件将提供对应的实体以及数据的构造方法等文件，从而支持后续的使用。
需要注意的是，ProtoBuf是本质上是序列化方法，具体是通过Spring Cloud 的OpenFeign进行接口调用，还是通过grpc进行接口调用，都是可以的。
本文对ProtoBuff进行了概念的整理，并没有对每个细节都进行深入的梳理，可以当作概念科普来进行阅读。
Ⅳ ProtocolBuffer浅析
ProtocolBuffer是google 定义的一种数据交换的格式，它独立于语言，独立于平台。google 提供了多种语言的实现：java、c#、c++、go 和 python，每一种实现都包含了相应语言的编译器以及库文件。ProtocolBuffer类似于xml、json,不过它更小、更快、也更简单。
目前使用最广泛的数据传输协议为JSON，JSON是一种轻量级的数据交换格式而且层次和结构比较简单和清晰，这里主要对比一下Protocol Buffer和JSON的对比，给出优势和劣势：
优势
劣势
实际数据对比
Protocol Buffer的使用流程总体可以分为三步，如下图所示：
google推荐在Android项目中使用lite版，lite版本生成的java文件更加轻量，其配置如下：
首先创建一个.proto文件，并且在文件中声明如下内容:
在整个proto文件中数据类型分为基本类型和结构类型，其中结构类型主要为:
下面分别介绍一下不同结构的作用及规定：
message表示一个结构，类似于java中类，一个proto文件中可以声明多个message结构：
message可以引用不同proto文件中的message，只要在proto文件中的最上面声明import即可，如下所示：
enum使用很简单，直接在message中声明enum结构体并且将属性声明为对应的enum即可：
在proto3中，enum第一个值必须为0，主要是为了和基础类型的默认值保持一致
map是proto3新加的，使用也很简单：
如下
repeated修饰的属性类似于jsonArray,也类似于java中的List，该修饰符在格式正确的消息中可以重复任意次（包括0次）
日常开发过程中，由于需求的变更，往往需要增加字段，这就涉及到字段的扩充，字段扩充需要达到一个目的： 兼容
所以Protocol Buffer在字段扩充中定义了如下规则：
只要记住上述规则，就能完成字段扩充且老版本也能兼容
Protocol Buffer 更快更小的主要原因如下：
上面这个例子中，在序列化时，”name” 、”count”的key值不会参与，由编号1、2代替，这样在反序列化的时候直接通过编号找到对应的key就可以。需要注意的是编号一旦确定就不可以更改，服务端和客户端通过proto通信的时候需要提前定义号数据格式。
其中Length不一定有，依据Tag确定，例如int类型的数据就只有Tag-Value，string类型的数据就必须是Tag-Length-Value。
Protocol Buffer定义了如下的数据类型，其中部分数据类型已经不再使用：
上面已经介绍了Protocol Buffer的数据结构及Tag的类型，但是Tag块并不是只表示数据类型，其中数据编号也在Tag块中，Tag的生成规则如下：
其中Tag块的后3位表示数据类型，其他位表示数据编号
Java中整数类型的长度都是确定的，如int类型的长度为4个字节，可表示的整数范围为-2 31——2 31-1，但是实际开发中用到的数字均比较小，会造成字节浪费，可变长度编码就能很好的解决这个问题，可变长度编码规则如下：
举个例子：
其中第一个字节由于最高位为1，则后面的字节也是前面的数据的一部分，第二个字节最高位为0，则表示数据计算终止，由于Protocol Buffer是低位在前，整体的转换过程如下：
10000001 00000011 ——> 00000110000001 表示的10进制数为：2^0 + 2^7 + 2^8 = 385 通过上面的例子可以知道一个字节表示的数的范围0-128，上面介绍的Tag生成算法中由于后3位表示数据类型，所以Tag中1-15编号只占用1个字节，所以确保编号中1-15为常用的，减少数据大小。
可变长度编码唯一的缺点就是当数很大的时候int32需要占用5个字节，但是从统计学角度来说，一般不会有这么大的数.
上面介绍了Protocol Buffer的原理，现在通过实例来展示分析过程，我们定义的proto文件如下：
其序列化后的字节数据如下：
前面介绍过Protocol Buffer的 数据结构为TLV，其中L不是必须的，根据T的类型来确定 先看下第一个字节：
这里字节最高位为0，所以该Tag就用这一个字节表示，其中后3位表示类型，前面表示字段编号，所以:
这里字节最高位为0，所以该Tag就用这一个字节表示，其中后3位表示类型，前面表示字段编号，所以: file_num = 0001 = 1 type = 010 = 2 上面介绍过type=2，则后面有Length，按照可变长度编码规则，知道表示长度的字节为：
所以Length=4,则value的长度是4个字节，直接取出后面4个字节：
这4个字节对应的就是test 再看下一组：
由上面的Tag知道： file_num=2 type=0 前面介绍过type=0，后面没有Length，直接就是value，
value=1，通过上面的解析可以知道
上面介绍了Protocol Buffer的原理，解释了为什么Protocol Buffer更快，更小，这里再总结一下：
参考资料：
proto3官网指南： https://developers.google.com/protocol-buffers/docs/proto3
protobuf-gradle-plugin： https://github.com/google/protobuf-gradle-plugin 博客： https://juejin.im/post/5dcbf630e51d451bfe5bb21b
