gRPC unary RPC latency spikes exclusively when multiple calls share a single HTTP/2 connection

gRPC unary RPC latency spikes only when multiple calls run concurrently on a single HTTP/2 connection.

The shared connection limits the HTTP/2 flow‑control window, enforces a max concurrent streams setting, and subjects all streams to TCP head‑of‑line blocking from packet loss.

Uncertainty remains whether the delay stems from application buffer draining, flow‑control window size, or TCP congestion on the shared connection.

1. Does latency correlate with the server’s max concurrent streams configuration?
2. Is the spike reproduced when the client drains inbound data promptly versus when it stalls?
3. Can adjusting the HTTP/2 flow‑control window size mitigate the concurrency‑only latency?