On Thu, 28 Dec 2023 17:23:38 +0300 Vladimir Homutov via nginx-devel <nginx-devel@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). > > > > _______________________________________________ nginx-devel mailing list nginx-devel@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-devel