Hi.
On 15.04.23 11:32, Willy Tarreau wrote:
Hi everyone,
I was discussing with Tristan a few hours ago about the widespread
deployment of H2 and H3, with Cloudflare showing that H1 only accounts
for less than 7% of their traffic and H3 getting close to 30% [1],
and the fact that on the opposite yesterday I heard someone say "we
still have not tried H2, so H3..." (!).
Tristan said something along the lines of "if only proxies would enable
it by default by now", which resonated to me like when we decided to
switch some defaults on (keep-alive, http-reuse, threads, etc).
And it's true that at the beginning there was not even a question about
enabling H2 by default on the edge, but nowadays it's as reliable as H1
and used by virtually everyone, yet it still requires admins to know
about this TLS-specific extension called "ALPN" and the exact syntax of
its declaration, in order to enable H2 over TLS, while it's already on
by default for clear traffic.
Is there any experience about the backends and what protocol they use?
As far as I can see is QUIC/h3 not yet there, what's the plan to add
QUIC/h3 as backend protocol?
```
podman run --rm --network host --name haproy-test --entrypoint /bin/bash
-it haproxy:latest
Available multiplexer protocols :
(protocols marked as <default> cannot be specified using 'proto' keyword)
h2 : mode=HTTP side=FE|BE mux=H2 flags=HTX|HOL_RISK|NO_UPG
fcgi : mode=HTTP side=BE mux=FCGI flags=HTX|HOL_RISK|NO_UPG
<default> : mode=HTTP side=FE|BE mux=H1 flags=HTX
h1 : mode=HTTP side=FE|BE mux=H1 flags=HTX|NO_UPG
<default> : mode=TCP side=FE|BE mux=PASS flags=
none : mode=TCP side=FE|BE mux=PASS flags=NO_UPG
```
Do you see any benifit when there is a quic e2e connection?
Something like:
client - Q/H3 - HAProxy - Q/H3 - Backend
Thus you're seeing me coming with my question: does anyone have any
objection against turning "alpn h2,http/1.1" on by default for HTTP
frontends, and "alpn h3" by default for QUIC frontends, and have a new
"no-alpn" option to explicitly turn off ALPN negotiation on HTTP
frontends e.g. for debugging ? This would mean that it would no longer
be necessary to know the ALPN strings to configure these protocols. I
have not looked at the code but I think it should not be too difficult.
ALPN is always driven by the client anyway so the option states what we
do with it when it's presented, thus it will not make anything magically
fail.
Get a +1 for turning on the default settings.
This must be highlighted in the documentation as it could break some
working setups which have not activated H2 on some the listener for some
specific reasons.
And if we change this default, do you prefer that we do it for 2.8 that
will be an LTS release and most likely to be shipped with next year's
LTS distros, or do you prefer that we skip this one and start with 2.9,
hence postpone to LTS distros of 2026 ?
+1 for 2.8 .
Even if I wouldn't share my feelings, some would consider that I'm
trying to influence their opinion, so I'll share them anyway :-) I
think that with the status change from "experimental-but-supported" to
"production" for QUIC in 2.8, having to manually and explicitly deal
with 3 HTTP versions in modern configs while the default (h1) only
corresponds to 7% of what clients prefer is probably an indicator that
it's the right moment to simplify these a little bit. But I'm open to
any argument in any direction.
As the history shows, that the a lot of peoples reuses some sample
configs I would also consider to add a example quic+h2 setup in the
examples directory because the current example quick config looks
somehow wrong.
http://git.haproxy.org/?p=haproxy.git;a=blob;f=examples/quick-test.cfg;h=f27eeff432de116132d2df36121356af0938b8a4;hb=HEAD
I would be nice when the package owner of the distributions would also
adopt there config examples but this is a decision which is done outside
of haproxy :-)
It would be nice to be able to decide (and implement a change if needed)
before next week's dev8, so that it leaves some time to collect feedback
before end of May, so please voice in!
Thanks!
Willy
[1] https://radar.cloudflare.com/adoption-and-usage
Regards
Alex
