Jack Jiang

我的最新工程MobileIMSDK:http://git.oschina.net/jackjiang/MobileIMSDK
posts - 420, comments - 13, trackbacks - 0, articles - 0

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

1、引言

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

 
 
技术交流:

(本文已同步发布于: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"]

}

7、修改字段类型导致协议解析不一致的通信问题

现象:A 服务访问 B 服务,业务逻辑短时间处理完,但整个请求 15s 超时,必现。

直接原因:IDL 类型被修改;并且只升级了服务端(B 服务),没升级客户端(A 服务)。

本质原因:string 是变长编码,i64 是定长编码。由于客户端没有升级,所以反序列化的时候,会把 signTime 当做 string 类型来解析。而变长编码是 T-L-V 模式,所以解析的时候会把 signTime 的低位 4 字节翻译成 string 的 length。

signTime 是时间戳,大整数,比如:1624206147902,转成二进制为:

100000000 00000000 00000001 01111010 00101010 00111011 00000001 00111110

低位 4 字节转成十进制为:378 。

也就是要再读 378 个字节作为 SignTime 的值,这已经超过了整个 payload 的大小,最终导致 Socket 读超时。

注:修改类型不一定就会导致超时,如果 value 的值比较小,解析到的 length 也比较小,能够保证读完。

但是错误的解析可能会导致各种预期之外的情况,包括:

  • 1)乱码;
  • 2)空值;
  • 3)报错:unknown data type xxx (skip 异常)。

8、通信协议带来的常见问题

8.1兼容性

1)增加字段:

通过 skip 来跳过增加的字段,从而保证兼容性。

2)删除字段:

编译生成的解析代码是基于 field_id 的 switch-case 结构,语法结构上直接具备兼容性。

3)修改字段名:

不破坏兼容性,因为 binary 协议不会对 name 进行编码。

8.2Exception

Thrift 有两种 Exception:

  • 1)一种是框架内置的异常;
  • 2)一种是 IDL 自定义的异常。

框架内置的异常包括:

  • 1)方法名错误;
  • 2)消息序列号错误;
  • 3)协议错误。

这些异常由框架捕获并封装成 Exception 消息,反序列化时会转成 error 并抛给上层。

逻辑如下:

另一种异常是由用户在 IDL 中自定义的,关键字是 exception,用法上跟 struct 没有太大区别。

8.3optional、require 实现原理

optional 表示字段可填,require 表示必填。

字段被标识为 optional 之后:

  • 1)基本类型会被编译为指针类型;
  • 2)序列化代码会做空值判断,如果字段为空,则不会被编码。

字段被标识为 require 之后:

  • 1)基本类型会被编译为非指针类型(复合类型 optional 和 require 没区别);
  • 2)序列化不会做空值判断,字段一定会被编码。如果没有显式赋值,就编码默认值(默认空值,或者 IDL 显式指定的默认值)。

9、参考资料

[1] Protobuf从入门到精通,一篇就够!

[2] 如何选择即时通讯应用的数据传输格式

[3] 强列建议将Protobuf作为你的即时通讯应用数据传输格式

[4] APP与后台通信数据格式的演进:从文本协议到二进制协议

[5] 面试必考,史上最通俗大小端字节序详解

[6] 移动端IM开发需要面对的技术问题(含通信协议选择)

[7] 简述移动端IM开发的那些坑:架构设计、通信协议和客户端

[8] 理论联系实际:一套典型的IM通信协议设计详解

[9] 58到家实时消息系统的协议设计等技术实践分享

[10] 金蝶随手记团队的Protobuf应用实践(原理篇)

[11] 新手入门一篇就够:从零开发移动端IM


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



作者:Jack Jiang (点击作者姓名进入Github)
出处:http://www.52im.net/space-uid-1.html
交流:欢迎加入即时通讯开发交流群 215891622
讨论:http://www.52im.net/
Jack Jiang同时是【原创Java Swing外观工程BeautyEye】【轻量级移动端即时通讯框架MobileIMSDK】的作者,可前往下载交流。
本博文 欢迎转载,转载请注明出处(也可前往 我的52im.net 找到我)。


只有注册用户登录后才能发表评论。


网站导航:
 
Jack Jiang的 Mail: jb2011@163.com, 联系QQ: 413980957, 微信: hellojackjiang