protobuf 学习
前言
最近由于个人的兴趣转到了消息箱业务线,学习IM相关知识。说到IM,首先会讲到使用TCP协议还是UDP协议;再其次会讲到选择什么样的聊天协议:是基于原生Socket封装的CocoaAsyncSocket,还是基于webSocket的Facebook开源项目SocketRocket,还是基于xmpp的xmppframework;再者会了解到我们传输的数据格式:是Json,还是XML,还是ProtocolBuffer?
今天我们要学习的就是ProtocolBuffer。
简介
Google Protocol Buffer(简称 Protobuf)是Google公司内部的混合语言数据标准,它是一种轻便高效的结构化数据存储格式,可以用于结构化数据串行化,或者说序列化。它很适合做数据存储或RPC数据交换格式。常用于通讯协议、数据存储等领域的语言无关、平台无关、可扩展的序列化结构数据格式。
编码机制
协议封装总体格式
发送一个完整的通讯协议,二进制组成结构:
字段 | 长度 | 说明 |
---|---|---|
PacketLen | 4byte | little-endian |
HeaderLen | 1-5byte | varint |
HeaderData | ||
BodyLen | 1-5byte | varint |
BodyData |
Header和Body字段分别使用自定义编码,基于protobuf
字段编码规则
- FieldTag 表示字段ID序号
- FiledType 表示字段数据类型
- FiledTagAndType 表示字段类型标识符
两者共享一个byte字节呈现
- 3个bit可以标识7种数据类型,当前只定义了四种类型
- 0:varint
- 1:string
- 2:struct(dictionary)
- 3:array
FieldTagAndType = (FiledTag << 3) | FiledType
逆向计算:
FieldTag = FiledTagAndType >> 3
FieldType = FiledTagAndType % 8
具体字段类型编码格式
基本类型:数字(varint:0)
字段特征码 + 值
例如
{3:1}
二进制编码
<<25,1>>
3 << 3 | 1 = 25
基本类型:字符串(string:1)
二进制编码为
字段特征码 + 值长度 + 值
例如
{2: “abcde”}
二进制编码为
<<17,5,97,98,99,100,101>>
2 << 3 | 1 = 17
5 代表字符串长度
97,98,99,100,101 分别代表abcde的ascii编码十进制表示。
基本类型:字典(结构体)(dict:2)
二进制编码为
字段特征码 + 结构体长度 + 每个具体key:value键值对的逐一自我呈现。
例如:
{
0: 1,
1: "abc",
3: {
0: 100,
1: "bcd"
}
}
二进制编码表示为
<<0,1,9,3,97,98,99,26,7,0,100,9,3,98,99,100>>
这里分为三部分: <<0,1>> <<9,3,97,98,99>> <<26,7,0,100,9,3,98,99,100>>
前两部分不细说了,就是上面数字和字符串的规则,重点说第三部分<26,7,0,100,9,3,98,99,100>>
3 << 3 | 2 = 26
结构体长度是100和"bcd“ =>0,100,9,3,98,99,100占了7个字节长度
基本类型:数组(array:3)
二进制编码为:
字段特征码 + 二进制长度 + 数组元素类型 + [每一个具体key:value键值对的逐一自我呈现]
例如:
{
3: [1, 2, 3, 4, 5],
4: ["cde", "def"]
}
二进制编码表示为:
<<27,6,0,1,2,3,4,5,35,9,1,3,99,100,101,3,100,101,102>>
27: 3 << 3 | 3 = 27
6 : 二进制数组长度,后面紧跟着6个字节数组二进制表示(一个类型特征1 + 数组的真正二进制长度5)
0 : 数组元素是数字类型
35: 4 << 3 | 1 = 35
9 : 二进制长度 1,3,99,100,101,3,100,101,102
1 : 元素类型是字符串
protobuf优点:
1、性能好,效率高
时间、控件开销都得到了很大程度的优化。
缺点:
1、可读性较差
这个直接影响开发测试时候的效率。当然,一般情况下,protobuf非常可靠,并不会出现太大的问题。
2、通用性差
protobuf虽然支持了大量语言的序列化和反序列化,但仍然并不是一个跨平台和语言的
传输标准。在多平台消息传递中,对其他项目的兼容性并不是很好,需要做相应的适配
改造工作。相比json 和 XML,通用性还是没那么好。
总结
对于Protobuf的选择来说,一般用于IM通讯,在http传输方案中用的比较少,json可读性要比protobuf好太多。
1、因为TCP所有数据都是二进制数据流传输,需要自己去把二进制数据流转成自己需要的数据协议,Protobuf可以很好的支持这一点,所以Protobuf在TCP传输使用的场景比较多。
2、HTTP是属于应用层的协议,底层传输使用的也是TCP。HTTP已经做了数据解封装操作,我们在使用get和post的时候,我们在开发中可以快速拿到客户端和服务器的传输的数据(一般使用Json)Json可读性好,也能在各个端也能快速的转成Model,所以基本已经满足了大部分公司99%的需求。protobuf的解析快,但是一般app在这块应该没有什么性能的瓶颈,如果对数据解析和节省带宽有要求的话可以使用protobuf。
网友评论