How is gRPC client streaming/bidirectional streaming implemented with HTTP/2?
Server streaming makes sense, in that it could utilize server push to send multiple responses to a request, but it's not clear to me how it does bidirectional message passing over HTTP/2 the way one would over a websocket.
2
votes
1 Answers
5
votes
gRPC encodes streams as HTTP bodies. There is a five byte header before each message, consisting of the message length and a flag byte. It does not use SERVER_PUSH or other HTTP/2-specific features for streaming.
At its core, gRPC is streaming. Unary (single request, single response) and server streaming (single request) are simply special cases for producing cleaner APIs or more optimized I/O behavior. But on-the-wire, everything looks the same as streaming.
The specification of HTTP/1 allows but does not require streaming and bidirectional connections, but some implementations don't support them. But with the nature of HTTP/2, it is generally more work to not support them. Also, there aren't decade-old HTTP/2 proxies to cause compatibility problems; gRPC is able to work with the HTTP/2 ecosystem to encourage streaming to be supported.
For more information of the gRPC encoding, see gRPC's PROTOCOL-HTTP2.md, especially Length-Prefixed-Message.
