这是一道很常见的面试题目，因为涉及的知识点比较多！！！
首先我们需要明确的是： HTTP和RPC不是对等的概念。

RPC是一个完整的远程调用方案，它包括了：接口规范+序列化反序列化规范+通信协议等。

而HTTP只是一个通信协议，工作在OSI的第七层，不是一个完整的远程调用方案。

所以，要想回答这个问题，应该拉平为一个对等的概念。例如，HTTP+Restful规范+序列化与反序列化，构成一个完整的远程调用方案，再和RPC进行比较。而单纯的HTTP，只是一个通信协议，自然无法和RPC比较。

讲到Http就不得不从TCP讲起。

1.TCP

TCP 是有三个特点，面向连接、可靠、基于字节流。

字节流可以理解为一个双向的通道里流淌的二进制数据，也就是01 串。纯裸 TCP 收发的这些 01 串之间是没有任何边界的，你根本不知道到哪个地方才算一条完整消息。

正因为这个没有任何边界的特点，所以当我们选择使用 TCP 发送“夏洛"和"特烦恼”的时候，接收端收到的就是“夏洛特烦恼”，这时候接收端没发区分你是想要表达“夏洛”+“特烦恼”还是“夏洛特”+“烦恼”。

这就是所谓的粘包问题，

我下面简单介绍一下粘包问题。

1.1 TCP粘包问题

TCP粘包是指发送方发送的若干包数据到接收方接收时粘成一包，从接收缓冲区看，后一包数据的头紧接着前一包数据的尾。

1.1.1 为什么出现粘包现象

（1）发送方原因

我们知道，TCP默认会使用Nagle算法。而Nagle算法主要做两件事：
1）只有上一个分组得到确认，才会发送下一个分组；
2）收集多个小分组，在一个确认到来时一起发送。

所以，正是Nagle算法造成了发送方有可能造成粘包现象。

（2）接收方原因

TCP接收到分组时，并不会立刻送至应用层处理，或者说，应用层并不一定会立即处理；实际上，TCP将收到的分组保存至接收缓存里，然后应用程序主动从缓存里读收到的分组。这样一来，如果TCP接收分组的速度大于应用程序读分组的速度，多个包就会被存至缓存，应用程序读时，就会读到多个首尾相接粘到一起的包。

1.1.2 什么时候需要处理粘包现象

（1）如果发送方发送的多个分组本来就是同一个数据的不同部分，比如一个很大的文件被分成多个分组发送，这时，当然不需要处理粘包的现象；

（2）但如果多个分组本毫不相干，甚至是并列的关系，我们就一定要处理粘包问题了。比如，我当时要接收的每个分组都是一个有固定格式的商品信息，如果不处理粘包问题，每个读进来的分组我只会处理最前边的那个商品，后边的就会被丢弃。这显然不是我要的结果。

1.1.3 如何处理粘包现象

（1）发送方

对于发送方造成的粘包现象，我们可以通过关闭Nagle算法来解决,我们可以使用TCP_NODELAY选项来关闭Nagle算法。

（2）接收方

遗憾的是TCP并没有处理接收方粘包现象的机制，我们只能在应用层进行处理。

（3）应用层处理

应用层的处理简单易行！并且不仅可以解决接收方造成的粘包问题，还能解决发送方造成的粘包问题。

解决方法就是循环处理：应用程序在处理从缓存读来的分组时，读完一条数据时，就应该循环读下一条数据，直到所有的数据都被处理；但是如何判断每条数据的长度呢？

两种途径：

1）格式化数据：每条数据有固定的格式（开始符、结束符），这种方法简单易行，但选择开始符和结束符的时候一定要注意每条数据的内部一定不能出现开始符或结束符。
2）发送长度：发送每条数据的时候，将数据的长度一并发送，比如可以选择每条数据的前4位是数据的长度，应用层处理时可以根据长度来判断每条数据的开始和结束。

好了，上面插了一个题外话，主要是怕不知道的小伙伴在去花费时间百度了，下面我们继续回到正题。

说这个的目的是为了告诉大家，纯裸 TCP 是不能直接拿来用的，你需要在这个基础上加入一些自定义的规则，用于区分消息边界。

