G2: gRPC over HTTP/3 #256
G2: gRPC over HTTP/3 #256
Conversation
It was revealed during the [HTTP/3 gRFC discussion][1] that servers using RST_STREAM for deadlines and the client-side trick of double-checking the deadline when processing CANCELLED status wasn't documented. I'm not all that bothered if an implementation uses Trailers instead of RST_STREAM for deadline, but it does seem hard for an implementation to avoid truncating a message in that situation and it may extend the amount of time the RPC consumes memory. [1]: grpc/proposal#256
| A trial implementation in grpc-dotnet is underway. .NET 6 is adding preview support for | ||
| HTTP/3 to the .NET server and client. grpc-dotnet leverages that underlying HTTP/3 support. | ||
|
|
||
| ## Open issues (if applicable) |
There was a problem hiding this comment.
QUIC always uses security (TLS) which means gRPC-over-http3 always requires certs/keys IIUC. Does it impact the gRPC API or the usage? To be addressed in this gRFC?
There was a problem hiding this comment.
HTTP/3 would never be negotated over an insecure connection.
Scenarios would be:
- gRPC client uses prenegotated H2C over insecure connection
- gRPC client uses TLS and requests only HTTP/2. Ignores
alt-svcheader returned from the server. - gRPC client uses TLS and requests HTTP/2 or greater. In this case an initial HTTP/2 call is made, server returns response with an
alt-svcheader that tells the client that HTTP/3 is available. HTTP/2 connection is replaced with QUIC+HTTP/3 and future calls use HTTP/3. - gRPC client uses TLS and is configured in advance to only do HTTP/3. QUIC+HTTP/3 connection is made to server.
There was a problem hiding this comment.
I think clients might introduce channel settings to give users the specify what protocol they want. For example:
RequestVersionwith2.0,3.0.RequestVersionPolicywithRequestVersionExact,RequestVersionOrGreater(allow upgrade)
|
Hi James, Do you happen to know how gRPC Servers or Client e.g. SDK kind of pluming/wrapper code get notified of transport errors for any of the following types of streaming gRPC connections (service interface call/functions), other than implementing their own heartbeat timeout mechanism?:
? Thank you, -lars |
| ## Implementation | ||
|
|
||
| A trial implementation in grpc-dotnet is underway. .NET 6 is adding preview support for | ||
| HTTP/3 to the .NET server and client. grpc-dotnet leverages that underlying HTTP/3 support. |
There was a problem hiding this comment.
@lidizheng what about doing some python asyncio prototyping!? https://github.com/aiortc/aioquic
There was a problem hiding this comment.
I understand that building a MVP gRPC Python HTTP/3 on top of the aioquic library probably isn't that hard. Currently, gRPC Python uses gRPC Core as the transport layer, it's not that trivial to move existing code onto another transport library. I hope if we want to invest resources, we have a working architecture and aiming for long-term support.
|
@JamesNK, is there anything in this PR you'd like to change before I merge it? It looks like there's only one typo to address from my perspective. |
Fixed typo. I also added a section on HTTP/3 negotiation in reply to @sanjaypujare's comment. |
A specification for gRPC over HTTP/3.
There is a lot of overlap with the content in https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md. For example, request and response headers are unchanged between HTTP/2 and HTTP/3. Rather than duplicate content, the proposal focuses on the differences between HTTP/2 and HTTP/3.
Preview: https://github.com/JamesNK/proposal/blob/jamesnk/http3/G2-http3-protocol.md