gRPC 是 Google 基于 HTTP/2 以及 protobuf 的嗦董，要了解 gRPC 協(xié)議吏砂，只需要知道 gRPC 是如何在 HTTP/2 上面?zhèn)鬏斁涂梢粤?/p>
gRPC 通常有四種模式，unary镣典，client streaming镊叁，server streaming 以及 bidirectional streaming，對于底層 HTTP/2 來說团秽，它們都是 stream主胧，并且仍然是一套 request + response 模型
Request
gRPC 的 request 通常包含 Request-Headers, 0 或者多個(gè) Length-Prefixed-Message 以及 EOS
Request-Headers 直接使用的 HTTP/2 headers，在 HEADERS 和 CONTINUATION frame 里面派發(fā)习勤。定義的 header 主要有 Call-Definition 以及 Custom-Metadata踪栋。Call-Definition 里面包括 Method（其實(shí)就是用的 HTTP/2 的 POST），Content-Type 等图毕。而 Custom-Metadata 則是應(yīng)用層自定義的任意 key-value夷都，key 不建議使用 grpc- 開頭，因?yàn)檫@是為 gRPC 后續(xù)自己保留的
Length-Prefixed-Message 主要在 DATA frame 里面派發(fā)予颤，它有一個(gè) Compressed flag 用來表示該 message 是否壓縮囤官，如果為 1冬阳，表示該 message 采用了壓縮，而壓縮算法定義在 header 里面的 Message-Encoding 里面党饮。然后后面跟著四字節(jié)的 message length 以及實(shí)際的 message
EOS（end-of-stream） 會在最后的 DATA frame 里面帶上了 END_STREAM 這個(gè) flag肝陪。用來表示 stream 不會在發(fā)送任何數(shù)據(jù)，可以關(guān)閉了
Response
Response 主要包含 Response-Headers劫谅，0 或者多個(gè) Length-Prefixed-Message 以及 Trailers见坑。如果遇到了錯(cuò)誤嚷掠，也可以直接返回 Trailers-Only捏检。
- Response-Headers
- HTTP-Status // 通常的 HTTP 200，301不皆，400
- Content-Type
- Custom-Metadata
- Trailers-Only
- HTTP-Status
- Content-Type
- Trailers
- Trailers
- Status // gRPC 的 status
- 0 或者多個(gè) Custom-Metadata
如果在最后收到的 HEADERS frame 里面贯城，帶上了 Trailers，并且有 END_STREAM 這個(gè) flag霹娄，那么就意味著 response 的 EOS
Protobuf
gRPC 的 service 接口是基于 protobuf 定義的能犯，我們可以非常方便的將 service 與 HTTP/2 關(guān)聯(lián)起來
- Path :
/Service-Name/{method name} - Service-Name :
?( {proto package name} "." ) {service name} - Message-Type :
{fully qualified proto message name} - Content-Type :
"application/grpc+proto"
