有了HTTP协议为什么还需要RPC协议？

当我们需要实现进程间通信时，即在两个不同的四元组之间进行通信时，通常会使用socket编程来实现，选择TCP或UDP作为传输协议。在实际应用中，为了确保数据稳定性，常常选择使用TCP。

然而，TCP是面向字节流的，这就导致了粘包问题的出现。粘包指的是：

为了解决这个问题，我们需要在代码中加入自定义规则，例如添加消息头来区分消息边界，可能还需要包装每条数据，包括消息头和消息体。这样的规定和约定构成了所谓的协议 ，每个使用TCP的项目可能都会定义自己的协议，尽管细节可能有所不同，但原理大致相同。基于TCP的这种通信方式演变出了许多协议，其中就包括HTTP协议和RPC协议。

RPC（Remote Procedure Call）并不是一种具体的协议，而是一种调用方式，旨在使远程方法的调用方式与本地方法一致，屏蔽掉一些网络细节。为了实现这一目标，许多RPC协议应运而生，如gRPC、Thrift等。这些RPC协议大多数底层基于TCP，但也可以使用UDP、HTTP等其他协议。

RPC协议的出现早于HTTP，因此问题应该是：“既然有了RPC，为什么还需要HTTP？”RPC更适用于客户端-服务器（cs）架构，其中客户端只需与公司内部的服务端建立连接进行消息收发。相比之下，HTTP更适用于浏览器-服务器（bs）架构，因为它需要与公司内部服务器以及其他公司的服务器进行通信。尽管当前bs和cs架构逐渐融合，支持多平台访问，但RPC仍然在公司内部微服务之间的通信中发挥着作用，而HTTP则更多用于跨公司间的通信。

有些区别包括服务发现，HTTP通过DNS服务实现，而RPC则通过专门的中间服务如consul和etcd。底层连接方面，HTTP1.1建立连接后会一直保持，而RPC协议通常使用连接池，通过复用连接提高性能。此外，传输内容也有差异，HTTP通常使用JSON，而RPC更倾向于使用诸如protobuf的格式。 gRPC底层直接使用HTTP2，其性能甚至可能超过许多RPC协议。

在整理这些差异时，需要考虑网络性能、底层连接管理、数据传输格式等因素。这种细致入微的比较有助于理解为什么在不同情境下选择不同的通信方式。