что это такое и как это понять

RPC (удаленный вызов процедур) дословно переводится как удаленный вызов процедур.

HTTP (HyperText Transfer Protorl) дословный перевод - протокол передачи гипертекста.

И RPC, и HTTP являются протоколами запрос-ответ, но они имеют разные названия из-за разного времени, концепций дизайна, согласованных протоколов, эффективности, области применения и правил использования. По сути, они созданы для связи между распределенными системами. протокол связи (запрос-ответ) (с точки зрения сетевой модели OSI).

RPC — это термин, придуманный Брюсом Джеем Нельсоном в 1981 году, а HTTP был создан примерно в 1990 году (см. Википедию).

Протокол RPC и RPC, как они называются? Протокол RPC = RPC

Протокол HTTP, HTTP, как он называется? HTTP-протокол = HTTP

RPC｜HTTP — это просто аббревиатура всех

Протокол HTTP 不仅仅只有协议, а также гипертекст, передача и многие функции (такие как кодек, роль различных параметров, которые часто запоминаются в интервью)
Протокол RPC также 不仅仅只有协议имеет кодеки, обнаружение регистрации службы, балансировку нагрузки и т. д.

Протокол RPC по существу определяет процесс связи, и конкретная технология реализации не ограничена.Каждая структура RPC имеет свой собственный метод реализации 我认为HTTP也是RPC的一种实现方式.

Грубо говоря, протокол — это своего рода соглашение: и rpc, и http созданы для связи между серверами, и обоим нужно сформулировать набор стандартных протоколов для связи. Тем не менее, HTTP относительно популярен, это единое соглашение во всем мире, и оно широко используется. Но обобщение также означает избыточность, поэтому многие фреймворки RPC были созданы позже (нестандартные протоколы, отличная производительность и т. д.).

我们可以自定义RPC请求/响应包含的消息头和消息体结构，自定义编解码方式，自定义网络通信方式，只要client和server消息的发送和解析能对应即可，这些问题确认下来，一个RPC框架就设计出来了。

Давайте сначала посмотрим на этапы, которые RPC и HTTP будут проходить от процесса запроса, а затем сравним их по этапам.

один процесс запроса

этап	стадийная стратификация	RPC	HTTP
клиент: бизнес-логика xx	слой бизнес-логики	немного	немного
клиент: клиент создает запрос и инициирует вызов	кодек	бережливость｜json｜protobuf и т. д.	json｜картинка и т.д.
клиент: Построить поток данных в соответствии с транспортным протоколом	уровень протокола	thrift｜gRPC｜Kitex｜dubbo等	HTTP1 ｜HTTP1.1｜HTTP2｜QUIC等
client: 服务发现	服务发现	自定义内部服务发现组件	DNS
client: 网络通信：传输数据流	网络通信层	接口层：netty｜netpool，根据OS的API做了一些封装本质：TCP｜UDP｜HTTP系列	接口层：HTTP内部自己实现，目前不清楚咋做的本质：TCP｜UDP
server: 把数据流解析为协议结构	协议层	略，同上	略，同上
server: 解析协议中的请求体	编解码	略，同上	略，同上
server: 执行业务逻辑xx	业务逻辑层	略，同上	略，同上

从请求链路可以看到，最核心的只有三层：编解码、协议、网络通信

下面会从这3个角度去对比HTTP和RPC

HTTP VS RPC自定义协议

HTTP和RPC 2个关键词不具备可比较性，因为RPC包含了HTTP。

但是RPC自定义协议(thrift, protobuf, dubbo, kitex-thrift等) 是RPC的具体实现，HTTP也是RPC的具体实现，它们是具备可比较性的

编解码(序列化)

序列化：指将程序运行过程中的动态内存数据（java的class、go的struct）转化为硬盘中静态二进制数据的过程，以方便网络传输。
反序列化：指将硬盘中静态二进制数据转化为程序运行过程中的动态内存数据的过程，以方便程序计算。

HTTP/1.1 一般用json

自定义RPC协议一般用 thrift、protobuf

