补充一下，为什么 gRPC 没有采用 HTTP 协议。首先在 OSI 网络模型中，TCP 是属于传输层，而 HTTP 是基于 TCP 之上的应用层，所以 HTTP 协议基于 TCP 协议。如果是通过 HTTP 连接能够发起一个请求，那么使用 TCP 连接同样可以，当然我们也可以基于 TCP 协议自己封装一个类似于 HTTP 的应用层协议。
而 HTTP 协议有一个问题，那就是连接是一次性的，服务端一旦返回结果那么连接就断开了。所以很多时候我们更愿意基于 TCP 连接自己去实现，而不是使用 HTTP，因此对于性能要求高的场景，使用 HTTP 是很麻烦的。所以 HTTP 后来发展到了 2.0 版本，它是可以保持长连接的，我们目前用的都是 1.1。而 gRPC 便是基于 HTTP 2.0 设计的，由于 HTTP 2.0 能完成长连接，那么使用它的好处会非常多，因为它是兼容 HTTP 1.1 的，不需要我们自己再基于 TCP 去封装了。
rpc、http 以及 restful 之间的区别可能这三者之间的概念容易让人产生混淆，下面来区分一下。
rpc 和 http首先我们说如果想实现 rpc，那么必须要先解决两个问题：
1. 数据的序列化和反序列化
2. 网络传输协议
而 http 协议本身属于网络传输协议的一种，想实现 rpc 也需要依赖网络传输协议。而 rpc 不仅可以使用 http 协议，也可以使用 tcp 协议。所以结论很清晰了，http 协议只是实现 rpc 框架的一种选择，你可以选择它，也可以不选择它，因此这两者不是竞争关系。
rpc 和 restfulrpc 和 restful 之间也不是互斥的，我们通常对外提供服务的时候一般都是通过 http 请求的方式。而任何一种请求都是要有一种规范的，正所谓无规矩不成方圆嘛，而是 restful 便是相应的规范。既然是规范，那么我们完全可以不遵守，所以 restful 只是一种规范而已，它和 rpc 之间实际上是没有太大关系的。
使用 Python 开发 rpcrpc 技术在架构设计上由四部分组成，分别是：客户端、客户端存根、服务端、服务端存根。
客户端（client）：服务调用发起方，也称为服务消费者。
客户端存根（client stub）：该程序运行在客户端所在的计算机上，主要用来存储要调用的服务器的地址。另外该程序还负责将客户端请求远程服务器程序的数据信息打包成数据包，通过网络发送给服务端的 stub 程序；其实还要接收服务端 stub 程序发送的调用结果的数据包，并解析返回给客户端。
服务端（server）：远端计算机机器上运行的程序，其中有客户端调用的方法。
服务端存根（server stub）：和客户端存根作用类似，负责接收客户端 stub 程序通过网络发送的请求消息数据包，并调用服务端相应的方法，完成功能调用；然后将调用的结果打包成数据包，发送给客户端的 stub 程序、
了解完了 rpc 技术的组成结构，我们来看一下具体是如何实现客户端到服务端的调用的。实际上，如果我们想要在网络中的任意两台计算机之间实现远程过程调用，需要解决很多问题，比如：
两台物理机器在网络中要建立稳定可靠的通信连接
两台服务器的通信协议的定义问题，即两台服务器上的程序要如何识别对方的请求和返回结果。也就是说，两台服务器必须都能够识别对方发来的消息，并能够解析出其中的请求含义或返回含义，然后才能进行处理，这其实就是数据通信协议所需要完成的工作
我们通过流程图来说明 rpc 每一步的调用过程：
整体逻辑还是很简单的，解释一下的话就是：
1. 客户端想要发起一个远程过程调用，首先调用本地客户端 stud 程序
2. 客户端 stub 程序接收了客户端的功能调用请求，将客户端请求调用的方法名、携带的参数等信息做序列化操作，打包成数据包
3. 客户端 stub 程序查找远程服务器程序的 IP 地址，通过网络发送给服务端的 stub 程序
4. 服务端 stub 程序接收到客户端发送的数据包信息，并使用和客户端 stub 相同的协议对数据包进行反序列化，得到请求的方法名和请求参数等信息
5. 服务端 stub 程序准备相关数据，调用本地 server 对应的功能方法，并传入相应的参数，进行业务处理
6. 服务端程序根据已有业务逻辑执行调用过程，待业务执行结束，将执行结果返回给服务端 stub 程序
7. 服务端 stub 程序将调用结果按照约定的协议进行序列化，并通过网络发送给客户端 stub 程序
8. 客户端 stub 程序接收到服务端 stub 发送的返回数据，对数据进行反序列化操作，然后将最终结果再交给客户端
9. 客户端请求发起者得到调用结果，整个 rpc 过程结束
rpc 中你需要知道的东西