- uses HTTP/2 as the underlying multiplexed transport: requests are multiplexed over a single TCP connection; explicitly allow for full-duplex streaming.
- pluggable transport layer: gRPC/HTTP/2, gRPC/QUIC, internally gRPC/LOAS2.
- high-performance, compact, lightweight: uses binary rather than text; header compression to reduce the sie of request and response.
- uses static paths for performance reasons during call dispatch as parsing call parameters from paths, query parameters and payload body adds latency and complexity. Paths encodes method name.
- utilize protobuf
- for microservices
- used by Docker/Kubernetes, etcd
- from Google
- Stub: a single client.
- Channel: a single TCP connection. Can be multiplexed(usd by multiple stubs).
gRPC encourages sharing channels; channels are relatively expensive, stubs for different services at the same server can share the same channel.
- Payload: a sequence of bytes opaque to the transport protocol
- Metadata/Side Channel (Optional): e.g. client max waiting time, authentication info, etc. Sidechannel is represented with the Metadata class, which models the sidechannel as an untyped key-value map. Keys are ASCII characters, values are bytes, to be compatible with shipping over HTTP headers. (gRPC sidechannel is effectively a map from string to bytes)
- hardcoded(no control): logic hardcoded in the RPC system, cannot be customized.
- interceptors/filters(partial control): RPC system controls the bulk of the handling of the event; users can registered interceptors (or filters), RPC system will run the interceptors, apply the side-effects, and continue the execution of the event.
- handlers(full control): user implement "handlers" to fully handle an event.
- ALTS, Application Layer Transport Security(LOAS2); a replacement for SSL/TLS
- TLS: from external to Google
- ALTS: for service-to-service communications within Google's infrastructure
- gRPC: a replacement for Google's internal only Stubby, on top of TLS or ALTS