I'm using nginx 1.26.1 from the nginx.org ubuntu repo.
I find when I remove the "reuseport" flag from the "listen" directive
for my quic port, a lot page assets fail to load, and the browser
ultimately falls back to http/2.
When I re-add "reuseport", all http/3 requests succeed again.
How crucial is "reuseport" when using quic on nginx? Is it normal for
things to break badly without it?
Hello,
On Sat, 15 Jun 2024 13:58:55 +0100
Dominic Preston <lzqhwo at gmail.com> wrote:
> I'm using nginx 1.26.1 from the nginx.org ubuntu repo.
>
> I find when I remove the "reuseport" flag from the "listen" directive
> for my quic port, a lot page assets fail to load, and the browser
> ultimately falls back to http/2.
>
> When I re-add "reuseport", all http/3 requests succeed again.
>
> How crucial is "reuseport" when using quic on nginx? Is it normal for
> things to break badly without it?
> _______________________________________________
Very, it's required to use the reuseport parameter when using multiple
workers as per the documentation here[1] so that all UDP packets of a
HTTP/3/quic connection are routed to and handled by the same worker, as
I understand.
This is just due to limitations of how UDP (being
stateless and sessionless) is handled by the kernel compared to TCP
(which is session orientated).
[1] https://nginx.org/en/docs/quic.html#configuration
On Tue, 25 Jun 2024 at 16:35, J Carter <jordanc.carter at outlook.com> wrote:
> Very, it's required to use the reuseport parameter when using multiple
> workers as per the documentation here[1] so that all UDP packets of a
> HTTP/3/quic connection are routed to and handled by the same worker, as
> I understand.
I see, thanks. It's so badly broken without the reuseport parameter
that I think using multiple workers with quic should imply reuseport,
or at the very least raise a warning in the logs if an attempt is made
to use such a configuration.