当我们要实现一种属于自己的RPC，自然而然应该先想到如何定义一个协议，协议的本质就是解决客户端与服务端通讯过程中遇到的问题。首先，是语义问题，我们必须明确数据流的含义，数据中那些部分是协议头，哪些部分是数据，数据是以什么格式来存储的等等，其次是内容问题，协议头中必须包含哪些字段，这些字段与我们采用的技术，实际实现的需求相关。
首先，实现一个RPC，需要考虑采用什么技术，要实现一种高性能RPC，假如我们使用的是以epoll为基础的I/O多路复用技术，由于tcp是一个流，对于一个流，我们怎么才可以确定一个流中一个段是一次RPC，而另一个段是另外一次RPC所产生的？我们第一个字段就呼之欲出了，我们必须在协议的第一个字段定义该次RPC的流长度，我们才可以通过读取这个字段，确定应该在tcp流中断句断在哪里。所以我们现在得到的RPC协议是这样的：
| 32位数据长度 |
然后我们又想，作为一个RPC服务端，对客户发来的调用进行回复吧？所以我们还需要一个字段来记录客户端的第几次调用。现在我们的协议就是这样的：
| 32位数据长度 |
| 32位调用ID |
对于int，string，double等等的数据类型，如果需要在网络中传输，我们还需要对其进行序列化操作（proto，json等），而网络传输又很慢，我们自然又想到要对传输的数据进行压缩，那么我们现在的协议就是：
| 32位数据长度 |
|||
| 32位调用ID |
|||
| 8位序列化方式 |
8位压缩方式 |
||
做完这些我们可以发现，在不考虑扩展性和其他业务需求的前提下，一个RPC协议就有了一个基本的雏形，最后我们在加上数据段，协议就是如下：
| 32位数据长度 |
|||
| 32位调用ID |
|||
| 8位序列化方式 |
8位压缩方式 |
序列化数据 |
|
| 序列化数据 |
|||
在次基础上，我们就可以更进一步实现自己的一套RPC了。