计算机网络编程中一个非常基本的问题:该怎样表示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可能是用不同语言编写的,你的编解码方案必须通用且不能和语言绑定
-
编解码方法的性能问题ÿ