IM通讯协议专题学习(十)：初识 Thrift 序列化协议|json|二进制|字节|序列化协议|算法|通讯协议

本文由字节跳动技术团队杨晨曦分享，本文有修订和改动。

1、引言

本文将带你一起初步认识Thrift的序列化协议，包括Binary协议、Compact协议（类似于Protobuf)、JSON协议，希望能为你的通信协议格式选型带来参考。

技术交流：

- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》
- 开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）

（本文已同步发布于：http://www.52im.net/thread-4576-1-1.html）

2、系列文章

本文是系列文章中的第10篇，本系列总目录如下：

《IM通讯协议专题学习(一)：Protobuf从入门到精通，一篇就够！》

《IM通讯协议专题学习(二)：快速理解Protobuf的背景、原理、使用、优缺点》

《IM通讯协议专题学习(三)：由浅入深，从根上理解Protobuf的编解码原理》

《IM通讯协议专题学习(四)：从Base64到Protobuf，详解Protobuf的数据编码原理》

《IM通讯协议专题学习(五)：Protobuf到底比JSON快几倍？全方位实测！》

《IM通讯协议专题学习(六)：手把手教你如何在Android上从零使用Protobuf》

《IM通讯协议专题学习(七)：手把手教你如何在NodeJS中从零使用Protobuf》

《IM通讯协议专题学习(八)：金蝶随手记团队的Protobuf应用实践(原理篇)》

《IM通讯协议专题学习(九)：手把手教你如何在iOS上从零使用Protobuf》

《IM通讯协议专题学习(十)：初识 Thrift 序列化协议》（* 本文）

另外：如果您还打算系统地学习IM开发，建议阅读《新手入门一篇就够：从零开发移动端IM》。

3、概述

Thrift是 Facebook 开源的一个高性能，轻量级 RPC 服务框架，是一套全栈式的 RPC 解决方案，包含序列化与服务通信能力，并支持跨平台/跨语言。

Thrift整体架构如图所示：

Thrift 软件栈定义清晰，各层的组件松耦合、可插拔，能够根据业务场景灵活组合。

如图所示：

Thrift 本身是一个比较大的话题，本篇文章不会涉及到Thrift的全部内容，只会涉及到其中的序列化协议。

4、 Binary协议

4.1消息格式

这里通过一个示例对 Binary 消息格式进行直观的展示。

IDL 定义如下：

