thrift的binaryprotocol协议分析

thrift的binaryprotocol协议分析 

出处:http://hi.baidu.com/yancncen/blog/item/b6e0ad38031b06cbd4622547.html)

联系作者,请加qq:1-1-3-8-5-7-1-5-4

thrift里的c++ lib支持很多种协议,不过鉴于有些协议在别的语言的thrift lib并没有得到支持,如php只支持binaryprotocol协议。所以,建议交互都走binaryprotocol协议,在此也只分析 binaryprotocol的协议。

废话不说了,直入正题

binaryprotocol协议分析:

使用工具:
strace、tcpdump、vi、thrift及其源码

(1)0-4个字节:
协议版本|消息类型 (对于TBinaryProtocol.cpp而言协议版本为0x80010000和消息类型进行或运算)
其中消息类型包括:call == 1, reply == 2, excetpion == 3

(2)4-8字节:
请求的函数名称的长度,这里假设为functionNameLen


(3)8-functionNameLen字节{functionNameLen为请求函数名的长度}:
请求的函数名称名称

(4)functionNameLen-functionNameLen+4个字节:(4个字节)
请求的序列号
(貌似生成的代码里面,不管是哪个请求序列号都为0)


如果function没有参数:
最后一个字节为0

参数具有以下形式:{类型}{序号}{值}, 详细请看下面的解释

如果function有参数:
(5)functionNameLen+4-functionNameLen+5个字节:(1个字节)
参数1的类型, 包括以下类型:

参数类型表:
T_STOP       = 0,
T_VOID       = 1,
T_BOOL       = 2,
T_BYTE       = 3,
T_I08        = 3,
T_I16        = 6,
T_I32        = 8,
T_U64        = 9,
T_I64        = 10,
T_DOUBLE     = 4,
T_STRING     = 11,
T_UTF7       = 11,
T_STRUCT     = 12,
T_MAP        = 13,
T_SET        = 14,
T_LIST       = 15,
T_UTF8       = 16,
T_UTF16      = 17

(6)functionNameLen+5-functionNameLen+7个字节:(2个字节)
参数序号,取决于你定义的idl文件中参数所定义的序号


(7)接下来的n个字节,取决于参数的类型:

a)对于以下具有固定长度的简单数据类型的参数:
T_STOP       = 0, n==1
T_VOID       = 1,   n==1
T_BOOL       = 2, n==1
T_BYTE       = 3, n==1
T_I08        = 3, n==1
T_I16        = 6, n==2
T_I32        = 8, n==4
T_U64        = 9, n==8 ? (虽然给出了定义,但是TBinaryProtocol.cpp并没有实现,
所以,如果要使用该数据类型的必须注意, 应该使用string类型来代替它
unsigned long long 类型就需要特别注意了)
T_I64        = 10, n==8
T_DOUBLE     = 4, n==8   (double在目标机器上必须是8个字节的,符合IEC-559标准的浮点数,貌似对我们没有影响)
这n个字节就是参数的值。


以下的数据类型被我归为复合数据类型:

b)对于String,这n个字节包含以下内容:
前面4个字节:字符串的长度stringLen
接下来的stringLen个字节:字符串的内容

c)对于struct,这n个字节包含以下内容:
假设这个结构体包含m个字段:(为了便于说明问题,下面所说的字节偏移是相对于struct内部结构而言的)
0-1字节:字段的数据类型
1-3字节:字段序号,取决于你定义的idl文件中参数所定义的序号

   接下来的k个字节:goto (7)
以此类推,直至m个字段
其实,struct的字段和函数参数具有一样的编码方式

d)对于set,这n个字节包含以下内容:(为了便于说明问题,下面所说的字节偏移是相对于set内部结构而言的)
0-1字节:set里面的元素的数据类型
1-5字节:元素个数
假设元素的数据类型的长度为k个字节,那么接下来每k个字节作为一个元素值,至于元素值的分析,请goto(7)
注意,这里和函数参数/struct的区别在于,这里不存在元素的序号值