kitex序列化协议

维度	json(HTTP/1.1)	protobuf(gRPC)
优点	1. 可读性好、使用简单，学习成本低	1. 序列化后的体积比json小 => 传输效率高 2. 序列化/反序列化速度快 => 性能损耗小
缺点	1. JSON 进行序列化的额外空间开销比较大 2. JSON 没有类型，比如无法区分整数和浮点像 Java 、Go这种强类型语言，不是很友好，解析速度比较慢(需要通过反射解决)	1. 不可读，都是二进制
适用场景	适用于服务提供者与服务调用者之间传输的数据量要相对较小的情况，否则会严重影响性能	追求高性能的场景

协议层

编码之后，数据转换成字节流，但是RPC通信时，每次请求发送的数据大小不是固定的，那么为了区分消息的边界，避免粘包、半包等现象，我们需要定义一种协议，来使得接收方能够正确地读出不定长的内容。简单点说，通信协议就是约定客户端和服务器端传输什么数据，以及如何解析数据。

维度	HTTP/1.1	kitex-TTHeader
优点	1. 灵活，可以自定义很多字段 2. 几乎所有设备都可以支持HTTP协议	1. 灵活，通用，可以自定义自定义必要字段即可 => 减小报文体积，提高传输效率 2. 性能优秀
缺点	1. 包含许多为了适应浏览器的冗余字段，这些是内部服务用不到的，性能差	1. 部分设备存在不能支持，通用性欠佳

可参考

kitex：概览，传输协议
dubbo：triple 协议，概览

可以思考一下序列化、传输协议、网络通信的关系，下面以kitex为例进行分析

kitex codec 接口定义，kitex thrift 序列化实现，kitex ttheader协议，kitex 发送请求核心代码

可以发现 Encode中，先根据message构造出header，写入out，然后再把data(实际的业务数据)写到out。

encode函数完全遵守 ttheader协议去构造数据。

最后再把out通过网络库发送出去

网络通信层

网络通信层主要提供一个易用的网络库，封装了操作系统提供的socket api。

维度	HTTP/1.1	kitex框架
实现方式	一般采用短连接需要3次握手(可以配置长链接添加请求头Keep-Alive: timeout=20)- 长连接，指在一个连接上可以连续发送多个数据包，在连接保持期间，如果没有数据包发送，需要双方发链路检测包	rpc框架维护一个tcp连接池，每次用完不断开连接，通过心跳检测断开连接（探测服务是否有问题）- 支持短连接、长连接池、连接多路复用以及连接池状态监控。
优点	1. 几乎所有设备都可以支持HTTP协议	1. 不用每次请求都经历三次握手&四次挥手，减少延时
缺点	1. 每次请求都要新建连接，性能差	1. 部分设备存在不能支持，通用性欠佳

HTTP的长连接和TCP长连接不是一个东西，需要注意下，TCP Keepalive是操作系统实现的功能，并不是TCP协议的一部分，需要在操作系统下进行相关配置(只能保证网络没问题，不能代表服务没问题)

其中 HTTP2 拥有多路复用、优先级控制、头部压缩等优势

可以参考

kitex：连接类型

RPC自定义协议和 HTTP的使用场景

公司内部的微服务，对客户端提供的服务适合用RPC，更好的性能

对外服务、单体服务、为前端提供的服务适合用HTTP

我的思考

rpc在编解码、协议层、网络通信都比HTTP有更大的优势，那为啥不把HTTP换成RPC呢

我认为最核心的是人的认知，HTTP已经深入人心，并且所有的机器和语言默认都会支持。但是自定义RPC协议可能很多人都没听过(比如kitex、dubbo等)，还让别人支持，根本不可能。
- 需要建设全局的DNS等等，HTTP链路中的组件都需要换成自定义的那一套，成本极高。
- 但是公司内部可以搞成一套，可以极大提高性能，何乐而不为。
RPC框架可以自定义负载均衡，重试机制，高可用，流量控制等策略。这些是HTTP不能支持的