HTTP(S)与RPC之争（rpc与http区别）

off999 2025-03-14 19:46 20 浏览 0 评论

自从2011年阿里巴巴开源Dubbo后，互联网上就开始了HTTP(S)与RPC的对比与争论，各说各的好，有的企业只用Dubbo（RPC），有的企业只用HTTP(S)，有的两者都用。如今已经是2025年了，网上随便一搜，依然有一系列的文章在对比HTTP(S)与RPC，甚至有不少在对比Dubbo协议与HTTP协议（这里不是错别字，真的有不少文章写的是Dubbo协议，而不是框架/组件/系统等名词）！

争论点

基于OSI模型，有不少观点认为RPC比HTTP(S)更底层，RPC是第5层（基于定制的TPC协议实现，报文更小），HTTP(S)是第7层（最上层），因此RPC性能更好。
RPC默认使用长连接，并且是消息机制（异步），相对HTTP(S)的会话机制（同步），因此RPC更容易支持高并发，性能更好。
RPC自带软负载均衡，注册直连机制，而HTTP(S)需额外搭建负载均衡（Nginx、硬负载均衡等），因此RPC的稳定性与服务治理方面更优。
RPC主要是为了解决内网服务调用的问题，相对HTTP(S)来说，设计较为简单，因此HTTP(S)的安全性、通用性（跨平台/语言）更好。
PRC不是明文传输，而HTTP是明文传输（这里也不是错别字，真的有不少文章就这么写的），因此HTTP更容易调试。

分析

以下分别是HTTP(S)报文格式与RPC报文格式：

HTTP(S)

// 请求
{方法}GET/POST /{地址}(?{GET参数}) {协议版本}HTTP1.1/2.0
{头信息（键值对形式），数据类型、浏览器、主机、Cookie等信息}
{POST数据}

// 响应
{协议版本}HTTP1.1/2.0 {状态码}200/404
{头信息（键值对形式），数据类型、时间戳、Cookie等信息}
{响应数据}

{头信息，主机、类型标识（请求/响应）、序列化类型、协议版本、ID等信息}
{方法名、返回类型、参数等信息}

争论点1

OSI模型里，第6层叫表示层，主要是为了处理系统之间的数据加解密、编码、序列化等，确保双方能够读懂交换的信息。其中，HTTP(S)协议里包含相关信息并实现了相关功能，RPC默认需要系统双方保持同样的约定。例如：乱码问题，无论是HTTP(S)还是RPC，相信有不少人都遇到过。

当系统双方使用共同的约定时（大部分企业的服务器都会统一设置，统一环境），HTTP(S)的执行链路与RPC的区别就很小了，这时HTTP(S)只多了一点判断指令。这时，HTTP(S)就变得低一层了吗？
当RPC需要支持跨平台功能时，代码中自定义实现了表示层的功能，并且协议中也增加了相关信息。这时，RPC就变得高一层了吗？

OSI模型里，第5层叫会话层（Session），主要是为了让服务端和客户端之间的多次请求响应匹配上，维持状态。其中，HTTP(S)基于Cookie实现，RPC需在代码中基于自定义ID机制实现。

当HTTP(S)不设置Cookie时（无状态模式，当前绝大多数企业都是使用的无状态HTTP(S)），代码中也不做会话保持逻辑，HTTP(S)就变得低一层了吗？例如：心跳检测、查询搜索等。
当RPC基于自定义ID机制实现了会话保持逻辑，RPC就变得高一层了吗？

再比较一下报文内容。其中HTTP(S)头信息由于是键值对形式，因此使用默认值的信息都可以不传。例如：无状态调用都不设置Cookie，因此头信息里可以不存在Cookie字符。

主机是HTTP(S)和RPC都存在的，由于RPC的直接调用模式，大概率是IP地址，而HTTP(S)则大概率是域名。这就变成IP长还是域名长的问题，大多数情况下，域名相对更长，但是可以配置短域名，比IP更短。
HTTP(S)的数据类型，相较于RPC的序列化类型，一般HTTP(S)的长10个字符以内。
HTTP(S)的状态码，相较于RPC的自定义，由于RPC需要统一序列化，因此RPC的会更长。例如：按json格式，{status:200}，则RPC长9个字符。
HTTP(S)的方法是特有的（常用为3到4个字符，最长为7个字符），RPC特有的是类型标识（一般是一个字符）。大多数情况下，HTTP(S)长2到3个字符，完整的Restful模式下，HTTP(S)长2到6个字符。
HTTP(S)的地址对应RPC的方法名。由于HTTP(S)的头信息有最大长度限制，一般情况下HTTP(S)的地址不会太长，常见为10个字符以内。而RPC需把完整的方法名进行编码，按JAVA的格式包括包名路径、类名、方法名，常见为几十个字符（面向对象的编码规范中，一般类名和方法名都需要有具体含义，并且JAVA的包名一般包含公司名、项目名、框架内的分类名等）。
HTTP(S)响应的时间戳是特有的，比RPC长13位。

总结一下，

OSI的第5、6、7层在实际中其实可以归纳为同一层，HTTP(S)和RPC都可以自定义是否需要这三层中的几层，而不是必须都要。因此，从网络模型来说，HTTP(S)和RPC都在这个大层，唯一区别就是：HTTP(S)默认已经支持这三层，使用时自行设置即可，而RPC需要额外的代码来支持。
同样的业务，同样的接口定义，同样的编码、序列化等设置下，如果RPC可以随意设置方法名，保持不比HTTP(S)的长，则HTTP(S)会比RPC长约20个字符。但是，由于JAVA和面向对象规范的叠加，RPC在报文长度上反而更容易比HTTP(S)长几十个字符。
假设RPC在理想的情况下，比HTTP(S)短20个字符，性能差距也不一定大。例如：心跳检测类简单请求，整个报文可能就百来个字符，那么性能差距可能能到20%。但是正常的业务请求中，报文长度是几百几千个字符，报文越长，性能差距就越小，甚至小于2%，小于1%，在一些大数据量的查询接口下，可能差距只有万分之一。因此，不谈具体业务、具体接口的情况下谈协议性能，就是耍流氓！

