首页  思维导图  详情

gRPC

2023-06-08 08:40:09   14  举报





AI智能生成

gRPC

分布式

grpc

rpc

protobu

HTTP2

作者其他创作

大纲/内容

什么是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 连接上的多复用请求等特。这些特性使得其在移动设备上表现更好，更省电和节省空间占用

官方文档

为什么要使用gRPC

生态好（依靠云原生）：背靠Google。还有比如nginx也对grpc提供了支持

跨语言：跨语言，且自动生成sdk

性能高：比如protobuf性能高过json, 比如http2.0性能高过http1.1

强类型：编译器就给你解决了很大一部分问题

流式处理（基于http2.0）：支持客户端流式，服务端流式，双向流式

gRPC的传输介质-ProtoBuf

Protobuf是由Google开发的二进制格式，用于在不同服务之间序列化数据。是一种IDL（interface description language）语言

具统计比json快6倍

ProtoBuf的数据格式（为什么ProtoBuf比 json效率高？）

体积小-无需分隔符：TLV存储方式不需要分隔符（逗号，双引号等）就能分隔字段，减少了分隔符的使用
体积小-空字段省略：若字段没有被设置字段值，那么该字段序列化时的数据是完全不存在的，即不需要进行编码，而json会传key和空值的value
体积小-tag二进制表示：是用字段的数字值然后转换成二进制进行表示的，比json的key用字符串表示更加省空间
编解码快：tag的里面存储了字段的类型，可以直接知道value的长度，或者当value是字符串的时候，则用length存储了长度，可以直接从length后取n个字节就是value的值，而如果不知道value的长度，我们就必须要做字符串匹配

gRPC基于 Http2.0（Http2.0优势）

二进制分帧（frame）

在二进制分帧层上，HTTP 2.0 会将所有传输的信息分割为更小的消息和帧，并对它们采用二进制格式的编码，其中HTTP1.x的首部信息会被封装到Headers 帧，而我们的request body则封装到Data帧里面。帧是数据传输的最小单位，以二进制传输代替原本的明文传输

HTTP 2.0 所有的通信都在一个连接（TCP连接）上完成，这个连接可以承载任意数量的双向数据流。相应地，每个数据流以消息的形式发送，而消息由一或多个帧组成，这些帧可以乱序发送，然后再根据每个帧首部的流标识符重新组装。

HTTP/2 的四个概念

Connection ：1 个 TCP 连接，包含 1 个或者多个 stream。所有通信都在一个 TCP 连接上完成，此连接可以承载任意数量的双向数据流。
Stream：一个双向通信的数据流，包含 1 条或者多条 Message。每个数据流都有一个唯一的标识符和可选的优先级信息，用于承载双向消息。流是连接中的一个虚拟信道，可以承载双向消息传输。每个流有唯一整数标识符。为了防止两端流ID冲突，客户端发起的流具有奇数ID，服务器端发起的流具有偶数ID。
Message：消息是指逻辑上的HTTP消息（请求/响应）。一系列数据帧组成了一个完整的消息。比如一系列DATA帧和一个HEADERS帧组成了请求消息。
Frame：最小通信单位，以二进制压缩格式存放内容。来自不同数据流的帧可以交错发送，然后再根据每个帧头的数据流标识符重新组装。

在一个TCP连接中可以同时存在多个Stream，可以并发执行。但是一个Stream内部的多个Fream不能乱序。
流有顺序，帧没有

Frame结构

Frame 由 Frame Header 和 Frame Payload 两部分组成

Length： 帧有效负载的长度（数据的长度，不包含头部），注意：帧头的 9 个八位字节不包含在此长度值中。

Type： 这 8 位用来表示帧类型的。帧类型确定帧的格式和语义。实现方必须忽略并丢弃任何类型未知的帧。

Flags：标志位，常用的标志位有 END_HEADERS 表示头数据结束，相当于 HTTP/1 里头后的空行（“\r\n”）。

R：保留的 1 位。该位的语义未定义，发送时必须保持未设置 (0x0)，接收时必须忽略

Stream Identifier： 流标识符，表示为无符号 31 位整数。由客户端发起的流必须使用`奇数`编号的流标识符；那些由服务器发起的必须使用`偶数`编号的流标识符。DATA 帧必须与某一个流相互关联。

stream ID 的作用

实现多路复用的关键。接收端的实现可以根据这个 ID 并发、组装消息。同一个 stream 内 frame 必须是有序的。

推送依赖性请求的关键。客户端发起的流是奇数编号，服务端发起的流是偶数编号

头部压缩（HPACK）

为什么要压缩？

