QUIC and HTTP/3 roadmap blog post

[Mathew Heard]

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 <vl at 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 at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx