接口测试-API测试中常用的协议（下）

一、RPC

RPC（Remote Procedure Call）即远程过程调用协议，它允许程序调用位于其他计算机上的程序中的过程或函数，就像调用本地程序中的过程一样。下面从其概念、工作原理、特点、应用场景等方面详细介绍：

概念起源与核心思想

• 起源：RPC 的概念最早出现在 20 世纪 70 年代，是为了解决分布式系统中不同计算机之间的通信和协作问题而提出的。随着计算机网络的发展和分布式系统的广泛应用，RPC 逐渐成为一种重要的技术手段。
• 核心思想：RPC 的核心思想是让调用远程函数的过程尽可能地像调用本地函数一样简单和透明。开发者无需关心函数调用的具体实现细节，包括网络传输、数据序列化、错误处理等，只需像调用本地函数一样传入参数并获取返回值即可。

工作原理

RPC 的工作过程通常可以分为以下几个步骤：

1. 客户端调用：客户端程序调用本地的一个 RPC 代理函数，这个函数看起来就像一个本地函数，但实际上它是用于发起远程调用的。客户端将调用的函数名、参数等信息传递给这个代理函数。
2. 请求序列化：RPC 代理函数将客户端传递的参数和调用信息进行序列化，即将这些数据转换为可以在网络上传输的格式，如二进制数据。常见的序列化方式有 JSON、XML、Protocol Buffers 等。
3. 网络传输：序列化后的请求数据通过网络传输到服务器端。这个过程涉及到网络协议的选择和使用，如 TCP、UDP 等。
4. 服务器接收与反序列化：服务器端接收到客户端发送的请求数据后，将其进行反序列化，还原出原始的函数名和参数信息。
5. 服务器处理：服务器端根据接收到的函数名和参数，调用相应的实际函数进行处理，并得到处理结果。
6. 结果序列化与返回：服务器将处理结果进行序列化，然后通过网络将其返回给客户端。
7. 客户端接收与反序列化：客户端接收到服务器返回的结果数据后，进行反序列化操作，得到最终的处理结果。

特点

• 透明性：RPC 对调用者和被调用者屏蔽了网络通信的细节，使得远程调用就像本地调用一样简单，提高了开发效率。
• 可扩展性：RPC 可以方便地扩展到不同的计算机和网络环境中，支持分布式系统的构建和扩展。
• 高效性：通过优化网络传输和数据序列化方式，RPC 可以实现高效的数据传输和处理，减少了远程调用的延迟。

应用场景

• 分布式系统：在分布式系统中，不同的服务可能运行在不同的服务器上，RPC 可以方便地实现这些服务之间的通信和协作。例如，一个电商系统中的订单服务、库存服务和支付服务可能分别运行在不同的服务器上，通过 RPC 可以实现它们之间的交互。
• 微服务架构：微服务架构将一个大型的应用拆分成多个小型的、自治的服务，RPC 是实现微服务之间通信的重要手段。不同的微服务可以使用不同的编程语言和技术栈，通过 RPC 可以实现它们之间的无缝集成。
• 云计算：在云计算环境中，用户可以通过 RPC 调用云服务提供商提供的各种服务，如存储服务、计算服务等。

常见的 RPC 框架

• gRPC：由 Google 开发并开源的高性能 RPC 框架，采用 HTTP/2 协议和 Protocol Buffers 序列化，具有高性能、多语言支持等特点。
• Thrift：由 Facebook 开发的跨语言的 RPC 框架，支持多种编程语言和数据传输协议，具有良好的可扩展性和性能。
• Dubbo：阿里巴巴开源的高性能 Java RPC 框架，专注于服务治理和分布式系统的开发，提供了丰富的服务注册、发现、监控等功能。

二、gPRC

gRPC 是由谷歌开发并开源的高性能、通用的远程过程调用（RPC, Remote Procedure Call）协议，它让客户端应用程序可以像调用本地对象的方法一样调用远程服务器的方法，为构建分布式系统提供了便利。下面从多方面详细介绍：

