Http/3 and http/1.1 support

[pjebs]

What is the typical performance difference between connect protocol using http1.1 vs grpc using http3?

[pjebs]

https://kmcd.dev/posts/grpc-over-http3/
https://kmcd.dev/posts/grpc-over-http3-followup/

[jhump]

Can it be done using this package?

It can! This package supports anything that supports "net/http".

For fasthttp, that means you'll have to use their converter/adapter support -- to adapt a ConnectRPC handler (which is a "net/http" http.Handler) to the fasthttp handler interface.

The quic-go project already supports "net/http", so you can add a ConnectRPC handler to an HTTP/3 server, just as you add any other handler.

My understanding is grpc now supports http3.

Not officially. There are some implementations that support HTTP/3, but Google's reference implementations in the grpc GitHub org mostly do not actually support it. In fact, in the blog post links you just posted, connect-go is one of the few projects that it lists as supporting HTTP/3 😄.

What is the typical performance difference between connect protocol using http1.1 vs grpc using http3?

I don't really have numbers on this. The quic-go project and the stdlib "net/http" package are both evolving and changing. The stdlib has mostly been seeing updates for HTTP/2 in recent releases. We don't have benchmarks available, though we have observed that HTTP 1.1 often outperforms HTTP/2 (potentially surprising, but this is due to performance issues with HTTP/2 in the "net/http" stdlib).

The reduced round trips with HTTP/3 and lack of head-of-line-blocking are certain to decrease latency for many operations, including connection setups and highly concurrent RPCs when the hostname resolves in DNS to only a single host/address. Those blog posts likely have more concrete information than I can provide.

[pjebs]

In that article, it has this table:

Is Connect (using grpc) and Connect using Connect protocol faster than "grpc-web"?
Is Connect (using grpc) just using grpc-web under the hood?

[pjebs]

@jhump
Also, if I start a http3 server to serve connectrpc using the technique in the links above,
I can't see how to get the browser-client to use http3 based on https://connectrpc.com/docs/web/getting-started.

Normally, in a standard rest scenario, the browser makes in the initial request assuming the server is using HTTP/1.1 or /2. The server responds back with a Alt-Srv header suggesting that a http3 service is available. From then onwards, the browser connects using http3.

In the documentation for the javascript connect client, I don't see any indicator it does that process.

[jhump]

Is Connect (using grpc) and Connect using Connect protocol faster than "grpc-web"?

No, they are basically the same. The differences in the protocols are small and shouldn't make an appreciable difference for performance.

Is Connect (using grpc) just using grpc-web under the hood?

No, not really; this isn't really possible as they aren't the same protocol. The main differences in the protocols are how error codes and trailers are transmitted. In plain gRPC, these are sent in HTTP trailers. But because browser APIs do not support HTTP trailers, gRPC-web puts that information in a special "chunk" at the end of the HTTP response body. Another difference is that the gRPC protocol requires HTTP/2, whereas gRPC-web allows HTTP 1.1. But this difference tends to actually be quite minor when implementing since all of gRPC's semantics (other than full-duplex bidirectional streaming) technically work with HTTP 1.1 (as long as your HTTP library supports HTTP trailers).

In the documentation for the javascript connect client, I don't see any indicator it does that process.

This process is automatic -- connect-web uses browser APIs for HTTP, and those APIs automatically handle protocol selection. So the exact same thing happens with ConnectRPC as it does for the REST scenario you described. You shouldn't need to do anything when configuring the client other than be using TLS (i.e. "https" scheme instead of "http"). The server, on the other hand, must be implemented to send back the Alt-Svc header (and must expose the service over HTTP/3 on the indicated port, of course).

[pjebs]

Thanks @jhump