Phase out use of custom HTTP2 Transport

[johanbrandhorst]

Please answer these questions before submitting your issue.

What version of gRPC are you using?

1.12.0

What version of Go are you using (go version)?

1.10

What operating system (Linux, Windows, …) and version?

Linux

What did you do?

I checked the source of the transport package.

What did you expect to see?

I expected the gRPC HTTP2 transport to be built on top of the Go standard library HTTP2 stack.

What did you see instead?

There is a separate HTTP2 stack implementation.

This is mostly an issue to hear about current opinions and possibly tracking the migration from the internal HTTP2 stack to that of the Go standard library. I'm guessing this is something we can all agree is a good idea even if it might not be of the highest priority.

On a personal level I'm interested in grpc-go building its client stack on top of a net/http.Client or at least a net/http.RoundTripper because I'm currently looking at writing a grpc-web client for Go to be compiled to WASM, and this kind of thing together with my recently merged Fetch based net/http.RoundTripper would basically allow grpc-go to be compiled to WASM and work out of the box.

[dfawley]

Hi @johanbrandhorst,

I'm guessing this is something we can all agree is a good idea even if it might not be of the highest priority.

I agree this sounds good in theory. In practice, however, I don't think it will ever be possible to delete the grpc HTTP2 stack and replace it with uses of net/http. There are a number of features in the grpc transport that are not present in the net/http client/server. For example: keepalive, max-idleness detection, and hooks for stats and interceptors.

In the upcoming quarter, I intend to redesign the interface between the grpc layer and the transport, make it public, and introduce a way to inject alternate transports. This should make it straightforward to implement a transport based on the net/http package instead. I don't think that could be our default for the reasons mentioned above, but we may be able to support it as an alternative.

[johanbrandhorst]

@dfawley that's great to hear, and would potentially provide a nicer solution for #2174 😊.

[nhooyr]

@dfawley would it be possible to add the features necessary into the Go http2 client and then use that instead?

[dfawley]

@nhooyr It may be possible, but you're talking about upstreaming a lot of features that the Go team may not want in their server. Also, we have done a lot of performance tuning work, so we would have to make sure performance was the same or better before switching. In the end, the effort would be a lot of work, and we have higher priority things on our plate. When we complete the refactor to allow for alternate transports, something built on the standard http2 server could be an optional one.

I'm not sure if you're aware, but we do have a ServeHTTP that makes our server work with the standard http2 implementation if you absolutely need it, but it's experimental.

[dfawley]

Let's track this effort under #906, which predates this issue.