于是我们会把每条要发送的数据都包装一下，比如加入消息头，消息头里写清楚一个完整的包长度是多少，根据这个长度可以继续接收数据，截取出来后它们就是我们真正要传输的消息体。

而这里头提到的消息头，还可以放各种东西，比如消息体是否被压缩过和消息体格式之类的，只要上下游都约定好了，互相都认就可以了，这就是所谓的协议。

每个使用 TCP 的项目都可能会定义一套类似这样的协议解析标准，他们可能有区别，但原理都类似。

于是基于 TCP，就衍生了非常多的协议，比如 HTTP 和 RPC。

2.HTTP 和 RPC

RPC 其实是一种调用方式

先看一下看网络的分层图：

TCP 是传输层的协议，而基于 TCP 造出来的 HTTP 和各类 RPC 协议，它们都只是定义了不同消息格式的应用层协议而已。

HTTP（HyperTextTransferProtocol）协议又叫做超文本传输协议。我们用的比较多，平时上网在浏览器上敲个网址就能访问网页，这里用到的就是 HTTP 协议。

而RPC（RemoteProcedureCall）又叫做远程过程调用，它本身并不是一个具体的协议，而是一种调用方式。

如果我们调用的不是个本地方法，而是个远端服务器暴露出来的一个方法remoteFunc，如果我们还能像调用本地方法那样去调用它，这样就可以屏蔽掉一些网络细节，用起来更方便，岂不美哉？

基于这个思路，大佬们造出了非常多款式的 RPC 协议，比如比较有名的gRPC，thrift。

值得注意的是，虽然大部分 RPC 协议底层使用 TCP，但实际上它们不一定非得使用 TCP，改用 UDP 或者 HTTP，其实也可以做到类似的功能。

到这里，我们回到文章标题的问题。

那既然有 RPC 了，为什么还要有 HTTP 呢？

其实，TCP 是70 年代出来的协议，而 HTTP 是90 年代才开始流行的。而直接使用裸 TCP 会有问题，可想而知，这中间这么多年有多少自定义的协议，而这里面就有80 年代出来的RPC。

所以我们该问的不是既然有 HTTP 协议为什么要有 RPC，而是为什么有 RPC 还要有 HTTP 协议?

现在电脑上装的各种联网软件，比如 xx 管家，xx 卫士，它们都作为客户端（Client） 需要跟服务端（Server） 建立连接收发消息，此时都会用到应用层协议，在这种 Client/Server (C/S) 架构下，它们可以使用自家造的 RPC 协议，因为它只管连自己公司的服务器就 ok 了。

但有个软件不同，浏览器（Browser） ，不管是 Chrome 还是 IE，它们不仅要能访问自家公司的服务器（Server），还需要访问其他公司的网站服务器，因此它们需要有个统一的标准，不然大家没法交流。于是，HTTP 就是那个时代用于统一Browser/Server (B/S)的协议。

也就是说在多年以前，HTTP 主要用于 B/S 架构，而 RPC 更多用于 C/S 架构。但现在其实已经没分那么清了，B/S 和 C/S 在慢慢融合。很多软件同时支持多端，比如百度云盘，既要支持网页版，还要支持手机端和 PC 端，如果通信协议都用 HTTP 的话，那服务器只用同一套就够了。而 RPC 就开始退居幕后，一般用于公司内部集群里，各个微服务之间的通讯。

那这么说的话，都用 HTTP 得了，还用什么 RPC？

3.HTTP 和 RPC 有什么区别

我们来看看 RPC 和 HTTP 区别比较明显的几个点。

3.1 服务发现

首先要向某个服务器发起请求，你得先建立连接，而建立连接的前提是，你得知道IP 地址和端口。这个找到服务对应的 IP 端口的过程，其实就是服务发现。

在HTTP中，你知道服务的域名，就可以通过DNS 服务去解析得到它背后的 IP 地址，默认80 端口。

而RPC的话，就有些区别，一般会有专门的中间服务去保存服务名和 IP 信息，比如Consul、Etcd、Nacos、ZooKeeper，甚至是 Redis。想要访问某个服务，就去这些中间服务去获得 IP 和端口信息。由于 DNS 也是服务发现的一种，所以也有基于 DNS 去做服务发现的组件，比如CoreDNS。

