Question

很抱歉，这个问题是否幼稚。（此处是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会话。流通道将用于客户端和服务器之间的恒定遥测数据流。（恒定的数据传输，但是从服务器到客户端的批量传输）。

StreamChannel是否有一个单独的TCP会话，而对于每个Write和Read，都会在调用完成后建立并终止一个新会话？

还是只有一个TCP会话可以进行所有通信？

再说一次，请原谅我。

感谢您的时间。

Answer 1

由于gRPC使用HTTP / 2，因此它可以在同一TCP连接上多路复用多个RPC。 gRPC中的Channel抽象使gRPC可以做出连接决策，而无需高度了解应用程序。

默认情况下，gRPC使用“优先选择”负载平衡策略，该策略将使用与后端的单个连接。所有 new RPC都会通过该连接。

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

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

Answer 2

我也在grpc.io中发布了相同的问题，并且得到的答复与标记的答案一致。摘要：如果没有负载平衡，则所有RPC使用相同的会话。会话保持跨请求连接。会话建立是在第一次尝试在频道上进行呼叫时发生的。

使用gRPC的TCP会话

2 个答案: