联系作者，请加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的信息。
因此，我们需求变更时，尽量保存旧的字段不要删除，做到只增不减的方式来兼容旧接口。

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