可以看出服务发现这一块，两者是有些区别，但不太能分高低。

3.2 底层连接形式

以主流的HTTP1.1协议为例，其默认在建立底层 TCP 连接之后会一直保持这个连接（keep alive），之后的请求和响应都会复用这条连接。

而RPC协议，也跟 HTTP 类似，也是通过建立 TCP 长链接进行数据交互，但不同的地方在于，RPC 协议一般还会再建个连接池，在请求量大的时候，建立多条连接放在池内，要发数据的时候就从池里取一条连接出来，用完放回去，下次再复用，可以说非常环保。

由于连接池有利于提升网络请求性能，所以不少编程语言的网络库里都会给 HTTP 加个连接池，比如 Go 就是这么干的。

可以看出这一块两者也没太大区别，所以也不是关键。

3.3 传输的内容

基于 TCP 传输的消息，说到底，无非都是消息头 Header 和消息体 Body。

Header是用于标记一些特殊信息，其中最重要的是消息体长度。

Body则是放我们真正需要传输的内容，而这些内容只能是二进制 01 串，毕竟计算机只认识这玩意。所以 TCP 传字符串和数字都问题不大，因为字符串可以转成编码再变成 01 串，而数字本身也能直接转为二进制。但结构体呢，我们得想个办法将它也转为二进制 01 串，这样的方案现在也有很多现成的，比如JSON，Protocol Buffers (Protobuf)。

这个将结构体转为二进制数组的过程就叫序列化，反过来将二进制数组复原成结构体的过程叫反序列化。

对于主流的 HTTP1.1，虽然它现在叫超文本协议，支持音频视频，但 HTTP 设计 初是用于做网页文本展示的，所以它传的内容以字符串为主。Header 和 Body 都是如此。在 Body 这块，它使用JSON来序列化结构体数据。

而 RPC，因为它定制化程度更高，可以采用积更小的 Protobuf 或其他序列化协议体去保存结构体数据，同时也不需要像 HTTP 那样考虑各种浏览器行为，比如 302 重定向跳转啥的。因此性能也会更好一些，这也是在公司内部微服务中抛弃 HTTP，选择使用 RPC 的最主要原因。
Http原理：

RPC原理：

当然上面说的 HTTP，其实特指的是现在主流使用的 HTTP1.1，HTTP2在前者的基础上做了很多改进，所以性能可能比很多 RPC 协议还要好，甚至连gRPC底层都直接用的HTTP2。

那么问题又来了。

为什么既然有了 HTTP2，还要有 RPC 协议？

这个是由于 HTTP2 是 2015 年出来的。那时候很多公司内部的 RPC 协议都已经跑了好些年了，基于历史原因，一般也没必要去换了。

上面说了那么多，给大家一个总结吧，在面试的时候也可按照总结的内容回答。

4.总结

• 纯裸 TCP 是能收发数据，但它是个无边界的数据流，上层需要定义消息格式用于定义消息边界。于是就有了各种协议，HTTP 和各类 RPC 协议就是在 TCP 之上定义的应用层协议。
• RPC 本质上不算是协议，而是一种调用方式，而像 gRPC 和 Thrift 这样的具体实现，才是协议，它们是实现了 RPC 调用的协议。目的是希望程序员能像调用本地方法那样去调用远端的服务方法。同时 RPC 有很多种实现方式，不一定非得基于 TCP 协议。
• RPC（Remote Procedure Call，远程过程调用）是一种进程间通信方式，也是一种技术思想
• 从发展历史来说，HTTP 主要用于 B/S 架构，而 RPC 更多用于 C/S 架构。但现在其实已经没分那么清了，B/S 和 C/S 在慢慢融合。很多软件同时支持多端，所以对外一般用 HTTP 协议，而内部集群的微服务之间则采用 RPC 协议进行通讯。
• RPC 其实比 HTTP 出现的要早，且比目前主流的 HTTP1.1 性能要更好，所以大部分公司内部都还在使用 RPC。
• HTTP2.0在HTTP1.1的基础上做了优化，性能可能比很多 RPC 协议都要好，但由于是这几年才出来的，所以也不太可能取代掉 RPC。