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支持, 连接流程如下:
- TCP的三次握手
- 客户端必须首先发送一个连接序言,其逻辑结构:
PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n // 纯字符串表示,翻译成字节数为24个字节
SETTINGS帧 // 其负载可能为空 - 发送完毕序言之后,客户端可以不用等待来自服务器端响应,马上发送HTTP/2其它帧
- 服务器端接收到客户端的连接序言之后,需要发送一个SETTINGS帧作为连接序言
- 任一端接收到SETTINGS帧之后,都需要返回一个包含确认标志位SETTIGN作为确认
- 其它帧的正常传输
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