从实践到原理 带你参透 gRPC（一）
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 端进行抓包去剖析，看看整个过程中它都做了些什么事。如下图：
MagicSETTINGSHEADERSDATASETTINGSWINDOW_UPDATEPINGHEADERSDATAHEADERSWINDOW_UPDATEPING我们略加整理发现共有十二个行为，是比较重要的。在开始分析之前，建议你自己先想一下，它们的作用都是什么？大胆猜测一下，带着疑问去学习效果更佳。
行为分析
Magic
Magic 帧的主要作用是建立 HTTP/2 请求的前言。在 HTTP/2 中，要求两端都要传送一个连线前言，作为对所使用协议的最终确认，并确定 HTTP/2 连线的初始设定，客户端和服务端各自发送不同的连线前言。
而上图中的 Magic 帧是客户端的前言之一，内容为 PRI * HTTP/2.0 SM ，以确定启用 HTTP/2 连线。
SETTINGS
SETTINGS 帧的主要作用是设定这一个连线的引数，作用域是整个连线而并非单一的流。
而上图的 SETTINGS 帧都是空 SETTINGS 帧，图一是客户端连线的前言（Magic 和 SETTINGS 帧分别组成连线前言）。图二是服务端的。另外我们从图中可以看到多个 SETTINGS 帧，这是为什么呢？是因为传送完连线前言后，客户端和服务端还需要有一步互动确认的动作。对应的就是带有 ACK 标识 SETTINGS 帧。
HEADERS
HEADERS 帧的主要作用是储存和传播 HTTP 的标头资讯。我们关注到 HEADERS 里有一些眼熟的资讯，分别如下：
method：POSTscheme：httppath：/proto.SearchService/Searchauthority：:10001content-type：application/grpcuser-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 入门系列》，关注我第一时间获得。
本文作者：煎鱼，原创授权释出
