Go语言中文网，致力于每日分享编码知识，欢迎关注我，会有意想不到的收获！

gRPC 在 Go 语言中大放异彩，越来越多的小伙伴在使用，最近也在公司安利了一波，希望这一篇文章能带你一览 gRPC 的巧妙之处，本文篇幅比较长，请做好阅读准备。本文目录如下：

简述

gRPC 是一个高性能、开源和通用的 RPC 框架，面向移动和 HTTP/2 设计。目前提供 C、Java 和 Go 语言版本，分别是：grpc, grpc-java, grpc-go. 其中 C 版本支持 C, C++, Node.js, Python, Ruby, Objective-C, PHP 和 C# 支持。

gRPC 基于 HTTP/2 标准设计，带来诸如双向流、流控、头部压缩、单 TCP 连接上的多复用请求等特性。这些特性使得其在移动设备上表现更好，更省电和节省空间占用。

调用模型

1、客户端(gRPC Stub)调用 A 方法，发起 RPC 调用。

2、对请求信息使用 Protobuf 进行对象序列化压缩(IDL)。

3、服务端(gRPC Server)接收到请求后，解码请求体，进行业务逻辑处理并返回。

4、对响应结果使用 Protobuf 进行对象序列化压缩(IDL)。

5、客户端接受到服务端响应，解码请求体。回调被调用的 A 方法，唤醒正在等待响应(阻塞)的客户端调用并返回响应结果。

调用方式

一、Unary RPC：一元 RPC

Server

• 创建 gRPC Server 对象，你可以理解为它是 Server 端的抽象对象。
• 将 SearchService(其包含需要被调用的服务端接口)注册到 gRPC Server。 的内部注册中心。这样可以在接受到请求时，通过内部的 “服务发现”，发现该服务端接口并转接进行逻辑处理。
• 创建 Listen，监听 TCP 端口。
• gRPC Server 开始 lis.Accept，直到 Stop 或 GracefulStop。

Client

• 创建与给定目标(服务端)的连接句柄。
• 创建 SearchService 的客户端对象。
• 发送 RPC 请求，等待同步响应，得到回调后返回响应结果。

二、Server-side streaming RPC：服务端流式 RPC

Server

Client

三、Client-side streaming RPC：客户端流式 RPC

Server

Client

四、Bidirectional streaming RPC：双向流式 RPC

Server

Client

客户端与服务端是如何交互的

在开始分析之前，我们要先 gRPC 的调用有一个初始印象。那么最简单的就是对 Client 端调用 Server 端进行抓包去剖析，看看整个过程中它都做了些什么事。如下图：

• Magic
• SETTINGS
• HEADERS
• DATA
• SETTINGS
• WINDOW_UPDATE
• PING
• HEADERS
• DATA
• HEADERS
• WINDOW_UPDATE
• PING

我们略加整理发现共有十二个行为，是比较重要的。在开始分析之前，建议你自己先想一下，它们的作用都是什么？大胆猜测一下，带着疑问去学习效果更佳。

行为分析

Magic

Magic 帧的主要作用是建立 HTTP/2 请求的前言。在 HTTP/2 中，要求两端都要发送一个连接前言，作为对所使用协议的最终确认，并确定 HTTP/2 连接的初始设置，客户端和服务端各自发送不同的连接前言。

而上图中的 Magic 帧是客户端的前言之一，内容为 PRI * HTTP/2.0SM，以确定启用 HTTP/2 连接。

SETTINGS

SETTINGS 帧的主要作用是设置这一个连接的参数，作用域是整个连接而并非单一的流。

而上图的 SETTINGS 帧都是空 SETTINGS 帧，图一是客户端连接的前言(Magic 和 SETTINGS 帧分别组成连接前言)。图二是服务端的。另外我们从图中可以看到多个 SETTINGS 帧，这是为什么呢？是因为发送完连接前言后，客户端和服务端还需要有一步互动确认的动作。对应的就是带有 ACK 标识 SETTINGS 帧。

HEADERS

HEADERS 帧的主要作用是存储和传播 HTTP 的标头信息。我们关注到 HEADERS 里有一些眼熟的信息，分别如下：

• method：POST
• scheme：http
• path：/proto.SearchService/Search
• authority：:10001
• content-type：application/grpc
• user-agent：grpc-go/1.20.0-dev

你会发现这些东西非常眼熟，其实都是 gRPC 的基础属性，实际上远远不止这些，只是设置了多少展示多少。例如像平时常见的 grpc-timeout、grpc-encoding 也是在这里设置的。

DATA

DATA 帧的主要作用是装填主体信息，是数据帧。而在上图中，可以很明显看到我们的请求参数 gRPC 存储在里面。只需要了解到这一点就可以了。

HEADERS, DATA, HEADERS

在上图中 HEADERS 帧比较简单，就是告诉我们 HTTP 响应状态和响应的内容格式。

在上图中 DATA 帧主要承载了响应结果的数据集，图中的 gRPC Server 就是我们 RPC 方法的响应结果。

在上图中 HEADERS 帧主要承载了 gRPC 状态 和 gRPC 状态消息，图中的 grpc-status 和 grpc-message 就是我们的 gRPC 调用状态的结果。

其它步骤

WINDOW_UPDATE

主要作用是管理和流的窗口控制。通常情况下打开一个连接后，服务器和客户端会立即交换 SETTINGS 帧来确定流控制窗口的大小。默认情况下，该大小设置为约 65 KB，但可通过发出一个 WINDOW_UPDATE 帧为流控制设置不同的大小。

PING/PONG

主要作用是判断当前连接是否仍然可用，也常用于计算往返时间。其实也就是 PING/PONG，大家对此应该很熟。

小结

• 在建立连接之前，客户端/服务端都会发送连接前言(Magic+SETTINGS)，确立协议和配置项。
• 在传输数据时，是会涉及滑动窗口(WINDOW_UPDATE)等流控策略的。
• 传播 gRPC 附加信息时，是基于 HEADERS 帧进行传播和设置；而具体的请求/响应数据是存储的 DATA 帧中的。
• 请求/响应结果会分为 HTTP 和 gRPC 状态响应两种类型。
• 客户端发起 PING，服务端就会回应 PONG，反之亦可。

这块 gRPC 的基础使用，接下来会发布《gRPC 入门系列》，关注我第一时间获得。

本文作者：煎鱼，原创授权发布