前言
最近也是在参与谱写 《Kitex前传：RPC那些你不得不知的故事》的 传输协议：如何把信息发出去 部分内容，所以也是重新复习一遍相关协议并输出笔记
一、RPC会在什么地方用到传输协议
根据我们之前的文章，我们现在已经了解到了RPC的一个调用过程了，我们这里再来复习一下
1、客户端client发起服务调用请求。
2、client stub 可以理解成一个代理，会将调用方法、参数按照一定格式进行封装，通过服务提供的地址，发起网络请求。
3、消息通过网络传输到服务端。
4、server stub接受来自socket的消息
5、server stub将消息进行解包、告诉服务端调用的哪个服务，参数是什么
6、结果返回给server stub。
7、sever stub把结果进行打包交给socket
8、socket通过网络传输消息
9、client slub 从socket拿到消息。
10、client stub解包消息将结果返回给client。
一个RPC框架就是把步骤2到9都封装起来。
可以看到，在传输过程第三步和第八步，都用到了网络传输，这里大部分RPC框架的做法都是采用TCP协议，而有人可能会问数据交互为什么用 RPC，不用 HTTP？首先需要指正，这两个并不是并行概念。RPC 是一种设计，就是为了解决不同服务之间的调用问题，完整的 RPC 实现一般会包含有 传输协议 和 序列化协议 这两个。
而 HTTP 是一种传输协议，RPC 框架完全可以使用 HTTP 作为传输协议，也可以直接使用 TCP，使用不同的协议一般也是为了适应不同的场景使用 TCP 和使用 HTTP 各有优势：
（1）传输效率：
- TCP：通常自定义上层协议，可以让请求报文体积更小
- HTTP：如果是基于HTTP 1.1 的协议，请求中会包含很多无用的内容
（2）性能消耗，主要在于序列化和反序列化的耗时
- TCP，可以基于各种序列化框架进行，效率比较高
- HTTP，大部分是通过 json 来实现的，字节大小和序列化耗时都要更消耗性能
（3）跨平台：
- TCP：通常要求客户端和服务器为统一平台
- HTTP：可以在各种异构系统上运行
