1.protobuf只能用于数据转换，不能用于网络传输，grpc是用protobuf数据转换，netty网络传输，两者结合，grpc是基于HTTP 2.0实现的
rpc 和 HTTP都属于应用层协议，为什么不直接用HTTP呢
相对于 HTTP 的用处，RPC 更多的是负责应用间的通信，所以性能要求相对更高。但 HTTP 协议的数据包大小相对请求数据本身要大很多，又需要加入很多无用的内容，比如换行符号、回车符等；还有一个更重要的原因是，HTTP 协议属于无状态协议，客户端无法对请求和响应进行关联，每次请求都需要重新建立连接，响应完成后再关闭连接。因此，对于要求高性能的 RPC 来说，HTTP 协议基本很难满足需求，所以 RPC 会选择设计更紧凑的私有协议。
怎么设计一个rpc协议呢
1.RPC 每次发请求发的大小都是不固定的，所以我们的协议必须能让接收方正确地读出不定长的内容，需要在头部用固定长度标明协议的长度
2.拿到数据之后，需要按照序列化方式反序列化，所以需要知道序列化的方式
3.想要协议可扩展向后兼容，如果扩展放在协议体里面每次还要反序列化才能拿出来，所以放在协议头合适，那协议头就不能定长了，所以需要一个固定的位置告诉我们协议头具体多长
综上，协议应该分为 协议头 和 协议体 ，两部分都是不定长的，协议头前面有固定字段表示协议头的长度，序列化方式 和协议体的长度 ，协议体里面是序列化的数据，里面是请求的方法和一些参数等信息
常用的序列化协议
1.JSON 可能是我们最熟悉的一种序列化格式了，JSON 是典型的 Key-Value 方式，没有数据类型，是一种文本型序列化框架
json 不好的点有
-
JSON 进行序列化的额外空间开销比较大，对于大数据量服务这意味着需要巨大的内存和磁盘开销；
-
JSON 没有类型，但像 Java 这种强类型语言，需要通过反射统一解决，所以性能不会太好。
2.Protobuf
优点
- 序列化后体积相比 JSON、Hessian 小很多；
- IDL 能清晰地描述语义，所以足以帮助并保证应用程序之间的类型不会丢失，无需类似 XML 解析器；
- 序列化反序列化速度很快，不需要通过反射获取类型；
- 消息格式升级和兼容性不错，可以做到向后兼容
选择序列化方式考虑的因素有哪些
1.序列化与反序列化的性能和效率
2.空间开销，也就是序列化之后的二进制数据的体积大小。序列化后的字节数据体积越小，网络传输的数据量就越小，传输数据的速度也就越快
3.序列化协议的通用性和兼容性
用什么网络io模型
IO 多路复用更适合高并发的场景，可以用较少的进程（线程）处理较多的 socket 的 IO 请求，但使用难度比较高
在 RPC 框架的实现中，在网络通信的处理上，我们会选择 IO 多路复用的方式
RPC 调用在大多数的情况下，是一个高并发调用的场景，考虑到系统内核的支持、编程语言的支持以及 IO 模型本身的特点，在 RPC 框架的实现中，在网络通信的处理上，我们会选择 IO 多路复用的方式
gRPC 的通信协议是基于标准的 HTTP/2 设计的，而 HTTP/2 相对于常用的 HTTP/1.X 来说，它最大的特点就是多路复用、双向流
