3. gRPC 通信模式：一元RPC、服务端流式RPC、客户端流式RPC、双向流式RPC的适用场景与对比

gRPC 基于 HTTP/2 协议，定义了四种通信模式（Communication Pattern）。理解这四种模式的区别与适用场景，是进行 gRPC 审计基线设计的基础。不同的模式决定了数据流的走向、并发模型以及安全审计的侧重点。

3.1 四种通信模式概述

gRPC 的通信模式由 .proto 文件中 service 定义的关键字决定。下表从数据流方向、典型应用、审计关注点三个维度进行对比：

3.2 四种模式的核心区别与适用场景

3.2.1 一元 RPC（Unary RPC）

最基础的通信模式，与传统的 HTTP REST 调用类似。客户端发送一个请求，服务端返回一个响应。适用于大多数同步、低延迟的查询操作。

• 优点： 实现简单，易于调试，与 HTTP/1.1 语义最接近。
• 缺点： 无法处理服务端主动推送或客户端批量发送的场景。
• 审计基线要求： 必须校验请求和响应的 Content-Type 是否为 application/grpc，以及 grpc-status 是否为 0。

3.2.2 服务端流式 RPC（Server Streaming RPC）

客户端发送一个请求，服务端返回一个消息流。服务端可以持续发送消息，直到发送完毕。适用于需要从服务端持续获取数据的场景。

• 优点： 减少客户端轮询开销，实现实时推送。
• 缺点： 客户端需要处理流中断和部分消息丢失的情况。
• 审计基线要求： 审计日志中必须记录流开始时间、结束时间、发送消息总数，并检查是否存在异常中断（如 UNAVAILABLE 状态码）。

3.2.3 客户端流式 RPC（Client Streaming RPC）

客户端发送一个消息流，服务端在接收完所有消息后返回一个响应。适用于客户端需要批量提交数据的场景。

• 优点： 支持大文件分片上传，降低单次请求负载。
• 缺点： 服务端必须等待所有消息接收完毕才能处理，延迟较高。
• 审计基线要求： 必须对每个分片消息进行完整性校验（如 CRC32 或 MD5），并记录分片序号，防止重放攻击。

3.2.4 双向流式 RPC（Bidirectional Streaming RPC）

客户端和服务端可以独立地发送和接收消息流，实现全双工通信。适用于需要实时交互的场景。

• 优点： 延迟最低，交互最灵活。
• 缺点： 实现复杂度最高，需要处理并发读写和消息顺序。
• 审计基线要求： 必须启用 双向 TLS（mTLS），并在审计日志中记录每个消息的 message_id 和 timestamp，以支持会话重建。

3.3 四种模式的数据流对比图

下图直观展示了四种通信模式中客户端与服务端之间的数据流方向与交互时序：

3.4 审计基线中的模式选择建议

在制定 gRPC 审计基线时，应根据业务场景选择合适的通信模式，并针对性地配置安全策略：

1. 高安全性场景（如金融交易、用户认证）： 优先使用 一元 RPC，配合 mTLS 和请求签名，审计日志最简洁。
2. 实时监控场景（如系统指标、日志采集）： 使用 服务端流式 RPC，审计基线需关注流中断告警和消息序列号校验。
3. 批量数据上传场景（如文件上传、传感器数据）： 使用 客户端流式 RPC，审计基线必须包含分片校验和超时重试机制。
4. 低延迟交互场景（如聊天、协同编辑）： 使用 双向流式 RPC，审计基线需启用会话级审计，并限制最大并发流数。

3.5 代码示例：四种模式的 .proto 定义

以下代码展示了如何在 .proto 文件中定义四种通信模式：

syntax = "proto3";

package audit.example;

// 一元 RPC
service UnaryService {
  rpc GetUser (UserRequest) returns (UserResponse);
}

// 服务端流式 RPC
service ServerStreamService {
  rpc SubscribeEvents (EventRequest) returns (stream EventResponse);
}

// 客户端流式 RPC
service ClientStreamService {
  rpc UploadLogs (stream LogEntry) returns (UploadStatus);
}

// 双向流式 RPC
service BidirectionalService {
  rpc Chat (stream ChatMessage) returns (stream ChatMessage);
}

message UserRequest {
  string user_id = 1;
}

message UserResponse {
  string name = 1;
  string email = 2;
}

message EventRequest {
  string topic = 1;
}

message EventResponse {
  int64 event_id = 1;
  string payload = 2;
}

message LogEntry {
  int64 timestamp = 1;
  string level = 2;
  string message = 3;
}

message UploadStatus {
  bool success = 1;
  int32 total_entries = 2;
}

message ChatMessage {
  string user_id = 1;
  string content = 2;
  int64 timestamp = 3;
}