争论点2

关于长连接，HTTP(S)的负载均衡通常也是长连接的连接池模式。在这一点上HTTP(S)与RPC并无明显的区别。

异步与同步，到底谁更容易支持高并发，性能更好，这个取决于相互依赖的系统双方各自的性能，没有唯一答案。例如：

低性能系统调用高性能系统接口的情况下，由于瓶颈点在调用方，调用方需要一定资源来维护被阻塞的并发调用。因此，异步机制比同步机制需要的资源更小，更容易支持高并发。
高性能系统调用低性能系统接口的情况下，由于瓶颈点在被调用方，异步模式下调用方和被调用方都需要资源维护被阻塞的调用，而同步模式下只需要调用方维护。因此，同步机制比异步机制需要的资源更小，更容易支持高并发。
系统双方性能一致的情况下，异步模式和同步模式需要的资源都差不多，支持高并发的能力都一样。

争论点3

这个争论点本质上是一个网络链路的差异，HTTP(S)的独立负载均衡模式，在网络链路上比RPC的注册直连模式多一个节点。因此，因为看起来HTTP(S)的物理链路耗时更长，所以RPC的性能就更好？？。并且，由于RPC的注册直连模式有一个专门的管理中心，可以动态的调度集群，而HTTP(S)的独立负责均衡模式下，貌似无法动态的调度集群？？因此，RPC在服务治理方面更优？？

集群调度方面，负责均衡本身就有调度的功能，心跳检测、失败重试等机制都是现成的，唯一的差别就是RPC的注册直连模式多了一个专门的调度中心。

如果说独立的好，那么HTTP(S)才是更好的，因为负载均衡和调度都是独立的，而RPC的注册直连模式，只有调度是独立的，负载均衡部分是和业务系统耦合在一起的。
如果说调度中心的动态发现机制好，那么，从已有节点来看，两者没区别，都有心跳检测，动态调度。从新增节点来看，RPC的注册中心是自动化添加新节点，而HTTP(S)的独立负载均衡需要额外的组件来支持自动化添加。这就是一个自动化部署的问题。

网络链路的差异方面，不同的系统规模，不同的系统依赖情况下，结论会不一样。以下分两种情况：

系统规模较小、系统依赖链路简单、不存在高性能系统依赖低性能系统的情况下，RPC的注册直连模式性能相对更好。在这些情况下，可能存在的瓶颈都在调用方，因此调用方无需维护多个下游信息就能完成业务处理，此时RPC注册直连模式中与业务耦合的软负载组件消耗资源较小，不会对性能产生明显的影响，网络链路更短意味着性能更优（延迟和并发性能都是RPC的注册直连模式更优）。
系统规模较大、系统依赖链路复杂、存在高性能系统依赖低性能系统的情况下，由于下游性能低，调用方存在一些被阻塞的调用以及增加的下游节点，此时RPC注册直连模式中与业务耦合的软负载组件消耗资源变大，依赖的低性能系统越多，性能差异越大，资源消耗越大，直到达到整体的平衡。与业务耦合的软负载组件消耗的资源将会直接影响业务系统的性能，此时网络链路短所提升的性能将被抵消，并产生反效果，降低整体性能。而HTTP(S)的独立负载均衡模式在这种情况下，并不会对业务系统产生影响，性能依然稳定。此时，HTTP(S)的独立负载均衡模式性能更优（单一的延迟依然是RPC的注册直连模式更优，但是并发性能是HTTP(S)的独立负载均衡模式更优）。

注：与业务相耦合的软负载均衡组件，在某些特定情况下，会引发连锁反应，导致业务系统崩溃。出事故后，负责业务系统的团队仍需担责，即便根本原因与业务系统的代码无关。

争论点4

通用性上，相较于RPC的对象序列化模式需包含代码信息，HTTP(S)无需任何代码信息，HTTP(S)更通用。

安全性上，HTTP(S)默认支持证书模式，而RPC需额外代码实现。

争论点5

调试的支持方面，HTTP(S)是默认支持明文打印的，头信息就包括很多可用信息，而RPC的部分关键信息在数据包中，需要额外代码支持打印（现在的框架一般都支持）。因此调试都方便，只是方式不太一样，习惯后没什么区别。

结论

在系统规模小、依赖关系简单，系统环境单一，开发语言单一，并且不存在高性能系统依赖低性能系统的情况下，在内网环境使用RPC相对更优，性能更好，延迟更低，支持高并发所需资源相对更少。
HTTP(S)作为全球通用且使用规模最广的协议之一，无论是内网还是外网都可以使用，并且默认支持跨平台、跨语言，多种数据类型、文件传输，支持的范围比RPC更广，更通用。高并发和性能方面和RPC没有明显差距，某些情况下比RPC更优，上述第1点的情况下略逊于RPC。
在对延迟敏感，并且需要2位数以内的毫秒级延迟的情况下，RPC相对更优。但是代价是可能需要更大的集群来弥补RPC的缺点，并且需要额外的人力投入对RPC进行扩展用于支持更多的业务情况。