前言：
很多次看到过这个问题，我自己也有点晕，后面搜了相关资料，基本来自于知乎上大神的回答，网上很多答案都不太靠谱，笔记总结如下，文章最后会放出参考链接，可以交流
RPC是包括很多东西的，传输协议，序列化协议
可以自定义TCP协议
**HTTP ：**然而，如前面所述，基于Restful的远程过程调用有着明显的缺点，主要是效率低、封装调用复杂。当存在大量的服务间调用时，这些缺点变得更为突出。HTTP由于Restful接口的可读性好
**RPC：**服务A调用服务B的过程是应用间的内部过程，牺牲可读性提升效率、易用性是可取的。基于这种思路，RPC产生了。
调用方调用内部的一个方法，但是被RPC框架偷梁换柱为远程的一个方法。之间的通信数据可读性不需要好，只需要RPC框架能读懂即可，因此效率可以更高。通常使用UDP或者TCP作为通讯协议，当然也可以使用HTTP。
动态代理接收到调用后，应该想办法调用远程的实际实现。这包括下面几步：
-
识别具体要调用的远程方法的IP、端口
-
将调用方法的入参进行序列化
-
通过通信将请求发送到远程的方法中
这样，远程的服务就接收到了调用方的请求。它应该：
-
反序列化各个调用参数
-
定位到实际要调用的方法，然后输入参数，执行方法
-
按照调用的路径返回调用的结果
本质上，两者是可读性和效率之间的抉择，通用性和易用性之间的抉择。
其实rpc不是一种协议，rpc是一种调用过程的方案/范式/实现。
http+retrofit同样也可以实现rpc风格的http调用。 dubbo框架同样也支持http(2)传输协议。
拿rpc和http对比没啥意义，应该是拿rpc底层的通信协议（如dubbo/grpc）对http，序列化协议（如hessian/protobuf）对json这样比较才有意义。
RPC不一定在第七层，可能在第四层：
它可以使用tcp或者udp，这样就工作在了第四层。通常，成熟的rpc多使用udp，因为包到达的有序性是可以放弃的。这样比tcp效率更好。