//接口
service SupService {
SearchDepartmentByKeywordResponse SearchDepartmentByKeyword(
1: SearchDepartmentByKeywordRequest request)

//请求
struct SearchDepartmentByKeywordRequest {
1: optional string Keyword
2: optional i32 Limit
3: optional i32 Offset

//假设request的payload如下：
Keyword: "lark",
Limit: 50,
Offset: nil,

4.2编码简图

4.3编码具体内容

抓包拿到编码后的字节流（转成了十进制，方便大家看）。

/* 接口名长度 */ 0 0 0 25
/* 接口名 */ 83 101 97 114 99 104 68 101 112 97 114 116
109 101 110 116 66 121 75 101 121 119 111
114 100
/* 消息类型 */ 1
/* 消息序号 */ 0 0 0 1
/* keyword 字段类型 */ 11
/* keyword 字段ID*/ 0 1
/* keyword len */ 0 0 0 4
/* keyword value */ 108 97 114 107
/* limit 字段类型 */ 8
/* limit 字段ID*/ 0 2
/* limit value */ 0 0 0 50
/* 字段终止符 */ 0

4.4编码含义

1）消息头：

msg_type（消息类型），包含四种类型：

1）Call：客户端消息。调用远程方法，并且期待对方发送响应；
2）OneWay：客户端消息。调用远程方法，不期待响应；
3）Reply：服务端消息。正常响应；
4）Exception：服务端消息。异常响应。

msg_seq_id（消息序号）：

1）客户端使用消息序号来处理响应的失序到达，实现请求和响应的匹配；
2）服务端不需要检查该序列号，也不能对序列号有任何的逻辑依赖，只需要响应的时候将其原样返回即可。

2）消息体：

消息体分为两种编码模式：

1）定长类型 -> T-V 模式，即：字段类型 + 字段序号 + 字段值；
2）变长类型 -> T-L-V 模式，即：字段类型 + 字段序号 + 字段长度 + 字段值。

具体是：

1）field_type：字段类型，包括 String、I64、Struct、Stop 等；
2）fied_id：字段序号，解码时通过序号确定字段；
3）len：字段长度，用于变长类型，如 String；
4）value：字段值。

字段类型有两个作用：

1）Stop 类型用于停止嵌套解析；
2）非 Stop 类型用于 Skip（Skip 操作是跳过当前字段，会在「常见问题 - 兼容性」进行讲解）。

4.5数据格式

定长数据类型：

变长数据类型：

5、Compact 协议

5.1概述

Compact 协议是二进制压缩协议，在大部分字段的编码方式上与 Binary 协议保持一致。

区别在于整数类型（包括变长类型的长度）采用了先 zigzag 编码，再 varint 压缩编码实现，最大化节省空间开销。

那么问题来了，varint 和 zigzag 是什么？

5.2varint 编码

解决的问题：定长存储的整数类型绝对值较小时空间浪费大。

据统计，RPC 通信时大部分时候传递的整数值都很小，如果使用定长存储会很浪费。

举个，对 i32 类型的 7 进行编码，可以说前面 3 个字节都浪费了：

00000000 00000000 00000000 00000111

解决思路：将整数类型由定长存储转为变长存储（能用 1 个字节存下就坚决不用 2 个字节）

原理并不复杂，就是将整数按 7bit 分段，每个字节的最高位作为标识位，标识后一个字节是否属于该数据。1 代表后面的字节还是属于当前数据，0 代表这是当前数据的最后一个字节。

以 i32 类型，数值 955 为例，可以看出，由原来的 4 字节压缩到了 2 字节：

binary编码： 00000000 00000000 00000011 10111011
切分： 0000 0000000 0000000 0000111 0111011
compact编码： 00000111 10111011

当然，varint 编码同样存在缺陷，那就是存储大数的时候，反而会比 binary 的空间开销更大：本来 4 个字节存下的数可能需要 5 个字节，8 个字节存下的数可能需要 10 个字节。

5.3zigzag 编码

解决的问题：绝对值较小的负数经过 varint 编码后空间开销较大举个，i32 类型的负数（-11）

原码： 10000000 00000000 00000000 00001011
反码： 11111111 11111111 11111111 11110100
补码： 11111111 11111111 11111111 11110101
varint编码： 00001111 11111111 11111111 11111111 11110101

显然，对于绝对值较小的负数，用 varint 编码以后前导 1 过多，难以压缩，空间开销比 binary 编码还大。

解决思路：负数转正数，从而把前导 1 转成前导 0，便于 varint 压缩

算法公式 & 步骤 & 示范：

//算法公式
32位： (n << 1) ^ (n >> 31)
64位： (n << 1) ^ (n >> 63)

* 算法步骤：
* 1. 不分正负：符号位后置，数值位前移
* 2. 对于负数：符号位不变，数值位取反

//示例
负数(-11）
补码： 11111111 11111111 11111111 11110101
符号位后置，数值位前移： 11111111 11111111 11111111 11101011
符号位不变，数值位取反(21)： 00000000 00000000 00000000 00010101
正数(11）
补码： 00000000 00000000 00000000 00010101
符号位后置，数值位前移(22)： 00000000 00000000 00000000 00101010

奇怪的知识：为什么取名叫 zigzag？

因为这个算法将负数编码成正奇数，正数编码成偶数。最后效果是正负数穿插向前。

就像这样：

编码前编码后
0 0
-1 1
1 2
-2 3
2 4

6、Json 协议

Thrift 不仅支持二进制序列化协议，也支持 Json 这种文本协议。

数据格式：

/* bool、i8、i16、i32、i64、double、string */
"编号": {
"类型": "值"
//示例
"1": {
"str": "keyword"

/* struct */
"编号": {
"rec": {
"成员编号": {
"成员类型": "成员值"
},

//示例
"1": {
"rec": {
"1": {
"i32": 50

/* map */
"编号": {
"map": [
"键类型",
"值类型",
元素个数,
"键1",
"值1",
"键n",
"值n"

//示例
"6": {
"map": [
"i64",
"str",
1,
666,
"mapValue"

/* List */
"编号": {
"set/lst": [
"值类型",
元素个数,
"ele1",
"ele2",
"elen"

//示例
"2": {
"lst": [
"str",
2,
"lark","keyword"]