gRPC wire format, HTTP/2 mapping, and call semantics

gRPC is a remote procedure call framework. Native gRPC commonly carries calls on HTTP/2 streams. A request uses POST and a service/method path, with a content-type beginning with application/grpc. Each gRPC message has a five-byte prefix: a compression flag and a four-byte big-endian message length. The message boundary is independent of HTTP/2 DATA-frame boundaries. An HTTP response status of 200 does not by itself mean the RPC succeeded: the final grpc-status is normally carried in trailers, while an immediate failure may use a trailers-only response. Confirm that every intermediary preserves trailers and HTTP/2 semantics.

Expert perspective: a channel is not one connection or unlimited capacity

Google engineer Jean de Klerk’s gRPC engineering article describes a channel as a logical target whose resolver and load balancer may manage multiple HTTP/2 connections. This is implementation guidance about connection utilization and recovery, not a promise that every language runtime creates the same pool. A peer can limit concurrent streams on a connection, and an established long-lived stream is not generally moved to another backend mid-call. Long streams therefore need explicit cancellation, reconnect, and application-level resume behavior where required. A client-side balancing policy cannot transparently relocate work that the server has already accepted.

Separate the schema from the transport

Protocol Buffers is a common IDL and message encoding for gRPC, not its only possible payload format. Compression is indicated through grpc-encoding; when a message’s compression flag is set, the declared encoding applies to that message. Neither the wire format nor generated stubs guarantee a fixed payload reduction or a universal speed advantage over JSON. Results depend on schema, payload shape, language runtime, compression, and network conditions. Generated client and server types can catch some contract mismatches, but deployment compatibility across independently updated services still needs versioning and compatibility rules.

Deadlines, retries, and browser deployment

The protocol document says a server should assume an infinite timeout if grpc-timeout is omitted. Production clients should normally set a deadline that matches the caller’s budget. Calls are not assumed idempotent unless explicitly defined, and the protocol does not provide duplicate suppression. Retrying after an ambiguous failure can repeat an operation; define idempotency keys and retryable outcomes at the application boundary. Browser gRPC-Web has a different feature envelope from native gRPC, so verify the required client/server streaming mode and proxy behavior. Test trailers, flow control, stream limits, cancellation, and retries through the actual ingress path.

References