深入理解 RPC 消息协议设计

本节我们开始讲解 RPC 的消息协议设计背后的基本原理，了解 RPC 的协议开发背后有哪些需要考虑的基本点。在通晓原理之后，我们就可以自己设计一套协议来开发属于自己的 RPC 系统。

本节主要涉及的知识点和它们之见的关系如下图：

对于一串消息流，我们必须能确定消息边界，提取出单条消息的字节流片段，然后对这个片段按照一定的规则进行反序列化来生成相应的消息对象。

消息表示指的是序列化后的消息字节流在直观上的表现形式，它看起来是对人类友好还是对计算机友好。文本形式对人类友好，二进制形式对计算机友好。

每个消息都有其内部字段结构，结构构成了消息内部的逻辑规则，程序要按照结构规则来决定字段序列化的顺序。

接下来，我们初步详细拆解。

消息边界

RPC 需要在一条 TCP 链接上进行多次消息传递。在连续的两条消息之间必须有明确的分割规则，以便接收端可以将消息分割开来，这里的接收端可以是 RPC 服务器接收请求，也可以是 RPC 客户端接收响应。

基于 TCP 链接之上的单条消息如果过大，就会被网络协议栈拆分为多个数据包进行传送。如果消息过小，网络协议栈可能会将多个消息组合成一个数据包进行发送。对于接收端来说它看到的只是一串串的字节数组，如果没有明确的消息边界规则，接收端是无从知道这一串字节数组究竟是包含多条消息还是只是某条消息的一部分。

比较常用的两种分割方式是特殊分割符法和长度前缀法。

消息发送端在每条消息的末尾追加一个特殊的分割符，并且保证消息中间的数据不能包含特殊分割符。比如最为常见的分割符是\r\n。当接收端遍历字节数组时发现了\r\n，就立即可以断定\r\n 之前的字节数组是一条完整的消息，可以传递到上层逻辑继续进行处理。HTTP 和 Redis 协议就大量使用了\r\n 分割符。此种消息一般要求消息体的内容是文本消息。

消息发送端在每条消息的开头增加一个 4 字节长度的整数值，标记消息体的长度。这样消息接受者首先读取到长度信息，然后再读取相应长度的字节数组就可以将一个完整的消息分离出来。此种消息比较常用于二进制消息。

基于特殊分割符法的优点在于消息的可读性比较强，可以直接看到消息的文本内容，缺点是不适合传递二进制消息，因为二进制的字节数组里面很容易