产生背景

在微服务架构兴起的背景下，不同服务之间需要高效通信。传统的通信方式，如 RESTful API ，在性能和效率上存在一定局限。谷歌基于自身在分布式系统通信方面的经验和需求，开发了 gRPC，以满足大规模、高性能服务间通信的要求，之后将其开源，供开发者广泛使用。

核心概念

• 服务定义：使用 Protocol Buffers（简称 Protobuf）语言来定义服务接口和消息类型。服务接口定义了客户端可以调用的方法，而消息类型则定义了这些方法的输入和输出参数。例如，定义一个简单的用户服务： 

// 定义消息类型
message UserRequest {
  string user_id = 1;
}

message UserResponse {
  string name = 1;
  int32 age = 2;
}

// 定义服务
service UserService {
  // 定义方法
  rpc GetUser (UserRequest) returns (UserResponse);
}

• 客户端和服务器：客户端应用程序根据服务定义生成客户端代码，调用远程服务器上的服务方法；服务器端应用程序根据服务定义实现具体的服务逻辑，并监听客户端的请求。

工作原理

1. 序列化：客户端调用本地生成的服务方法时，传入的参数会被序列化为 Protobuf 格式的二进制数据。Protobuf 是一种高效的序列化机制，能将结构化数据转换为紧凑的二进制表示，减少数据传输量。
2. 传输：序列化后的数据通过 HTTP/2 协议传输到服务器。HTTP/2 具有二进制分帧、多路复用、头部压缩等特性，提高了传输效率和性能。
3. 反序列化与处理：服务器接收到数据后，将其反序列化为原始的消息对象，然后调用对应的服务方法进行处理。处理完成后，将结果序列化为 Protobuf 格式并返回给客户端。
4. 客户端接收结果：客户端接收到服务器返回的结果后，进行反序列化操作，得到最终的响应数据。

特点

• 高性能：采用 HTTP/2 协议和 Protobuf 序列化，数据传输效率高，序列化和反序列化速度快，能显著减少延迟和提高吞吐量。
• 多语言支持：支持多种编程语言，如 Java、Python、Go、C++ 等，方便不同技术栈的团队进行开发和集成。
• 强类型接口：使用 Protobuf 定义服务接口和消息类型，具有严格的类型检查，能在编译阶段发现错误，提高代码的可靠性和可维护性。
• 流式传输：支持客户端和服务器之间的流式数据传输，适用于需要处理大量数据或实时数据的场景，如视频流、传感器数据等。

应用场景

• 微服务架构：在微服务系统中，不同服务之间需要频繁通信，gRPC 的高性能和多语言支持使其成为微服务间通信的理想选择。
• 移动应用与后端通信：移动应用与后端服务器之间的数据交互对性能和效率要求较高，gRPC 可以提供快速、可靠的通信方式。
• 大数据与实时数据处理：在大数据和实时数据处理场景中，需要处理大量的流式数据，gRPC 的流式传输功能能够满足这类场景的需求。

三、gRPC VS HTTP（RESTful API） 

gRPC 和 HTTP 协议都是在网络通信中常用的技术，二者既有相似之处，也存在诸多不同，以下从多方面为你详细对比：

相同点

• 底层依赖网络传输：gRPC 和 HTTP 协议都依赖底层的网络传输协议来实现数据的传输，通常基于 TCP 协议建立可靠的连接。这保证了数据在传输过程中的有序性和完整性，避免数据丢失或乱序。
• 用于网络通信：它们的核心目的都是实现不同节点之间的网络通信。无论是客户端与服务器之间，还是不同服务之间，都可以利用这两种协议进行数据交互，以完成特定的业务逻辑。
• 支持请求 - 响应模式：二者都支持基本的请求 - 响应通信模式。客户端向服务器发送请求，服务器接收请求后进行处理，并返回相应的结果给客户端。这种模式是网络通信中最常见的交互方式，方便实现各种业务功能。

不同点

协议层面