在 HTTP/1 中，HTTP 请求和响应都是由「状态行、请求 / 响应头部、消息主体」三部分组成。一般而言，消息主体都会经过 gzip 压缩，或者本身传输的就是压缩过后的二进制文件（例如图片、音频），但状态行和头部却没有经过任何压缩，直接以纯文本传输
根据 HTTP Archive 的统计，当前平均每个页面都会产生上百个请求。越来越多的请求导致消耗在头部的流量越来越多，尤其是每次都要传输 UserAgent、 Cookie 这类不会频繁变动的内容，完全是一种浪费

一个页面的抓包结果。可以看到，传输头部的网络开销超过 100kb，比 HTML 还多

HTTP/2协议中定义了 HPACK，这是一种新的压缩方法，它消除了多余的 header 字段，将漏洞限制到已知的安全攻击，并且在受限的环境中具有有限的内存需求。HPACK 格式特意被设计成简单且不灵活的形式：两种特性都降低了由于实现错误而引起的互操作性或安全性问题的风险；没有定义扩展机制，只能通过定义完整的替换来更改格式

如何进行头部压缩？

维护一份相同的静态表（Static Table），包含常见的头部名称，以及常见的头部名称与值的组合（静态表内容共61项，索引号1-61）；

维护一份相同的动态表（Dynamic Table），当一个header name 或者 header value在静态表中不存在，会被插入动态表中，可以动态地添加内容（动态表索引从62开始）；

客户端和服务端会共同维护一份动态表
第一次发送的时候需要明文发送(要经过Huffman编码)，第二次及第N次发送索引号

对不存在的头部使用哈夫曼编码（Huffman Coding），并动态缓存到索引（动态表）

静态表

一个预定义且不可更改的 header 字段列表。先定义好的内容，只有固定的几十个值，如果要发送的值符合静态表时，用对应的 Index 替换即可，这样就大大压缩了头部的大小，如果遇到不在静态表中的值，就会用到动态表

动态索引 & 动态表

动态表是一个由先进先出的队列维护的有空间限制的表，同样维护的是头部与对应的索引。
每个动态表只针对一个连接（TCP），每个连接的压缩解压缩的上下文有且仅有一个动态表。
那么动态表就是，当一个头部没有出现过的时候，会把他插入动态表中，索引从62开始

多路复用（Multiplexing）

http1.1中，浏览器客户端在同一时间，针对同一域名下的请求有一定数量的限制，超过限制数目的请求会被阻塞。这也是为何一些站点会有多个静态资源 CDN 域名的原因之一。

浏览器使用并行连接，但它们会将向同一个域名请求的并行连接的总数限制为一个较小的值。浏览器同域名请求的最大并发数限制

http 2.0 连接都是持久化的，而且客户端与服务器之间也只需要一个连接（每个域名一个连接）即可。http2连接可以承载数十或数百个流的复用，多路复用意味着来自很多流的数据包能够混合在一起通过同样连接传输。当到达终点时，再根据不同帧首部的流标识符重新连接将不同的数据流进行组装

单个 HTTP/2 连接可以包含多个并发打开的 stream 流，任一一个端点都可能交叉收到来自多个 stream 流的帧。
stream 流可以单方面建立和使用，也可以由客户端或服务器共享。
任何一个端都可以关闭 stream 流。
在 stream 流上发送帧的顺序非常重要。收件人按照收到的顺序处理帧。特别是，HEADERS 和 DATA 帧的顺序在语义上是重要的。
stream 流由整数标识。stream 流标识符是由发起流的端点分配给 stream 流的。

服务器推送（Server Push）

服务器可以对一个客户端请求发送多个响应，服务器向客户端推送资源无需客户端明确地请求。并且，服务端推送能把客户端所需要的资源伴随着 index.html一起发送到客户端，省去了客户端重复请求的步骤

当服务端需要主动推送某个资源时，便会发送一个 Frame Type 为 PUSH_PROMISE 的 Frame，里面带了 PUSH 需要新建的 Stream ID。意思是告诉客户端：接下来我要用这个 ID 向你发送东西，客户端准备好接着。客户端解析 Frame 时，发现它是一个 PUSH_PROMISE 类型，便会准备接收服务端要推送的流

http2.0性能瓶颈

启用http2.0后会给性能带来很大的提升，但同时也会带来新的性能瓶颈。因为现在所有的压力集中在底层一个TCP连接之上，TCP很可能就是下一个性能瓶颈，比如单个TCP packet丢失导致整个连接阻塞，无法逃避，此时所有消息都会受到影响

QUIC协议代替TCP协议中关于可靠、流量控制的部分