[PATCH 00 of 12] HTTP/3 proxying to upstreams

[Vladimir Homutov]

On Wed, Dec 27, 2023 at 02:48:04PM +0300, Maxim Dounin wrote:
> Hello!
>
> On Mon, Dec 25, 2023 at 07:52:41PM +0300, Vladimir Homutov via nginx-devel wrote:
>
> > Hello, everyone,
> >
> > and Merry Christmas to all!
> >
> > I'm a developer of an nginx fork Angie.  Recently we implemented
> > an HTTP/3 proxy support in our fork [1].
> >
> > We'd like to contribute this functionality to nginx OSS community.
> > Hence here is a patch series backported from Angie to the current
> > head of nginx mainline branch (1.25.3)
>
> Thank you for the patches.
>
> Are there any expected benefits from HTTP/3 being used as a
> protocol to upstream servers?

Personally, I don't see much.

Probably, faster connection establishing to due 0RTT support (need to be
implemented) and better multiplexing (again, if implemented wisely).
I have made some simple benchmarks, and it looks more or less similar
to usual SSL connections.

>
> [...]
>
> >     Probably, the HTTP/3 proxy should be implemented in a separate module.
> >     Currently it is a patch to the HTTP proxy module to minimize boilerplate.
>
> Sure.  I'm very much against the idea of mixing different upstream
> protocols in a single protocol module.

noted.

> (OTOH, there are some uncertain plans to make proxy module able to
> work with other protocols based on the scheme, such as in
> "proxy_pass fastcgi://127.0.0.1:9000;".  This is mostly irrelevant
> though, and might never happen.)

well, currently we have separate proxying modules that are similar enough to
think about merging them like suggested. Not sure if one big module with
methods will worth it, as semantics is slightly different.

proxy modules are already addons on top of upstream module, which does
the heavy lifting. What requires improvement is probably the
configuration that makes user to remember many similar directives doing
the same thing but for different protocols.