• HTTP 是通用协议，gRPC 基于 HTTP/2：HTTP 是一种通用的应用层协议，有多个版本（如 HTTP/1.0、HTTP/1.1、HTTP/2、HTTP/3），广泛应用于 Web 浏览、数据传输等各种场景。而 gRPC 是一种远程过程调用（RPC）协议，它基于 HTTP/2 构建，充分利用了 HTTP/2 的特性来实现高效的服务调用。
• 设计目标：HTTP 的设计目标是为了在 Web 上传输超文本（如 HTML 页面），强调通用性和广泛适用性，能够处理各种类型的请求和响应。gRPC 的设计目标则是为了实现高性能、高效的远程过程调用，专注于服务间的通信，更适合构建分布式系统和微服务架构。

数据格式与序列化

• HTTP 数据格式多样：HTTP 协议本身对数据格式没有严格限制，请求和响应可以使用多种数据格式，如 JSON、XML、HTML 等。这使得 HTTP 在处理不同类型的数据时具有很强的灵活性，但也可能导致数据传输效率较低，尤其是在处理大量数据时。
• gRPC 使用 Protobuf：gRPC 默认使用 Protocol Buffers（Protobuf）作为数据序列化工具。Protobuf 是一种高效的二进制序列化格式，它将数据结构定义在.proto 文件中，通过编译器生成相应的代码，实现数据的序列化和反序列化。Protobuf 具有数据体积小、序列化和反序列化速度快等优点，能够显著提高数据传输效率。

通信模式

• HTTP 通信模式有限：HTTP/1.1 主要采用请求 - 响应的单向通信模式，虽然 HTTP/2 引入了多路复用等特性，但在流式通信方面的支持相对有限。通常情况下，一个请求对应一个响应，难以实现实时的双向数据传输。
• gRPC 支持多种通信模式：gRPC 支持四种通信模式，包括一元 RPC（一个请求对应一个响应）、服务器流式 RPC（一个请求对应多个响应）、客户端流式 RPC（多个请求对应一个响应）和双向流式 RPC（多个请求对应多个响应）。这种丰富的通信模式使得 gRPC 在处理不同类型的业务场景时更加灵活，尤其适用于需要实时数据交互的场景，如实时监控、聊天应用等。（1对1 1对多 多对1 多对多）

性能

• HTTP 性能受版本影响：HTTP/1.1 存在头部冗余、队头阻塞等问题，导致性能相对较低，尤其是在高并发场景下。虽然 HTTP/2 通过二进制分帧、多路复用等技术解决了这些问题，提高了性能，但在某些特定场景下，如对延迟和吞吐量要求极高的场景，仍然存在一定的局限性。
• gRPC 性能优越：由于 gRPC 基于 HTTP/2，并结合了 Protobuf 的高效序列化，在性能方面表现出色。它能够有效减少数据传输量和延迟，提高吞吐量，适用于对性能要求苛刻的应用场景，如大规模分布式系统、实时数据处理等。

应用场景

• HTTP 应用广泛：HTTP 协议由于其通用性和广泛的支持，被广泛应用于 Web 开发、浏览器与服务器之间的通信、API 接口等领域。大多数的 Web 服务和网站都使用 HTTP 协议进行数据传输。
• gRPC 适用于特定场景：gRPC 更适用于构建分布式系统和微服务架构，尤其是对性能和效率要求较高的场景。例如，在微服务之间的通信、云服务的调用、物联网设备与服务器之间的通信等场景中，gRPC 能够发挥其优势，提供高效、可靠的通信服务。

接口定义

• gRPC：使用 Protocol Buffers 定义服务接口和消息类型，具有严格的类型系统。服务接口定义明确，包括方法名、输入参数和返回值类型，在编译阶段就能进行类型检查，有助于提高代码的可靠性和可维护性。例如：

service UserService {
  rpc GetUser (UserRequest) returns (UserResponse);
}

message UserRequest {
  string user_id = 1;
}

message UserResponse {
  string name = 1;
  int32 age = 2;
}

