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