本文由码农的荒岛求生陆小风分享，为了提升阅读体验，进行了较多修订和排版。
1、引言
搞即时通讯IM方面开发的程序员，在谈到通讯层实现时，必然会提到网络编程。那么计算机网络编程中的一个非常基本的问题：到底该怎样组织Client与server之间交互的数据呢？
本篇文章我们不讨论IM系统中的那些高端技术话题，我们回归到通讯的本质——也就是数据在网络中交互时的编解码原理，并由浅入深从底层理解Protobuf的编解码技术实现。
（本文已同步发布于：http://www.52im.net/thread-4088-1-1.html）
2、系列文章
本文是系列文章中的第 3 篇，本系列总目录如下：
《IM通讯协议专题学习(一)：Protobuf从入门到精通，一篇就够！》
《IM通讯协议专题学习(二)：快速理解Protobuf的背景、原理、使用、优缺点》
《IM通讯协议专题学习(三)：由浅入深，从根上理解Protobuf的编解码原理》（* 本文）
《IM通讯协议专题学习(四)：从Base64到Protobuf，详解Protobuf的数据编码原理》（稍后发布..）
《IM通讯协议专题学习(五)：Protobuf到底比JSON快几倍？请看全方位实测！》（稍后发布..）
《IM通讯协议专题学习(六)：手把手教你如何在Android上从零使用Protobuf》（稍后发布..）
《IM通讯协议专题学习(七)：手把手教你如何在NodeJS中从零使用Protobuf》（稍后发布..）
《IM通讯协议专题学习(八)：金蝶随手记团队的Protobuf应用实践(原理篇) 》（稍后发布..）
《IM通讯协议专题学习(九)：金蝶随手记团队的Protobuf应用实践(实战篇) 》（稍后发布..）
3、共识与协议
针对引言中引出的“到底该怎样组织Client与Server之间交互的数据呢？”。
这个问题可不像看上去那样简单，因为Client进程和Server进程运行在不同的机器上，这些机器可能运行在不同的处理器平台、可能运行在不同的操作系统、可能是由不同的编程语言编写的，Server要怎样才能识别出Client发送的是什么数据呢？
就像这样：
如上图所示，Client给Server发送了一段数据：
0101000100100001
Server怎么能知道该怎样“解读”这段数据呢？
显然：Client和Server在发送数据之前必须首先达成某种关于怎样解读数据的共识，这就是所谓的协议。
这里的协议可以是这样的：“将每8个比特为一个单位解释为无符号数字”。
如果协议是上面这样定义的：那么Server接收到这串二进制后就会将其解析为 81(01010001) 与 33(00100001)。
当然，这里的协议也可以是这样的：“将每8个比特为一个单位解释为ASCII字符”，那么Server接收到这串二进制后就将其解析为“Q!”。
可见：同样一串二进制在不同的“上下文/协议”下有完全不一样的解读，这也是为什么计算机明明只认知0和1但是却能处理非常复杂任务的根本原因，因为一切都可以编码为0和1，同样的我们也可以从0和1中解析出我们想要的信息，这就是所谓的编解码技术。
实际上不止0和1，我们也可以将信息编码为摩斯密码（Morse code）等，只不过计算机擅长处理0和1而已。
扯远了，回到本文的主题。
4、一个例子：远程过程调用（RPC）
作为程序员我们知道，Client以及Server之间不会简单传递一串数字以及字符这样简单，尤其在互联网大厂后端服务这种场景下。
当我们在电商App里搜索商品、打车App里呼叫出租车以及刷短视频时，每一次请求的背后在后端都涉及大量服务之间的交互。
就像这样：
完成一次客户端请求gateway这个服务要“调用”N多个下游服务，所谓“调用”是说A服务向B服务发送一段数据（请求），B服务接收到这段数据后执行相应的函数，并将结果返回给A服务。
只不过对于服务A来说并不想关心网络传输这样的底层细节，如果能像调用本地函数一样调用远程服务就好了，这就是所谓的RPC。
经典的实现方式是这样的：
RPC对上层提供和普通函数一样的接口，只不过在实现上封装了底层复杂的网络通信（当然也包括协议的定义，协议的解解码等）。RPC框架是当前互联网后端的基石之一，很多所谓互联网后端的职位无非就是在此基础之上堆业务逻辑。
本文我们不关心其中的细节，我们只关心在网络层Client是怎样对请求参数进行编码、Server怎样对请求参数进行解码的，也就是本文开头提出的问题。
5、信息的编解码
5.1纯文本的编解码对人类很友好
在思考怎样进行编解码之前，我们必须意识到：
1）Client和Server可能是用不同语言编写的（你的编解码方案必须通用且不能和语言绑定）；
2）编解码方法的性能问题必须要考虑（尤其是对时间要求苛刻的服务）。
首先，我们最应该能想到的就是以纯文本的形式来表示。
纯文本从来都是一种非常有友好的信息载体。为什么？很简单，因为人类（我们）可以直接看懂。
就像这段：
{
"widget": {
"window": {
"title": "Sample Konfabulator Widget",
"name": "main_window",
"width": 500,
"height": 500
},
"image": {
"src": "Images/Sun.png",
"name": "sun1",
"hOffset": 250,
"vOffset": 250,
},
}
}
是不是一目了然：只要我们实现约定好文本的结构（也就是语法），那么Client和Server就能利用这种文本进行信息的编码以及解码，不管Client和Server是运行在x86还是ARM、是32位的还是64位的、运行在Linux上还是Windows上、是大端还是小端，都可以无障碍交流。
因此：在这里，文本的语法就是一种协议（如下图所示）。
顺便说一句：你都规定好了文本的语法，实际上就相当于发明了一种语言。
这里用来举例用的语言就是所谓的JSON，只不过JSON这种语言不是用来表示逻辑（代码）而是用来存储数据的。
JSON就是这个老头提出来的：
除了JSON，另一种利用文本存储数据的表示方法是XML。
来一段XML感受下：
<note>
<to>Tove</to>
<from>Jani</from>
<heading>Reminder</heading>
<body>Don't forget me this weekend!</body>
</note>
相对JSON来说是不是就没那么容易看懂了，自从JSON出现后在Web领域就逐渐取代了XML。
当两段数据量很少的时候——就像浏览器和服务端的交互，JSON可以工作的非常好（如下图所示）。
这个场景就是这样：
在这里是JSON的天下。
5.2纯文本对计算机来说不够友好
在上小节中我们知道，JSON这类纯文本的编解码方式对于人类非常友好。
但对于后端服务之间的交互（或者具体如IM里Client和Server之间的交互）来说就不一样了，后端服务之间的RPC调用可能会传输大量数据，如果全部用纯文本的形式来表示数据那么不管是网络带宽还是性能可能都会差强人意。
在这种场景下，JSON并不是最好的选项，主要原因之一就在于性能以及数据的体积。
我们知道：文本表示对人类是最友好的，对机器来说则不是这样，对机器来说最好的还是01二进制。
那么有没有二进制的编码方法吗？答案是肯定的，这就是当前互联网后端中流行的Protobuf，Google公司开源项目。
那么Protobuf有什么神奇之处吗？
假设Client端想给Server端传输这样一段信息：“我有一个id，其值为43”。
那么在XML下是这样表示的：
<id>43</id>
数一数这这段数据占据了多少字节，很显然是11字节。
而如果用JSON来表示呢？
{"id":43}
数一数这段数据占据了多少字节，显然是9字节。
而如果用Protobuf来表示呢? 是这样的：
//消息定义
message Msg {
optional int32 id= 1;
}
//实例化
Msg msg;
msg.set_id(43);
其中Msg的定义看上去比JSON和XML更加复杂了，但这些只是给人看的，这些还会被protbuf进一步处理。
最终被Protobuf编码为：
1082b
也就是0x08与0x2b，这占据了多少字节呢？答案是2字节。
从JSON的9字节到Protobuf的2字节，数据大小减少了4倍多。
数据量的减少意味着：
1）更少的网络带宽；
2）更快的解析速度。
那么，Protobuf是怎样做到这一点的呢？
6、Protobuf是怎样实现编解码的？
首先，我们来思考最简单的情况，正常情况下，我们该怎样表示数字。
你可能会想这还不简单，统一用固定长度，比如用64个比特（8字节）。
这种方法可行，但问题是不论一个数字有多小，比方2，那么用这种方法表示2也需要占据64个比特（8字节），如下所示。
明明只要一个字节就能表示而我们却用了8个，前面的全都是0，这也太奢侈太浪费了吧。
显然，在这里我们不能使用固定长度来表示数字，而需要使用变长方法来表示。
什么叫变长？意思是说如果数字本身比较大，那么其使用的比特位可以较多，但如果数字很小那么就应该使用较少的比特位来表示，这就叫变长，随机应变，不死板。
那怎样变长呢？
我们规定：对于每一个字节来说，第一个比特位如果是1那么表示接下来的一个比特依然要用来解释为一个数字，如果第一个比特为0，那么说明接下来的一个字节不是用来表示该数字的。
也就是说对于每个8个比特（1字节）来说，它的有效载荷是7个比特，第一个比特仅仅用来标记是否还应该把接下来的一个字节解析为数字。
根据这个规定，假设来了这样一串01二进制：
1010110000000010
根据规定，我们首先取出第一个字节，也就是：
10101100
此时我们发现第一个比特位是1，因此我们知道接下来的一个字节也属于该数字。
将当前字节的1去掉就是：
0101100
然后我们看下一个字节：
00000010
我们发现第一个bit为0，因此我们知道下一个字节不属于该数字了。
接下来我们将解析到的0101100（第一个字节去掉第一个比特位）以及第二个字节0000010（第二个字节去掉第一个比特位）翻转之后拼接到一起（这里之所以翻转是因为我们规定数字的高位在后）。
这个过程就是：
1010110000000010
-> 10101100 | 00000010 //解析得到两个字节
_ _
-> 0101100 | 0000010 //各自去掉最高位
-> 0000010 | 0101100 //两个字节翻转顺序
0000010 + 0101100
-> 100101100 //拼接
最后我们得到了100101100，这一串二进制表示数字300。
这种数字的变长表示方法在Protobuf中被称之为varint。
因此在这种表示方法下，如果数字较大，那么使用的比特就多，如果数字较小那么使用比特就少，聪明吧。
有的同学看到这里可能会问题，刚才讲解的方法只能表示无符号数字，那么有符号数字该怎么表示呢？比如-2该怎么表示？
7、Protobuf的有符号数表示
按照刚才变长编码的思想，-2147483646使用的比特位应该比-2要少。
然而我们知道在计算机世界中负数使用补码表示的，也就是说最高位（最左侧的比特位）一定是1，假设我们使用64位来表示数字，那么如果我们依然用补码来表示数字的话那么无论这个负数有多大还是多小都需要占据10个字节的空间。
为什么是10个字节呢？
不要忘了varint每个字节的有效负荷是7个比特，那么对于需要64位表示的数字来说就需要64/7向上取整也就是10个字节来表示。
这显然不能满足我们对数字变长存储的要求。
该怎么解决这个问题呢？
既然无符号数字可以方便的进行变长编码，那么我们将有符号数字映射称为无符号数字不就可以了，这就是所谓的ZigZag编码，是不是很聪明。
ZigZag编码就像这样：
原始信息 编码后
0 0
-1 1
1 2
-2 3
2 4
-3 5
3 6
... ...
2147483647 4294967294
-2147483648 4294967295
这样我们就可以将有符号数字转为无符号数字，接收方接收到该数据后再恢复出有符号数字。
现在数字的问题彻底解决了，但这仅仅是万里长征第一步。
8、Protobuf的字段名称与字段类型
对于任何一个有用的信息都包含这样几部分：
1）字段名称；
2）字段类型；
3）字段值。
就像C/C++中定义变量时：
int i = 100;
在这里，字段名称就是i，字段类型是int，字段值是100。
刚才我们用varint以及ZigZag编码解决了字段值表示的问题，那么该怎样表示字段名称和字段类型呢？
首先，对于字段类型还比较简单，因为字段类型就那么多。
Protobuf中定义了6种字段类型：
对于6种字段类型我们使用3个比特位来表示就足够了。
接下来比较有趣的是字段名称该怎么表示呢？
假设我们需要传递这样一个字段：
int long_long_name = 100;
那么我们真的需要把“long_long_name”这么多字符通过网络传递给对端吗？
既然通信双方需要协议，那么“long_long_name”这字段其实是Client和Server都知道的，它们唯一不知道的就是“哪些值属于哪些字段”。
为解决这个问题，我们给每个字段都进行编号，比如通信双方都知道“long_long_name”这个字段的编号是2。那么对于“int long_long_name = 100; ”我们该怎么表示呢。
这个信息我们只需要传递：
1）字段名称：2 (2对应字段“long_long_name”)；
2）字段类型：0 (0表示varint类型，参见上图)；
3）字段值：100。
所以我们可以看到，无论你用多么复杂的字段名称也不会影响编码后占据的空间，字段名称根本就不会出现在编码后的信息中，so clever。
9、从宏观上看Protobuf的编码原理
我们已经在Protobuf中看到了数字以及字段名称以及字段类型是怎么表示了，现在是时候从宏观角度来看看多个字段该怎么编码了。
从本质上讲，Protobuf被编码后形成一系列的key-value，每个key-value对应一个proto中的字段。
也就是键值对：
其中value比较简单，也就是字段值；而字段名称和字段类型会被拼接成key。Protobuf中共有6种类型，因此只需要3个比特位即可。字段名称只需要存储对应的编号。
这样就可以这样编码：
(字段编号 << 3) | 字段类型
假设Server接收到了一个key为0x08，其二进制的表示为：
0000 1000
由于key也是利用varint编码的，因此需要将第一个比特位去掉。
这样我的得到：
000 1000
根据key的编码方式，其后三个比特位表示字段类型，即：
000
也就是0，这样我们知道该key的类型是Varint(第0号类型)，而字段编号为抹掉后3个比特位的值，即：
0001
这样，我们就知道了该key对应的字段编号为1，得到编号我们就能根据编号找到对应的编号名称。
10、Protobuf的嵌套数据
与JSON和XML类似，Protobuf中也支持嵌套消息.
就像这样：
message SubMsg {
optional int32 id= 1;
}
message Msg {
optional SubMsg msg = 1;
}
其实现也比较简单，这依然遵循被编码后形成一系列的key-value，只不过对于嵌套类型的key来说，其value是由子消息的key-value组成，如下图所示。
11、Protobuf与编译语言
与JSON一样，Protobuf也是一门语言，兼具了文本的可读性以及二进制的高效。
Protobuf之所以能做到这一点，就好比C语言与机器指令。
C语言是给程序员看的，可读性好。而机器指令是给硬件使用的，性能好。编译器会将C语言程序转为机器可执行的机器指令。
而Protobuf也一样，Protobuf也是一门语言，会将可读性较好的消息编码为二进制从而可以在网络中进行传播，而对端也可以将其解码回来。
在这里Protobuf中定义的消息就好比C语言，编码后的二进制消息就好比机器指令。
而Protobuf作为事实上语言必然有自己的语法。
其语法就是这样：
怎么样，还觉得编译原理没什么用吗？
不理解编译原理是不可能发明Protobuf这种技术的。
12、本文小结
我在写这篇文章时不断感叹，Google的这项技术节省了多少程序员的时间，同时我们也能看到这种基石般的技术依赖的底层原理却非常古老。
比如下面这些：
1）信息的编解码；
2）编译原理。
怎么样，这些是不是远远没有IT界各种流行的技术听上去时髦有趣，而正是这种朴素的技术支撑起了工业界，现在你也应该能明白底层技术的重要性了吧。
13、参考资料
[1]Protobuf官方网站
[4]强列建议将Protobuf作为你的即时通讯应用数据传输格式
[5]APP与后台通信数据格式的演进：从文本协议到二进制协议
[8]简述移动端IM开发的那些坑：架构设计、通信协议和客户端
（本文已同步发布于：http://www.52im.net/thread-4088-1-1.html）
