gRPC是基于HTTP/2协议的,要想了解gRPC,就需要理解HTTP/2协议
HTTP/1.x 的问题
- Parser 1.x是基于文本协议的,对机器并不友好,所以读取HTTP header 会耗费性能
- Request/Response 1.x 一问一答的固定交互模式,必须等待连接返回,因此网络连接效率不高
- push 推送一般用Long polling或者websocket
HTTP/2
Stream: 一个双向流,一条连接可以有多个 streams。
Message: 也就是逻辑上面的 request,response。
Frame::数据传输的最小单位。每个 Frame 都属于一个特定的 stream 或者整个连接。一个 message 可能有多个 frame 组成。
- Frame Format Frame的结构定义如下
|
|
Length:也就是 Frame 的长度,默认最大长度是 16KB,如果要发送更大的 Frame,需要显式的设置 max frame size。
Type:Frame 的类型,譬如有 DATA,HEADERS,PRIORITY 等。
Flag 和 R:保留位,可以先不管。
Stream Identifier:标识所属的 stream,如果为 0,则表示这个 frame 属于整条连接。
Frame Payload:根据不同 Type 有不同的格式。
- Multiplexing
一条连接可以包含多个 streams,多个 streams 发送的数据互相不影响。
Stream 可以被 client 和 server 单方面或者共享使用。
Stream 可以被任意一段关闭。
Stream 会确定好发送 frame 的顺序,另一端会按照接受到的顺序来处理。
Stream 用一个唯一 ID 来标识。
如果需要加大一条连接上的并发可以调大 SETTINGS_MAX_CONCURRENT_STREAMS
Priority
stream 有优先级,方便对端为不同的请求分配不同的资源Flow Control
Flow control 是单向的。Receiver 可以选择给 stream 或者整个连接设置 window size。
Flow control 是基于信任的。Receiver 只是会给 sender 建议它的初始连接和 stream 的 flow control window size。
Flow control 不可能被禁止掉。当 HTTP/2 连接建立起来之后,client 和 server 会交换 SETTINGS frames,用来设置 flow control window size。
Flow control 是 hop-by-hop,并不是 end-to-end 的,也就是我们可以用一个中间人来进行 flow control。HPACK
为了减少header头数据传输大小
GRPC
gRPC 通常有四种模式,unary,client streaming,server streaming 以及 bidirectional streaming,对于底层 HTTP/2 来说,它们都是 stream,并且仍然是一套 request + response 模型。
- Request
- Response
- Protobuf