既然有HTTP为什么还要有RPC？

1、为什么有HTTP还要有RPC？

socket：客户端 -> 服务端

TCP/UDP的封装 -> socket

纯裸TCP -> 字节粘包问题 -> 划分TCP一大串字节的规则（头身尾）：协议诞生（HTTP/RPC）

HTTP：访问网址

RPC：远程调用服务器（gRPC、thrift）

回到一开始的问题：这个问题是个认知误区，事实上HTTP诞生的时间晚于RPC，所以应该反过来问为什么有RPC还要有HTTP？

2、为什么有RPC还要有HTTP？

C（client）/S架构：RPC，公司内部的服务器调用各成一套体系 -> 演化成现在公司项目的微服务调用方法

B（browser）/S架构：浏览器需要能够丝滑访问任何服务器，HTTP诞生于对统一标准的需要 -> HTTP可以做到内外通吃

3、如果HTTP可以内外通吃，为什么还要用RPC用作公司内部的微服务调用呢？——对比HTTP1.1和RPC的优劣

1）服务发现：HTTP（DNS）、RPC（Redis等中间服务）

2）底层连接形式：RPC会建立连接池，但目前很多语言的网络库中也会给HTTP加连接池

3）传输内容：结构体的序列化和反序列化 -> HTTP1.1注重html页面展示，传输内容以字符串为主（json）；RPC私人定制，可以用更小的protobuf保存结构体，传输字节数据

第三点，RPC胜出，但目前HTTP2已经在性能上大大改善，甚至RPC也会基于HTTP2

回到一开始的问题，为什么还要有RPC，原因是：之前的项目都太老啦，那个时候的HTTP还没有进化得这么完善呢，所以很多都用的RPC，迁移到HTTP当然可以啦，但是程序员懒啊，又不是不能用！╭(╯^╰)╮