返回「计算机、信息技术与工程」
RPC方案
RPC方案 1. 通信协议: 使用基于 TCP/IP 的协议进行通信。ADB转发可以将设备上的特定端口映射到桌面端的端口，从而实现网络通信。 2. RPC机制: 可以使用如 gRPC, JSON RPC 等现成的RPC框架，或者自定义一个简单的基于JSON的协议。 3. 数据格式: 数据交换可以使用 JSON 或 Protobuf 等轻量级格式，这样可以简化跨语言通信的复杂性。
本文目录 9 个章节
RPC方案
- 通信协议: 使用基于 TCP/IP 的协议进行通信。ADB转发可以将设备上的特定端口映射到桌面端的端口，从而实现网络通信。
- RPC机制: 可以使用如 gRPC, JSON-RPC 等现成的RPC框架，或者自定义一个简单的基于JSON的协议。
- 数据格式: 数据交换可以使用 JSON 或 Protobuf 等轻量级格式，这样可以简化跨语言通信的复杂性。
RPC技术方案选型
1. gRPC
- 跨语言支持：gRPC 是一个高性能的 RPC 框架，由 Google 开发，支持多种语言，包括 Python 和 C#。
- 基于 HTTP/2：gRPC 基于 HTTP/2 协议，支持双向流、流控、头部压缩等。
- 使用 Protocol Buffers：默认使用 Protocol Buffers 作为接口定义语言和消息序列化格式，这提供了高效的数据传输。
- 适用场景：适合于高性能、跨语言、双向流通信的场景。
2. JSON-RPC
- 简单性：JSON-RPC 是一个基于 JSON 的轻量级 RPC 协议，易于理解和实现。
- 跨语言兼容性：几乎所有编程语言都支持 JSON，因此它适用于 Python 和 C#。
- 适用场景：适合于需要简单、无状态的单次请求-响应模式的场景。
3. XML-RPC
- 标准化：XML-RPC 是一种使用 XML 编码的远程过程调用协议。
- 跨语言支持：大多数现代编程语言都支持 XML，包括 Python 和 C#。
- 适用场景：适用于需要标准化、跨语言解决方案的场景，但性能上不如 JSON-RPC 或 gRPC。
4. 自定义简单的基于JSON的协议
RPC与HTTP协议
在 Web 开发中的 GET 和 POST 请求（属于 HTTP 协议）与 RPC（远程过程调用）之间存在显著区别。这些区别涵盖了它们的用途、设计哲学、以及如何在网络上传输数据。
GET 和 POST 请求（HTTP 协议）
- 用途:
- GET: 用于请求从服务器检索特定资源。GET 请求应该是幂等的，意味着多次执行相同的 GET 请求应返回相同的结果。
- POST: 用于向服务器提交数据，通常用于创建或更新资源。POST 请求不是幂等的，意味着多次执行相同的 POST 请求可能会有不同的效果。
- 数据传输:
- GET: 请求参数包含在 URL 中，存在长度限制。
- POST: 请求数据通常在请求体中发送，没有长度限制。
- 安全性:
- GET: 因为数据在 URL 中，所以不适合传输敏感数据。
- POST: 可以更安全地传输敏感数据，因为数据不会出现在 URL 中。
- 缓存和历史记录:
- GET: 请求可能被浏览器缓存，也会留在浏览器历史记录中。
- POST: 一般不会被缓存，也不会留在浏览器历史记录中。
RPC
- 用途:
- RPC 设计用于执行远程服务器上的过程或方法调用，就像调用本地方法一样。RPC 更注重于操作和方法调用。
- 数据传输:
- RPC 可以通过多种传输协议发送，如 HTTP、TCP、UDP 等。数据通常在请求体中传输，格式可以是 JSON、XML、二进制（如 Protocol Buffers）等。
- 接口定义:
- RPC 服务通常有明确的接口定义，说明了可调用的方法和它们的参数类型、返回类型等。
- 协议:
- RPC 可以使用各种协议实现，如 gRPC（基于 HTTP/2）、JSON-RPC、XML-RPC 等。这些协议定义了如何在客户端和服务器之间进行有效的远程方法调用。
区别总结
- 层级和抽象：GET/POST 请求是 HTTP 协议的一部分，关注于资源的传输和状态的变更。RPC 关注于远程执行函数或方法，提供了更高层次的抽象。
- 灵活性：RPC 提供更多的灵活性，可以选择不同的传输协议和数据格式，而 GET/POST 请求受限于 HTTP 协议的特定规则。
- 设计哲学：GET/POST 请求遵循 RESTful 设计原则，强调无状态和资源的表述。RPC 更侧重于行为和过程的调用。
Ref: ChatGPT