← Back to Labs
gRPC Lab
Trace one channel from setup through unary framing, multiplexing, flow control, deadlines, and drain behaviour.
Traffic shapeTune the same channel before stepping through the transport lifecycle
active streams
1
Warm one channel before the wider burst arrives
protobuf payload
24 KiB
24,576 bytes before gRPC framing
message on the wire
24,581 B
5 byte gRPC envelope plus the protobuf body
unary call footprint
24,761 B
Headers, one message, then trailers
window passes
1
Fits in one stream window budget
deadline outcome
180 ms budget
Budget remains larger than current transport and app time
Backend viewOne channel, several possible upstreams
Amsterdam
standby
1 stream
Chosen subchannel, warming the HTTP/2 transport
Frankfurt
standby
0 streams
Candidate endpoint discovered by the resolver
Milan
idle
0 streams
Visible to discovery, unused by the active channel
Dublin
idle
0 streams
Visible to discovery, unused by the active channel
Stream viewLogical RPCs hidden inside one HTTP/2 socket
stream 1
channel ready
HTTP/2 client streams use odd IDs. Under gRPC, one stream usually maps to one RPC, whether that RPC is unary or long-lived streaming.
Wire viewRequest metadata and routing
:method
POST
:path
/inventory.Stock/Reserve
content-type
application/grpc
te
trailers
grpc-timeout
180m
Wire viewResponse framing and final status
:status
200
message envelope
00 00 00 60 00 + protobuf payload (24,576 B)
trailers
grpc-status: 0 OK
Flow-control budgetByte credit at stream and connection scope
Per-stream window24,581 / 32,768 B
Connection window24,581 / 98,304 B
grpc-timeout
180m
Remaining deadline budget propagated to the server and often to downstream RPCs.
estimated service time
85 ms
Transport cost, payload size, and stream concurrency all push this number upward.
final RPC status
0 OK
The HTTP status may still be 200 while this trailer reports the real call result.
Step 1 / 6A gRPC client opens a reusable channel first
The expensive part happens before the application message moves. DNS, TCP, TLS, ALPN, and the first HTTP/2 settings exchange build one channel that later RPCs can reuse.
If every RPC builds its own channel, you pay setup cost, lose multiplexing, and make load balancing noisier than it needs to be.
Arrow keys to navigate · R to reset
Tap dots to jump to any step