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

[Maxim Dounin]

Hello!

On Wed, Dec 27, 2023 at 04:17:38PM +0300, Vladimir Homutov via nginx-devel wrote:

> 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.

Thanks for the details.

Multiplexing is available since introduction of the FastCGI 
protocol, yet to see it working in upstream connections.  As for 
0-RTT, using keepalive connections is probably more efficient 
anyway (and not really needed for upstream connections in most 
cases as well).

> >
> > [...]
> >
> > >     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.

Yep, making things easier to configure (and modify, if something 
related to configuration directives is changed or additional 
protocol is added) is the main motivator.  Still, there are indeed 
differences between protocol modules, and this makes single module 
inconvenient sometimes.  As such, plans are uncertain (and the 
previous attempt to do this failed miserably).

-- 
Maxim Dounin
http://mdounin.ru/