对不起，如果这个问题很幼稚。(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 会话。流通道将用于客户端和服务器之间的持续遥测数据流。(持续的数据传输，但从服务器到客户端的大量数据传输(。
流通道是否有单独的 TCP 会话，而对于每个写入和读取，将在调用完成后建立和终止一个新会话？
还是只有一个TCP会话，所有通信都通过该会话进行？
再次，如果这很幼稚，请原谅我。
谢谢你的时间。
由于 gRPC 使用 HTTP/2，因此它可以在同一 TCP 连接上多路复用多个 RPC。gRPC 中的通道抽象允许 gRPC 做出连接决策，而无需应用程序具有强感知能力。
默认情况下，gRPC 使用"先选取"负载均衡策略，该策略将使用与后端的单个连接。所有新的RPC 都将通过该连接。
连接可能会中断(由于 I/O 故障(或需要关闭(各种原因(，因此 gRPC 会自动处理重新连接。由于关闭连接可能需要很长时间(因为 gRPC 会等待该连接上的 RPC 完成(，因此 gRPC 仍有可能具有 2 个或更多连接到同一后端的连接。
因此，对于您的情况，所有 RPC 最初都存在于同一个连接上。随着时间的推移，新的 RPC 可能会使用较新的连接，而旧的、长期存在的流通道 RPC 可能会使初始 TCP 连接保持活动状态。如果该应用程序关闭并重新创建该长期存在的 StreamChannel，则它可以再次共享较新的连接。
我也在 grpc.io 中发布了相同的问题，我得到的回复与标记的答案一致。 总结： 如果没有负载平衡，则所有 RPC 都使用相同的会话。会话在请求之间保持连接。会话建立发生在首次尝试在通道上呼叫时。