In an ideal implementation it should be pretty much as fast as plain HTTP/2, since the overhead is only a bit of protobuf framing between chunks. Which dependin

In an ideal implementation it should be pretty much as fast as plain HTTP/2, since the overhead is only a bit of protobuf framing between chunks. Which depending on the chunk size is negligible. However what I think comes into play in the benchmark is the behavior of the real library, and most likely the garbage collector. There might be paths in the code where the each chunk is freshly allocated and later on dropped. This gets more costly if chunks get bigger, which might explain the degradation in the measurements. In this example the client's chunk size is allocated once and everything else is a cheap slice, which should be good. However for the server I'm not sure, I guess it might allocate the buffer for each chunk just in order to drop it later on. Then you could investigate if you can give protobuf a prepopulated data structure with a reserved maximum size (e.g. from a pool) that it should use for deserialization, which might speed things up. Another thing which obviously comes into play is the performance of HTTP/2 implementations, which may vary a lot. I think even for Go, the HTTP/2 implementation in the net package and the one in grpc where different (not sure if they unified them now, there was an attempt on the way). So the question would need to be investigated separately for each of those.