How to pack many requests in a single TCP packet with HTTP2 and HTTP3?

[alexandrehtrb]

Hello,

With HTTP2 and HTTP3, we can fit many HTTP requests into a single TCP packet. How does that work for HttpClient in .NET?

Let's suppose a code like this:

var reqProfile = httpClient.GetAsync("/user/profile");
var reqPosts = httpClient.GetAsync("/user/posts");
var reqFavourites = httpClient.GetAsync("/user/favourites");

await Task.WhenAll(reqProfile, reqPosts, reqFavourites);

Does HttpClient have an internal intelligence that fits all those requests together?

[Clockwork-Muse]

Strictly speaking, you're not guaranteed that those three requests will go to the same physical machine (Even ignoring things like loadbalancing), so the ability to somehow stuff them into the same packet may be non-helpful. And even if you are sending them to the same physical machine, devices along the network route can split them however they want.
You definitely aren't getting the responses back in the same packet, which probably renders the whole thing moot anyways.

Is there a particular problem you're trying to solve here, that requires you put things into a single packet? Usually when an application needs to do something like this (eg, multiplayer games) they're manually constructing the packets at quite a low level (and normally using raw UDP/TCP, not HTTP).

[MihaZupan]

There are no guarantees, but we do try to pack as much data into buffers before flushing it to the network as possible.

Currently in the HTTP/2 implementation we have a queue (Channel) of frames to write to the connection, and we'll only flush after that channel is empty (or you reach some size limit).
If you happen to have multiple requests being sent at exactly the same time and they're in that queue at the same time, it's possible they'll end up being sent together.

[alexandrehtrb]

It could be interesting to have a method that sends requests together, like:

await httpClient.SendBatchAsync(req1, req2, req3);

[MihaZupan]

I don't think we'd want to offer any guarantees about how such requests end up being sent (the API shape would force us to just call SendAsync one by one), at which point the helper isn't all that useful once you account for the need to handle multiple responses, possibly only some of those requests failing, ...

[Clockwork-Muse]

"could be interesting" is insufficient justification for a feature, especially one as involves as this one would be.

Again, is there some particular pain point you're experiencing? There might be alternative ways to solve the problem.