RPC英文全称Remote Procedure Call，翻译过来即【远程过程调用】
通常在开发中并不会把所有的功能都塞进一个篮子里（项目、解决方案等等），这样来说并不利于维护，代码臃肿，难于排错，对后期的扩展都是灾难性的，为了解决这个问题就需要对逻辑进行拆分，基于业务或者功能拆分到多个模块，模块间有相应的依赖关系，在单机上似乎是用多个类库的方式体现，比如一个程序去引用其他的jar或者其他dll，执行里面提供的接口去完成某一件事情；
而单机又会引出一定的问题，单点、容量、性能等，循序渐进的发展为分布式架构，不同的功能可能会分散在不同的机房、城市、国家等等，中间的通信也就需要通过网络来完成（这里暂不关心网络可能引发的问题，先认为网络正常），过程的执行通常可能会包含参数的传入，和执行后的相应的结果接收
比如A调用B，需要传入参数1和2，B执行1+2，返回结果3，此时只需要2个参数1和2，但接口总是很多样，肯定有其他接口存在其他类型的参数和数量的不同，而在执行调用和接收结果的逻辑又在一遍又一遍的重复，此时就需要一个双方都遵守的约定即传输协议出现，以消除模板代码，以更通用的格式去处理数据的传入和返回；
协议种类：
目前已存在很多这样的协议，如：SMTP, POP, FTP, IMAP, HTTP等等，除此之外任何人也能够在自己去定义协议的内容，只要双方遵守，就是个有效的协议，本文只简单探讨一下HTTP和自定义协议
对于HTTP协议相信所有的开发人员都很熟悉，协议内容报文 通常包含了多个header和一个body（或者没有），接收方通过HTTP协议格式去解析内容获得相应的结果，然后根据结果去决定执行某一段逻辑，在执行完毕之后，如果需要有返回值的话，会把返回值在以HTTP协议格式包装出一个报文，响应给调用方，调用方在解析...处理...调用...等等
一切看上去似乎都很美好，利用HTTP似乎可以处理任何类型的数据，然而一切并没有这么美好
HTTP头可能包含了本次调用并无用处的东西，而且协议内容是以文本编码的方式，产生了额外的字节，对于真正有用的数据来说，无效字节占用的大部分...在大并发下，有大量的无效传输占用了网络带宽，而假如我们的传入内容以字节码的形式：
4 bits表示执行的逻辑类型，8 bits表示参数长度后跟上参数，这样的方式即可以以更少的传入内容达到相同的目的，但是有利有弊，这样就需要需要自己去编写编码节码代码。
DUBBO就是使用了自定义协议的方式，格式更加的紧凑，减少传输中的带宽损耗。
原文：https://www.cnblogs.com/zhujiayi/p/13033813.html