时间戳

首页 > 解决方案 > 与 gRPC 的 TCP 会话

tcp - 与 gRPC 的 TCP 会话

问题描述

对不起，如果这个问题很幼稚。（这里是 gRPC 新手）。但是，我想了解这一点。

假设我有一个这样的 gRPC 服务定义：

service ABC {
  // Update one or more entities.
  rpc Write(WriteRequest) returns (WriteResponse) {
  }
  // Read one or more entities.
  rpc Read(ReadRequest) returns (stream ReadResponse) 
  {
  }
  // Represents the bidirectional stream 
  rpc StreamChannel(stream StreamMessageRequest)
      returns (stream StreamMessageResponse) {
  }
}

我们的潜在用例是使用 C++ 构建的服务器和使用 Java 构建的客户端。（不确定这是否重要）。

我想了解如何管理 TCP 会话。Stream Channel 将用于客户端和服务器之间的持续遥测数据流。（不断的数据传输，但从服务器到客户端的批量）。

StreamChannel 是否有单独的 TCP 会话，而每次写入和读取都会在调用完成后建立和终止一个新会话？

或者是否有一个 TCP 会话可以进行所有通信？

再次，如果这很幼稚，请原谅我。

谢谢你的时间。

标签： tcpgrpc

解决方案

由于 gRPC 使用 HTTP/2，它可以在同一个 TCP 连接上多路复用多个 RPC。gRPC 中的 Channel 抽象让 gRPC 无需应用程序需要强感知即可做出连接决策。

默认情况下，gRPC 使用“pick first”负载平衡策略，它将使用单个连接到后端。所有新的RPC 都将通过该连接。

连接可能会终止（由于 I/O 故障）或需要关闭（各种原因），因此 gRPC 会自动处理重新连接。因为关闭连接可能需要很长时间（因为 gRPC 会等待该连接上的 RPC 完成），所以 gRPC 仍然可能有 2 个或更多连接到同一个后端。

因此，对于您的情况，所有 RPC 最初都存在于同一个连接上。随着时间的推移，新的 RPC 可能会使用更新的连接，而旧的、长期存在的 StreamChannel RPC 可能会保持初始 TCP 连接处于活动状态。如果该长期存在的 StreamChannel 被应用程序关闭并重新创建，那么它可以再次共享较新的连接。

推荐阅读