gRPC

gRPC的特征：

• 基於 HTTP/2， 繼而 提供了連接多路復用、Body 和 Header 壓縮等機制。可以節省帶寬、降低TCP鏈接次數、節省CPU使用和延長電池壽命等。
• 支持主流開發語言（C, C++, Python, PHP, Ruby, NodeJS, C#, Objective-C、Golang、Java）
• IDL (Interface Definition Language) 層使用了 Protocol Buffers, 非常適合團隊的接口設計

gRPC 協議 http://dongliu.net/post/622451

gRPC 的協議設計上使用了HTTP2 現有的語義，請求和響應的數據使用HTTP Body 發送，其他的控制信息則用Header 表示。

 

Protobuf 相關資料：

Protobuf簡單使用及其抓包分析
http://blog.csdn.net/wangqiuyun/article/details/42119835

 

Android gRPC protobuf的compile&generate問題
Android上使用gRPC時，proto的compile和generate不能用java的方法，要用javanano的
http://pokerg.github.io/gRPC/Android-gRPC-protobuf%E7%9A%84compile%26generate%E9%97%AE%E9%A2%98/ 

 

Protobuf 筆記1
http://www.cnblogs.com/ghj1976/p/4565846.html

 

HTTP2 的網絡請求

HTTP2網絡請求分析請參考：

http://www.cnblogs.com/ghj1976/category/697891.html 

 

HTTP/2協議在TCP連接之初進行協商通信，只有協商成功，才會涉及到后續的請求-響應等具體的業務型數據交換。

客戶端預先知道服務器提供HTTP/2支持， 則可以采用下面方式跟服務器建立連接。

 

HTTP/2的直接連接

客戶端預先知道服務器提供HTTP/2支持， 連接流程如下：

1. TCP的三次握手
2. 客戶端必須首先發送一個連接序言，其邏輯結構：
   PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n  // 純字符串表示，翻譯成字節數為24個字節
   SETTINGS幀                                // 其負載可能為空
3. 發送完畢序言之后，客戶端可以不用等待來自服務器端響應，馬上發送HTTP/2其它幀
4. 服務器端接收到客戶端的連接序言之后，需要發送一個SETTINGS幀作為連接序言
5. 任一端接收到SETTINGS幀之后，都需要返回一個包含確認標志位SETTIGN作為確認
6. 其它幀的正常傳輸

 

 

GRPC的請求包

 

 

• Http 請求的Path 部分用來表示調用哪個服務，格式是/{package}.{ServiceName}/{RpcMethodName}，
• content-type 目前取值都是application/grpc+proto，將來gRPC 支持除Protobuf 之外的協議如Json 時，會有別的值。
• grpc-encoding 可以有gzip, deflate, snappy 等取值，表示采用的壓縮方法。
• grpc-timeout 表示調用的超時時間，單位有Hour(H), Minute(M), Second(S), Millisecond(m), Microsecond(u), Nanosecond(n) 等。

 

 

參考資料:

https://github.com/grpc/grpc-common/blob/master/PROTOCOL-HTTP2.md

http://dongliu.net/post/622451