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

[Vladimir Homutov]

On Thu, Dec 28, 2023 at 04:31:41PM +0300, Maxim Dounin wrote:
> 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).

With HTTP/3 and keepalive we can have just one quic "connection" per upstream
server (in extreme). We perform heavy handshake once, and leave it open.
Next we just create HTTP/3 streams to perform request. They can perfectly
run in parallel and use same quic connection. Probably, this is something
worth implementing, with limitations of course: we don't want to mix
requests from different (classes of) clients in same connection, we
don't want eternal life of such connection and we need means to control
level of such multiplexing.

>
> > >
> > > [...]
> > >
> > > >     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/
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-devel