Ai Aleks, On Sat, Apr 15, 2023 at 10:12:00PM +0200, Aleksandar Lazic wrote: > 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?
It's not there yet. It's planned for the long term (no emergency, it will only be relevant once h3 is common on the backends). And regarding H2 on the backend, it's not recommended if you're serving objects of moderate to large size, as it can cause head-of-line blocking. That's the reason why we've disabled connection sharing on the backend between multiple clients, because a slow client can cause some buffers to fill and slow other clients down. Using larger buffers is generally not a good option (it increases the memory footprint which often results in slowing down everything), and using smaller H2 windows to the server forces the server to make small frames and constantly switch between streams, which is not efficient either. Overall the only way to use H2 efficiently on the backend is either when it mostly delivers small objects in parallel (e.g. shipping cart thumb images, or map tiles), or when limiting it to one stream per connection to only benefit from the faster binary encoding and more resilient connection. H3 will make this incredibly better by the way, since all streams are independent. > > 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. Thanks for the feedback! > 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. I know, and that's also why I preferred to ask. > > 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 . OK. > > 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 Note that this one was called "quick test" to allow to quickly perform a test, it's not related to the QUIC protocol (no "k" in the name) :-) > 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 :-) We tried this in the past and it revealed difficult. It appears that many load balancer users think they're doing the same stuff but when you look at their config they come from different requirements with very different setups. Even the global section is not often the same. I'd rather see a dialog-based wizard asking a few questions and producing an initial config. That would help way more users. Thanks! Willy
