gRPC supports bidirectional streaming over HTTP/2. One of the implications of streaming is an RPC call idling while reading data from the HTTP/2 response stream. This is the client waiting for the next message. It could arrive immediately or in 5 minutes.

For example, a frontend server could have many bidi streams open with a backend server. The gRPC client in the frontend server is waiting to read data from them and holding onto many buffers. The client app has higher memory usage and GC heap fragmentation.

Customer reported fragmentation hotspots (note: they are using .NET 5, some of these may have been addressed in .NET 6):

• SslStream._internalBuffer
• Http2Stream._responseBufffer
• A byte array (address 0000021845447020) in HttpConnection (from an internal memory dump, ping me if you want a copy)
• Also, opportunity to allow zero-byte reads with responseStream.ReadAsync from user code. Consider HTTP/1.1, HTTP/2 and HTTP/3. This would allow the gRPC client (and other users of HttpClient) to wait until there is data available before renting a buffer.

cc @geoffkizer