e)对于list,这n个字节包含以下内容:
和set类似,这里就不重复累赘了。
值得注意的一点是,thrift白皮书提到了“list<type> An ordered list of elements.”,实际上,list在映射到stl的list时并不是经过排序的list。

f)对于map,这n个字节包含以下内容:(为了便于说明问题,下面所说的字节偏移是相对于map内部结构而言的)
0-1字节:key的数据类型。注意,可能是复合数据类型
1-2字节:value的数据类型。
假设key的数据类型的长度为k个字节,value的数据类型的长度为v个字节
那么接下来每k+v个字节作为一个key-value值,
至于key的值的分析和value的值的分析,请goto(7)

总结:
(1)关于定义idl的一些总结,尽量避免定义过于复杂的数据结构。

从上面的协议分析来看,复合数据类型的存在着一个递归包含的关系。
不过thrift在生成封/解包的代码里,并没有出现递归调用来封/解包,而是采用了循环嵌套循环的方式来生成代码,
这种做法避免了频繁递归调用封/解包函数,可提高封/解包的效率。同时带来的问题就是生成的代码量的急剧膨胀。

虽然没有递归调用来封/解包, 如果定义太过于复杂的数据结构也会随之产生多重循环,看下面的例子
假设定义以下一个数据结构:
map< string, list< set<string> > >,thrift将会产生类似于以下的循环来进行封/解包:
foreach (key in map)
{
foreach ( set in map[key] )
{
foreach (string in set )
encode()/decode();  
}
}

假设map,list,set的元素各有100个,这将是一个严重影响性能的地方,应该避免。

(2)建议使用了unsigned long long的字段使用string类型,而不是u64类型,因为目前的thrift不支持。

(3)在网络IO层一个潜在的瓶颈
由于thrift的binaryprotocol协议的包头没有任何的字节描述了整个网络包的长度的信息。
所以thrift的binaryprotocol协议在解包的时候是每次都只能采用从socket读取一个变量的类型接着读取变量的值出来这样的解释方式。
这种解包的方式可能引起的潜在问题:
当请求的client数量非常多,交互的数据量也非常多(这里可能是交互了很多字段,或者使用了太多复合数据类型)时,tcp/ip协议栈的缓冲区可能会被塞满了
还没有被处理的数据,就会严重影响服务质量。

至于为何不提供某些字节来标识整个数据包的长度,是因为thrift的binaryprotocol协议需要支持复杂数据类型,像set,list,map,而这些复合数据类型的大小是难以确定的。
为了支持标识整个数据包长度,封包前需要知道set,list,map的总体大小,那么就需要遍历set,list,map的大小,这是相当不划算,会增加运算逻辑,而且还会导致协议变得很复杂。


(4)如何做到兼容旧接口
当我们的server更新接口的同时,还需要保证旧client能够和新server交互,那么在定义IDL时就需要特别注意。
假设,我们定义以下一个这个一个结构体来交互用户信息。
struct user
{
1:username string,
2:password string,
3:sex i16,
}

当我们需求变更时,假设以下两种情况:
a)需要新增字段, age来表示年龄
struct user
{
1:username string,
2:password string,
3:sex i16,
4:age i32,
}

注意,原来字段的序号标识一定不能被改变,1:username string, 不能改成 5:username string。
此时,如果server是新的,client是旧的,并不影响client的工作,client从server那边收到的包里包含了age的信息,只是没有decode出来而已。

b)删除字段sex,新增字段age
struct user
{
1:username string,
2:password string,
//3:sex i16,
4:age i32, (注意,为了保证a)所定义的client能够和b)的server交互,这里的字段序号必须定义为4)
}

此时,如果server是新的,client是a)所生成的也并不影响和b)的server交互,因为client从server那边收到的包虽然没有包含sex的信息,但是client并不会崩溃,只是缺少了sex的信息。
因此,我们需求变更时,尽量保存旧的字段不要删除,做到只增不减的方式来兼容旧接口。

这里字段序号是唯一标识字段的关键。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值