Hi Vladimir, Within the main users of HTTP/3 we are seeing an uptick in users doing long lived connections and users using previously niche features (such as server push) leading to an expectation of near indefinite session life (and websocket isnt yet available for http/3).
Basically applications built to take full advantage of QUIC tend towards using larger, longer sessions as opposed to the traditional HTTP request & response. There are many drivers for this (modern app development libraries, PWA trend as well as more HTTP/3 related such as increase session establishment time). I'm no researcher in that area (just someone who sees the trend in his work) so I'll leave that there for now. I'm well aware of the rationale and the difficulties to implement such a thing in the current nginx architecture. I wouldn't say it's impossible, but difficult - yes certainly. I can think of a couple ways it could be architected especially now you have that ebpf packet router. Regards, Mathew On Tue, 13 Jul 2021 at 23:18, Vladimir Homutov <v...@nginx.com> wrote: > > On Tue, Jul 13, 2021 at 06:55:14PM +1000, Mathew Heard wrote: > > Hi Maxim, > > > > Really interesting read. > > > > Do you have any plans for resolving the SIGHUP causes session closure > > issues that currently exist with nginx-quic? The closure of long lived > > connections has been a thorn in the side of people doing HTTP/1.1 web > > sockets (and probably HTTP/2 push) for many years. With HTTP/3 (QUIC) > > it's even more pronounced. > > > > From my point of view its the single biggest obstacle to the QUIC > > upgrade. as a user. > > > > Regards, > > Mathew > > Hi Mathew, > > connections are handled in worker processes, and reload means running > new worker processes, that don't have state for existing connections. > QUIC doesn't change how nginx handles connections, so there are no > specific plans to change it. > > Can you please elaborate how HTTP/3 makes things worse from your > perspective? > _______________________________________________ > nginx mailing list > nginx@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx _______________________________________________ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx