[gravypod]

Sorry, this might be a bit off topic but it's something I've been excited about for a while. From what I've heard Microsoft is sort of getting behind gRPC. Have you tested using QUIC as a transport layer for the gRPC client/server libraries that MS maintains? Are you seeing notable performance benefits with QUIC as the underlying channel?

[davidfowl]

I'm from the .NET Core team and we've looked at it a little from the HTTP/3 angle but not from a pure QUIC angle. This is because the gRPC RPC protocol is described in terms of HTTP/2 frames today.

[Matthias247]

gRPC encoded data is actually not tightly coupled to HTTP/2 frames. It's described as a stream of gRPC chunk encoded data on top of a HTTP stream. But the gRPC frames do not necessarily have to align with HTTP/2 data frames boundaries.

See https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2....

The specification makes gRPC sound rather tightly bound to HTTP/2 level details, but I don't think it really is. You should be able to speak gRPC just fine over any kind of HTTP. One main pain point for browser support however had been APIs to exchange trailers, which are necessary for gRPC.

[JamesNK]

> gRPC encoded data is actually not tightly coupled to HTTP/2 frames.

The headers frame, and the capability to have headers before AND after content is a requirement. gRPC requires trailing headers for the status code of the call. Trailing headers frame is a new concept in HTTP/2.

gRPC-Web supports HTTP/1.1 and browsers. It is able to do that by encoding the status into the end of the response body. However gRPC-Web is a different spec.

If HTTP/3+QUIC supports the same features of HTTP/2 then gRPC should work on it. There might be a HTTP/3 specific spec for details around the management of a HTTP/3 connection, but gRPC headers, message content, and proto contracts shouldn't need to change. Take what I say with a grain of salt because I haven't looked closely at HTTP/3+QUIC yet.

[Matthias247]

A headers frame before content is just equivalent so „sending headers“, since Http/2 also only allows to send headers once per Stream unless those are informational headers. In the same fashion, sending a headers frame after content is equivalent to „sending trailing headers“ - which are allowed to be sent at most once after the body (which may be empty).

Therefore the fact that there is a frame involved doesn’t really matter.

HTTP/3 doesn’t change the HTTP semantics: Peers are sending 0-N informational headers, 1 set of request headers, a stream of body data, and 0-1 set of trailing headers. Therefore gRPC should run fine over it at long as the underlying HTTP library exposes all those necessary features.

[slowstart]

RPC/gRPC are certainly possible use cases for the QUIC transport protocol. But no, we have not yet explored the use of QUIC in this context. For now we are focused on workloads that will benefit the most from the tail latency performance and security improvements that QUIC brings.