• RESTful API：主要基于资源和 URI 进行设计，通过 HTTP 方法（如 GET、POST、PUT、DELETE）对资源进行操作。接口定义相对灵活，但缺乏严格的类型约束，更多依赖文档来规范接口使用。例如，一个获取用户信息的 RESTful API 可能是 GET /users/{user_id}。

 

 四、CoAP协议

CoAP（Constrained Application Protocol）即受限应用协议，是一种专门为资源受限的设备和网络设计的应用层协议，在物联网领域有着广泛应用。下面从多个方面详细介绍 CoAP 协议：

产生背景

在物联网发展过程中，大量设备如传感器、执行器等具有资源受限的特点，包括计算能力有限、内存小、电池供电且网络带宽低等。传统的 HTTP 协议较为复杂，对设备资源要求较高，不适合这些受限设备。CoAP 协议应运而生，旨在为物联网设备提供一种轻量级、高效的通信解决方案。

工作原理

• 请求 - 响应模型：CoAP 采用与 HTTP 类似的请求 - 响应模型，客户端向服务器发送请求，服务器接收到请求后进行处理，并返回响应。请求和响应消息包含方法（如 GET、POST、PUT、DELETE）、URI（统一资源标识符）、可选的头部选项和消息体等信息。
• 消息传输：CoAP 基于 UDP（用户数据报协议）进行消息传输，UDP 是一种无连接的协议，开销小，适合资源受限的设备。为了保证消息的可靠性，CoAP 提供了确认机制。对于需要确认的消息，接收方会发送确认消息给发送方；如果发送方在一定时间内没有收到确认消息，会进行重传。

• TCP 面向连接（如打电话要先拨号建立连接）;UDP 是无连接的，即发送数据之前不需要建立连接

  TCP 提供可靠的服务。也就是说，通过 TCP 连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP 尽最大努力交付，即不保证可靠交付

  TCP 面向字节流，实际上是 TCP 把数据看成一连串无结构的字节流;UDP 是面向报文的 UDP 没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如 IP 电话，实时视频会议等）

  每一条 TCP 连接只能是点到点的;UDP 支持一对一，一对多，多对一和多对多的交互通信

  TCP 首部开销 20 字节;UDP 的首部开销小，只有 8 个字节

  TCP 的逻辑通信信道是全双工的可靠信道，UDP 则是不可靠信道

• 资源发现：CoAP 支持资源发现功能，设备可以通过发送特殊的请求来发现网络中的其他设备和资源。例如，客户端可以向服务器发送一个 GET 请求，请求获取服务器上所有可用资源的列表。

协议特点

• 轻量级：CoAP 协议的消息头部非常小，最小仅为 4 个字节，相比 HTTP 协议，大大减少了数据传输量，降低了对设备资源的消耗。
• 低功耗：由于基于 UDP 协议，避免了 TCP 协议建立连接时的三次握手和断开连接时的四次挥手过程，减少了通信开销，降低了设备的功耗，适合电池供电的物联网设备。
• 支持异步通信：CoAP 支持异步通信模式，客户端发送请求后可以继续执行其他任务，无需等待服务器的响应，提高了设备的处理效率。
• 与 HTTP 兼容：CoAP 协议在设计上考虑了与 HTTP 的兼容性，部分 HTTP 的概念和方法（如 GET、POST 等）在 CoAP 中也有对应，方便在物联网设备和传统 Web 服务之间进行集成。

应用场景

• 智能家居：在智能家居系统中，各种智能设备如智能灯泡、智能门锁、温湿度传感器等通常都是资源受限的设备。CoAP 协议可以实现这些设备之间以及设备与家庭网关之间的通信，实现远程控制和数据采集。
• 工业物联网：工业环境中的传感器和执行器等设备数量众多，且分布广泛。CoAP 协议的轻量级和低功耗特性使其非常适合在工业物联网中使用，实现设备之间的实时数据传输和控制。
• 智能农业：在智能农业领域，传感器用于监测土壤湿度、温度、光照等环境参数，执行器用于控制灌溉系统、通风设备等。CoAP 协议可以实现这些传感器和执行器之间的通信，帮助农民实现精准农业管理。

