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

[J Carter]

On Thu, 28 Dec 2023 17:23:38 +0300
Vladimir Homutov via nginx-devel <nginx-devel at nginx.org> wrote:

> 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.
> 
Those heavy handshakes wouldn't be the only concern either...

Lack of upstream multiplexing has come up as a concern in the past
with the grpc module (which lacks it) due to that amplification effect
of client side h2 connections and streams being translated into
x*y upstream connections.

This poses a danger of ephemeral port exhaustion when targeting relatively
few upstream servers (such as proxying to an L4 load balancer instead of 
direct to application servers).

This necessitates provisioning a ton of VIPs and using proxy_bind 
(which isn't always practical / is a pain).

It would be exactly the same for h3 (and more so once grpc over h3
eventually becomes solid, especially bidi).

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