神奇的Google二进制编解码技术：Protobuf

计算机网络编程中一个非常基本的问题：该怎样表示client与server之间交互的数据，在往下看之前先想一想这个问题。

共识与协议

这个问题可不像看上去的那样简单，因为client进程和server进程运行在不同的机器上，这些机器可能运行在不同的处理器平台、可能运行在不同的操作系统、可能是由不同的编程语言编写的，server要怎样才能识别出client发送的是什么数据呢？就像这样：

client给server发送了一段数据：

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而已。

扯远了，回到本文的主题。

远程过程调用：RPC

作为程序员我们知道，client以及server之间不会简单传递一串数字以及字符这样简单，尤其在互联网大厂后端服务这种场景下。

当我们在电商App搜索商品、打车App呼叫出租车以及刷短视频时，每一次请求的背后在后端都涉及大量服务之间的交互，就像这样：

完成一次客户端请求gateway这个服务要调用N多个下游服务，所谓调用是说A服务向B服务发送一段数据（请求），B服务接收到这段数据后执行相应的函数，并将结果返回给A服务。

只不过对于服务A来说并不想关心网络传输这样的底层细节，如果能像调用本地函数一样调用远程服务就好了，这就是所谓的RPC，经典的实现方式是这样的：

RPC对上层提供和普通函数一样的接口，只不过在实现上封装了底层复杂的网络通信，RPC框架是当前互联网后端的基石之一，很多所谓互联网后端的职位无非就是在此基础之上堆业务逻辑。

本文我们不关心其中的细节，这里我们只关心在网络层client是怎样对请求参数进行编码、server怎样对请求参数进行解码的，也就是本文开头提出的问题。

信息的编解码

在思考怎样进行编解码之前我们必须意识到：

• client和server可能是用不同语言编写的，你的编解码方案必须通用且不能和语言绑定

• 编解码方法的性能问题ÿ