五、CoAP VS MQTT 

CoAP（Constrained Application Protocol）和 MQTT（Message Queuing Telemetry Transport）协议都是为物联网（IoT）环境设计的轻量级通信协议，但它们在设计理念、适用场景等方面存在一些区别，以下为你详细分析：

协议基础

• CoAP：基于 UDP（User Datagram Protocol）构建。UDP 是一种无连接的传输协议，开销小、速度快，但不保证数据的可靠传输。CoAP 为了弥补 UDP 的不足，在应用层实现了确认机制、重传机制等，以确保消息的可靠传输。
• MQTT：默认基于 TCP（Transmission Control Protocol）。TCP 是一种面向连接的传输协议，提供可靠的数据传输，能保证数据按序到达且不丢失。不过，建立和维护 TCP 连接会带来一定的开销。

通信模式

• CoAP：采用请求 - 响应（Request - Response）模式，类似于 HTTP 协议。客户端向服务器发送请求消息，服务器接收到请求后进行处理，并返回响应消息。这种模式适用于需要明确交互的场景，例如客户端查询传感器的当前数据。
• MQTT：基于发布 - 订阅（Publish - Subscribe）模式。设备（发布者）将消息发布到特定的主题（Topic），其他对该主题感兴趣的设备（订阅者）可以从代理（Broker）那里接收这些消息。这种模式实现了发布者和订阅者之间的解耦，适合大规模设备之间的消息传递和实时数据推送。

消息格式

• CoAP：消息格式较为简洁，头部最小仅为 4 字节，整体消息结构紧凑，适合资源受限的设备。它支持不同的消息类型（如确认消息、非确认消息等）和方法（如 GET、POST、PUT、DELETE），方便对资源进行操作。
• MQTT：消息格式也相对简单，由固定头部、可变头部和消息体组成。MQTT 消息的长度可以根据实际需求进行调整，以适应不同的数据量。它的消息类型包括连接、发布、订阅、取消订阅等，用于控制不同的通信操作。

适用场景

• CoAP：更适用于资源受限的设备与服务器之间的交互，尤其是需要对设备资源进行直接操作的场景，如读取传感器数据、控制执行器等。例如，在一个智能建筑系统中，传感器设备可以使用 CoAP 协议向服务器发送实时的温度、湿度等数据，服务器也可以通过 CoAP 协议对设备进行配置和控制。
• MQTT：适合大规模的物联网设备之间的通信，特别是需要实时数据推送和广播的场景。例如，在智能电网中，大量的电表设备可以通过 MQTT 协议将用电数据发布到代理服务器，电力公司的监控系统和其他相关设备可以订阅这些数据，实现实时监测和分析。

服务质量（QoS）

• CoAP：提供两种级别的可靠性：非确认消息（Non - confirmable）和确认消息（Confirmable）。非确认消息不要求接收方返回确认信息，适用于对可靠性要求不高的场景；确认消息要求接收方返回确认信息，如果发送方在一定时间内没有收到确认消息，会进行重传。
• MQTT：提供三种服务质量级别：QoS 0（最多一次）、QoS 1（至少一次）和 QoS 2（恰好一次）。QoS 0 表示消息可能会丢失，不保证送达；QoS 1 表示消息至少会被送达一次，但可能会有重复；QoS 2 表示消息恰好会被送达一次，提供最高级别的可靠性，但通信开销也相对较大。

安全性

• CoAP：支持 DTLS（Datagram Transport Layer Security）协议，它是基于 UDP 的 TLS（Transport Layer Security）协议，为 CoAP 通信提供加密和认证功能，保证数据的机密性和完整性。
• MQTT：支持 TLS 协议，通过对 TCP 连接进行加密，确保消息在传输过程中的安全性。此外，MQTT 还可以通过用户名和密码、客户端证书等方式进行身份认证。