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