文章总结： reqable3.3版本延期发布，新增grpc测试功能，支持四种rpc模式、proto文件解析与json转换，无需依赖protoc，提供环境变量和文件引用，功能免费。
综合评分： 72
文章分类： 产品介绍,安全工具
Reqable 3.3版本新功能预览：gRPC支持
原创
MegatronKing
MegatronKing
Reqable
2026年9月21日 12:05
上海
在小说阅读器读本章
去阅读
在公众号小说中沉浸阅读
大家好，由于受到多个客观的主观的因素影响，3.3版本正式发布延期了，先真诚给大家道个歉。
目前3.3版本已经开发完成，这个版本更新内容和重构代码较多，客户端和服务端要同步更新，加上临近中秋国庆长假，无法及时响应大家反馈的建议和缺陷，因此决定延期到节后发布。
在正式发布之前，给大家先介绍下新版本即将推出的gRPC测试功能。
- 什么是gRPC
gRPC（Google Remote Procedure Call）是由 Google 开源的高性能、跨语言的远程过程调用框架。gPRC使用protobuf编码数据，比使用JSON数据量更低解析性能更高。protobuf编码依赖proto定义文件，因此gRPC相比常规的HTTP请求，无论是发送数据还是读取数据，都需要依赖proto定义文件。
下图是抓包到的一个gPRC请求，可以看到数据是使用了二进制编码，在没有proto定义文件的情况下，这个二进制数据是无法正常解析的。
如果拥有proto定义文件，则可以转成JSON格式显示，还可以直接对数据进行编辑和测试。对于gPRC接口，proto定义文件是其中不可或缺的一部分。
除了数据使用protobuf编码外，相比HTTP请求，gPRC还支持下面4种模式。
- 一元 RPC：普通的一问一答，类似HTTP会话。
- 服务端流：客户端发一个请求，服务端返回一串数据。
- 客户端流：客户端发一串数据，服务端返回一个响应。
- 双向流：双方都可以持续发送数据流，类似WebSocket会话。
Reqable将完整支持以上这四种模式，下面我们具体来看看。
- 创建gRPC测试请求
无论是抓包还是发送请求，gRPC接口都需要先定义proto。也就是说Reqable需要知道proto文件的具体内容。点击 + 号 -> 新建规范文件 -> protobuf，可以在Reqable中新建一个proto文件，编辑proto内容，然后保存即可。
如果启用了云端数据模式，proto文件会保存到云端并自动同步到其他设备，如果使用的离线数据模式，proto文件会保存到本地的Reqable数据缓存目录。
定义好proto文件后，就可以创建gRPC测试请求了，点击 + 号，新建gRPC。
小技巧：如果你仅仅有HTTP的需求，嫌点击 + 号展开菜单浪费操作的话，可以在设置中启用快速创建HTTP选项，可以直接创建HTTP请求。
回归正题，我们继续介绍gRPC功能。新建好gPRC请求测试标签后，选择proto定义文件。
如果不想将proto文件保存到Reqable中也没关系，Reqable还支持直接直接使用本地的proto文件和服务器反射。
很多公开的gPRC接口，不对外直接提供proto定义文件，而是提供服务反射，调用者可以直接从接口服务器拉取proto定义内容。
以我们演示的grpc.postman-echo.com接口为例，服务器就提供了proto的反射定义。
接下来需要选择调用哪个服务的哪个方法了，点击URL输入框后面的 选择方法 展开列表菜单。
gPRC发送和接收的数据都是按照proto定义编码的二进制数据，对于我们测试和阅读非常不方便。没关系，在Reqable中将使用JSON格式进行转换，编辑JSON -> 自动转成proto二进制 -> 发送，收到proto二进制 -> 自动转成JSON -> 显示。
在发送数据时，不知道JSON如何定义的怎么办？点击 生成示例 图标即可自动生成一个数据模板。
- 四种请求模式
下面介绍下gRPC的4种请求模式，一元 RPC、服务端流、客户端流、双向流。服务方法前面的图标可以区分这几种模式。
首先是一元RPC，这个和HTTP请求会话类似，都是一问一答，发送请求然后接收响应。
元数据和HTTP请求的头部类似，请求元数据就是请求头，响应元数据就是响应头，只是叫法不同。
还有一个特殊的是响应尾部（Trailer），服务端在每个RPC调用结束后会发给客户端，包含RPC的响应状态，也常常用来发送RPC的性能数据，例如耗时等等。格式和元数据（请求响应头）一样，都是key-value的格式。
在这个请求测试界面，会忽略显示部分gRPC内置固定的元数据和响应尾（例如gRPC响应状态），让大家更好地关注于业务数据。在抓包页面，则可以查看到全部的元数据（请求响应头）和响应尾。
第二种模式服务端流，客户端发一个请求，服务端返回一串数据。Reqable会默认使用列表模式显示全部的发送和响应数据。
和SSE以及WebSocket数据视图类似，列表每项都是单行显示，也可以切换到对话模式，显示完整的JSON消息。
第三种模式客户端流，客户端发一串数据，服务端返回一个响应。和前面两种直接调用的RPC接口不同，在发送数据后，需要手动触发结束流，告知服务器客户端数据已经全部发送完毕，服务器才会发送响应。
最后一种模式双向流，和WebSocket类似，客户端和服务端可以持续地发送数据，没什么好特别介绍的。
- 环境变量和文件
gRPC的请求地址和消息内容均可以引用环境变量，和其他的请求一样，使用双尖括号引用。
Reqable使用JSON格式编辑数据，如果发送的数据中包含二进制数据（例如上传图片），要如何处理呢？
proto定义的二进制数据，和JSON转换的的时候，会使用base64编码。可以将图片内容转成base64后然后添加到JSON中。当然，有点麻烦是不是？
在Reqable中可以直接在JSON中引用文件路径，发送的时候会自动进行base64编码，例如下图。
- 一些技术细节
gRPC实现中最难的部分是proto文件的解析和JSON格式转换，有些抓包竞品例如Charles，需要用户额外安装protoc，然后运行命令去解析proto文件，生成描述文件后再导入。这虽然是一个被验证可行的方案，但是很明显对用户体验并不好。
Reqable也不像Postman之类那样有成熟的protobuf JavaScript扩展库可以直接使用，我们也只能自行摸索适合的方案。
研究之后，最终方案采取了移植protobuf源码，添加了C/C++接口提供给上层使用，不依赖protoc即可在运行时处理proto文件。
目前基本上实现了我对gPRC支持的预期设想，新版本gRPC的功能全部免费，相信这个版本的更新也能让大家满意。
感谢阅读，下篇文章见！也提前祝大家双节快乐！
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：Reqable MegatronKing
MegatronKing《Reqable 3.3版本新功能预览：gRPC支持》