RPC

Remote Procedure Call，远程过程调用。简单来说就是两个进程之间的数据交互。正常服务端的接口服务是提供给用户端(在Web开发中就是浏览器)或者自身调用的，也就是本地过程调用。和本地过程调用相对的就是：假如两个服务端不在一个进程内怎么进行数据交互？使用RPC。尤其是现在微服务的大量实践，服务与服务之间的调用不可避免，RPC更显得尤为重要。

rpc.jpg

上图描述了一个RPC的完整调用流程：

1：client向client stub发起方法调用请求。

2：client stub接收到请求后，将方法名，请求参数等信息进行编码序列化。

3：client stub通过配置的ip和端口使用socket通过网络向远程服务器server发起请求。

4：远程服务器server接收到请求，解码反序列化请求信息。

5：server将请求信息交给server stub，server stub找到对应的本地真实方法实现。

6：本地方法处理调用请求并将返回的数据交给server stub。

7：server stub 将数据编码序列化交给操作系统内核，使用socket将数据返回。

8：client端socket接收到远程服务器的返回信息。

9：client stub将信息进行解码反序列化。

10：client收到远程服务器返回的信息。

注：stub负责接收本地方法调用，并将它们委托给各自的具体实现对象。server端stub又被称为skeleton(骨架)。可以理解为代理类。而实际上基于Java的RPC框架stub基本上也都是使用动态代理。我们所说的client端和server端在RPC中一般也都是相对的概念。

GRPC

gRPC是Google的开源产品，是跨语言的通用型RPC框架，基于HTTP2协议，使用Go语言编写。 Java语言的应用同样使用了Netty做网络通信，Go采用了Goroutine做网络通信。序列化方式采用了Google自己开源的Protobuf。请求的调用和返回使用HTTP2的Stream。

GRPC原理

一个RPC框架必须有两个基础的组成部分：数据的序列化和进程数据通信的交互方式。

****Protobuf：Google Protocol Buffer(简称 Protobuf)是一种轻便高效的结构化数据存储格式，平台无关、语言无关、可扩展，可用于通讯协议和数据存储等领域。

上句有几个关键点：它是一种数据存储格式，跨语言，跨平台，用于通讯协议和数据存储。

这么看和我们熟悉的JSON类似，但其实着重点有些本质的区别。JSON主要是用于数据的传输，因为它轻量级，可读性好，解析简单。Protobuf主要是用于跨语言的IDL，它除了和JSON、XML一样能定义结构体之外，还可以使用自描述格式定于出接口的特性，并可以使用针对不同语言的protocol编译器产生不同语言的stub类。所以天然的适用于跨语言的RPC框架中。

而关于进程间的通讯，无疑是Socket。Java方面gRPC同样使用了成熟的开源框架Netty。使用Netty Channel作为数据通道。传输协议使用了HTTP2。

通过以上的分析，我们可以将一个完整的gRPC流程总结为以下几步：

• 通过.proto文件定义传输的接口和消息体。
• 通过protocol编译器生成server端和client端的stub程序。
• 将请求封装成HTTP2的Stream。
• 通过Channel作为数据通信通道使用Socket进行数据传输。

HTTP2

HTTP2 通过支持标头字段压缩和在同一连接上 进行多个并发交换，让应用更有效地利用网络资源，减少 感知的延迟时间。具体来说，它可以对同一连接上的请求和响应消息进行交错 发送并为 HTTP 标头字段使用 有效编码。 HTTP/2 还允许为请求设置优先级，让更重要的请求更快速地完成，从而进一步 提升性能。

HTTP2协议更有利于网络，因为与 HTTP/1.x 相比，可以使用更少的 TCP 连接。 这意味着与其他流的竞争减小，并且连接的持续时间变长，这些特性反过来提高 了可用网络容量的利用率。 最后，HTTP2 还可以通过使用二进制消息分帧对消息进行更高效的处理。

二进制分帧层

HTTP/2 所有性能增强的核心在于新的二进制分帧层，它定义了如何封装 HTTP 消息并在客户端与服务器之间传输。

二进制帧.png

这里所谓的“层”，指的是位于套接字接口与应用可见的高级 HTTP API 之间一个经过优化的新编码机制：HTTP 的语义（包括各种动词、方法、标头）都不受影响，不同的是传输期间对它们的编码方式变了。 HTTP/1.x 协议以换行符作为纯文本的分隔符，而 HTTP2 将所有传输的信息分割为更小的消息和帧，并采用二进制格式对它们编码。

这样一来，客户端和服务器为了相互理解，都必须使用新的二进制编码机制：HTTP/1.x 客户端无法理解只支持 HTTP2 的服务器，反之亦然。 不过不要紧，现有的应用不必担心这些变化，因为客户端和服务器会替我们完成必要的分帧工作。

数据流、消息和帧

新的二进制分帧机制改变了客户端与服务器之间交换数据的方式。 为了说明这个过程，我们需要了解 HTTP2 的三个概念：

• 数据流：已建立的连接内的双向字节流，可以承载一条或多条消息。
• 消息：与逻辑请求或响应消息对应的完整的一系列帧。
• 帧：HTTP2 通信的最小单位，每个帧都包含帧头，至少也会标识出当前帧所属的数据流。

这些概念的关系总结如下：

• 所有通信都在一个 TCP 连接上完成，此连接可以承载任意数量的双向数据流。
• 每个数据流都有一个唯一的标识符和可选的优先级信息，用于承载双向消息。
• 每条消息都是一条逻辑 HTTP 消息（例如请求或响应），包含一个或多个帧。
• 帧是最小的通信单位，承载着特定类型的数据，例如 HTTP 标头、消息负载等等。 来自不同数据流的帧可以交错发送，然后再根据每个帧头的数据流标识符重新组装。

Free-Converter.com-streams_messages_frames01-78815424.png

简言之，HTTP2 将 HTTP 协议通信分解为二进制编码帧的交换，这些帧对应着特定数据流中的消息。所有这些都在一个 TCP 连接内复用。 这是 HTTP2 协议所有其他功能和性能优化的基础。